Re: [Int-area] Progress on draft-laganier-ipv6-khi-01.txt

[Pekka Nikander <[e-mail]>]

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:[e-mail]]
>> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/int-area
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/int-area
>


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area