As we discuss in the draft, there are two reasons for making the hash
as long as possible. First, a longer hash is more secure to brute
force attacks made possible by advances in hardware. Some time ago
Hugo Krawczyk recommended us to us use at least 96 bits of a hash.
Second, the longer the hash the lower the probability of collisions.
Of course, being secure against brute force attacks is a two-edged
sword. From an architectural point of view, ORCHIDs should be
considered as a medium-term (10-20 years) transition mechanism that
allows legacy IPv6 applications to securely use HIP and other similar
protocols. In the longer run, such a practise should be discouraged;
we should encouraged people to update from the IPv6 API to some new
API that makes the security properties more transparent. However,
there is a long long way ahead before we get there, if ever. I just
want to note that while there are socially-beneficial incentives for
making the ORCHID hash as long as possible, there are also other,
longer-term incentives for making it not too long.
In my personal opinion, having ORCHIDs that are considered secure now
and could be estimated to be secure for the next 20 years or so might
be about the right size.
Considering the second property, or collisions, I think it is
important to experiment with completely flat name spaces. While I do
see the value of having an organisation ID embedded in an identifier,
I do also see the value of having completely opaque flat
identifiers. Both have their pros and cons, especially if you
consider privacy and privacy-related externalities, like price
discrimination potential.
--Pekka
On Jun 4, 2006, at 1:51, Dave Thaler wrote:
I think for this experiment a longer prefix is fine,
even /40 or /48 unless there's some strong reason it needs
to be shorter during the experiment.
Personally, I'd eventually like to see something like a /8
followed by an org id (like ULAs have). Since ULAs have 32
bits for such an id, that's how I get /40 (or /48 if eventually
there were a /16 like ULAs use, followed by 32 bit org id).
This would solve some problems HIP doesn't solve today,
which were pointed out in the SHIM6 meeting in Dallas.
(e.g., PTR records for HITs aren't feasible today since
the reverse zone would be flat).
The use of a long prefix for the present experiment could
be consistent with such an eventuality in the sense that
the hash would be truncated to about the same number of bits
(like 80 or 88).
-Dave
-----Original Message-----
From: Jari Arkko [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 6:19 AM
To: Internet Area
Subject: [Int-area] Progress on draft-laganier-ipv6-khi-01.txt
Sometime ago we discussed the allocation of an IPv6 prefix
for the purposes of legacy applications using HIP (the
ORCHID proposal). The key question in that discussion was
whether a /8 allocation is justified for this type of an
experiment. Since then we've had some off-line discussions
with the folks who commented on this topic, to come up
with alternatives to solve this issue. The proposal that
seemed to be acceptable is to allocate a longer prefix
(e.g. /28) as an IETF experimental allocation through
IANA. The implication is that the public key hash would
be truncated to 100 bits, presumably still within
an acceptable range.
If you have an opinion about this matter, please send
mail either here or on the HIP list before June 9th
so that Julien can update his draft.
Thanks,
--Jari
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
