Re: [Hipsec] Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

[Miika Komu <[e-mail]>]

Hi,

On 1/20/19 07:59, Tom Henderson wrote:
> On 1/8/19 3:44 PM, Eric Rescorla wrote:
>>
>>
>> On Tue, Jan 8, 2019 at 9:50 AM Tom Henderson <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     On 1/8/19 5:57 AM, Eric Rescorla wrote:
>>
>>      >     The second preimage attack resistance is 96 bits, plus
>>     whatever work
>>      >     is needed to generate the keys.
>>      >
>>      > I agree that this is in RFC 7343, but it doesn't seem to be stated
>>      > anywhere in this document, and  given that this text talks about
>>     both 64
>>      > bit and >= 100 bit hash functions, I'm not sure how to get it
>>     from this
>>      > text, which is in context quite confusing/
>>
>>     I agree that the text could be clarified; I will try to suggest
>>     something more.
>>
>>      >
>>      >     There isn't any mechanism defined to extend this, such as 
>> the CGA
>>      >     Hash Extension, but it seems to me that HIP could be extended
>>     in a
>>      >     similar way.  My recollection is that the WG had thought 96
>>     bits to
>>      >     be strong enough preimage resistance.
>>      >
>>      > Generally, we are targeting the 128-bit security level for new
>>     deployments
>>      >
>>
>>     Can you provide a reference for the 128-bit recommendation?
>>
>>
>> I don't believe there is a policy, but for instance, see:
>> https://tools.ietf.org/html/rfc7525#section-4.1
>>
>>     Also, how are legacy uses like SEND/CGA handling this new target (or
>>     are
>>     they just considered legacy at this point)?
>>
>>
>> As far as I understand it, they are legacy.
>>
>> -Ekr
>>
> 
> Eric and all,
> 
> In response to this thread, I propose below an additional paragraph to 
> the draft.
> 
> In section 3.1, it discusses requirements on the new namespace in
> general and mentions the desire to avoid collisions, but just lists a
> generic requirement to provide 'authentication services' because the
> cryptographic details are provided later.  As a result, I decided
> against describing second pre-image resistance here.
> 
> In section 4.3, the following paragraph currently concludes the section:
> 
>     In the HIP packets, the HITs identify the sender and recipient of a
>     packet.  Consequently, a HIT should be unique in the whole IP
>     universe as long as it is being used.  In the extremely rare case of
>     a single HIT mapping to more than one Host Identity, the Host
>     Identifiers (public keys) will make the final difference.  If there
>     is more than one public key for a given node, the HIT acts as a hint
>     for the correct public key to use.
> 
> I suggest to add a paragraph as follows:
> 
>     Although it may be rare for an accidental collision to cause a single
>     HIT mapping to more than one Host Identity, it may be the case that
>     an attacker succeeds to find, by brute force or algorithmic weakness,
>     a second Host Identity hashing to the same HIT.  This type of attack
>     is known as a preimage attack, and the resistance to finding a second
>     Host Identifier (public key) that hashes to the same HIT is called
>     second preimage resistance.  Second preimage resistance in HIP is
>     based on the hash algorithm strength and the length of the hash
>     output used.  Through HIPv2 [RFC 7401], this resistance is 96 bits
>     (less than the 128 bit width of an IPv6 address field due to the
>     presence of the ORCHID prefix [RFC7343]).  96 bits of resistance
>     was considered acceptable strength during the design of HIP, but may
>     eventually be considered insufficient for the threat model of an
>     envisioned deployment.  One possible mitigation would be to augment
>     the use of HITs in the deployment with the HIs themselves (and
>     mechanisms to securely bind the HIs to the HITs), so that the HI
>     becomes the final authority.  It also may be possible to increase
>     the difficulty of brute force attack by making the generation of the
>     HI more computationally difficult, such as the hash extension
>     approach of SEND CGAs [RFC 3972], although the HIP specifications
>     through HIPv2 do not provide such a mechanism.  Finally, deployments
>     that do not use ORCHIDs (such as certain types of overlay networks)
>     might also use the full 128-bit width of an IPv6 address field for
>     the HIT.

thanks! Eric, does this address your concerns?