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

[Eric Rescorla <[e-mail]>]

On Mon, Jan 7, 2019 at 9:58 PM Tom Henderson <[e-mail]> wrote:

> Eric, Miika asked me to share some off-list discussion we had on your
> questions about second preimage attacks in HIP (inline below, trimming to
> the relevant parts).
>
> - Tom
>
> On 11/21/18 11:37 AM, Eric Rescorla wrote:
>
>
>
> On Tue, Nov 20, 2018 at 12:07 PM Miika Komu <[e-mail]> wrote:
>
>>
>> > Eric Rescorla has entered the following ballot position for
>> > draft-ietf-hip-rfc4423-bis-19: No Objection
>> >
>> >
>
>
>
>
>> > COMMENTS
>> > S 3.1.
>> >>          were obtained.  For 64 bits, this number is roughly 4
>> billion.  A
>> >>          hash size of 64 bits may be too small to avoid collisions in a
>> >>          large population; for example, there is a 1% chance of
>> collision
>> >>          in a population of 640M.  For 100 bits (or more), we would not
>> >>          expect a collision until approximately 2**50 (1 quadrillion)
>> >>          hashes were generated.
>> >
>> > It's not just a matter of collisions being hard, but also of being
>> > difficult to produce an HI with a given name.
>>
>> ....where name would be the hash (i.e. HIT). So I added:
>>
>> Besides accidental collisions, it is also worth noting that intentional
>> collisions are difficult to accomplish because generating a valid,
>> colliding hash along with its private-public key is computationally
>> challenging.
>>
>> Did I capture your thinking correctly?
>>
>
> Well, this isn't a collision; it's what's called a preimage. I.e.,
> computing a public
> key with a given HIT. Anyway, as far as I can tell, in HIP being able to
> compute
> a preimage for HIT Y = H(K_X) is equivalent to breaking key K_X, so that
> means
> that that function must have reasonable strength. 2^64 is nowhere near
> enough and the typical expected security level of IETF protocols is 2^128,
> so that means that the full width of the IPv6 address has to be used.
>
> 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/

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


>
>
>
>> > S 4.3.
>> >>       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.
>> >
>> > How do you handle second-preimage attacks on the hash?
>>
>> I guess you are referring to this:
>>
>> https://tools.ietf.org/html/rfc7343#section-5
>>
>> (Please let me know if an explicit reference is needed)
>>
>
> No, I'm referring to the point I raised above.
>
> Would you prefer to add a statement such as "The defense against second
> preimage attacks on the hash is the length of the hash truncation (96
> bits), the work required to generate keys to try, and the possible
> distribution of both the host identity and HIT to end systems."?
>
I think you need to lay the situation out rather more completely than this.
I mean, the current text doesn't even say "preimage". You need to describe
the threat, how the-potential attack works, and why it's difficult

-Ekr