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 <t...@tomh.org >> <mailto:t...@tomh.org>> 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? _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
