On Mon, Jan 7, 2019 at 9:58 PM Tom Henderson <t...@tomh.org> 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 <mk...@kapsi.fi> 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
_______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
