Re: Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)
Eric Rescorla <[email protected]> Tue, 8 Jan 2019 05:57:41 -0800
| Newsgroups | gmane.ietf.hipsec,gmane.ietf.hip |
|---|---|
| Message-ID | <CABcZeBPKCOq7hO85CRAd3XRiH4v=G7ohG7p8X5GDeENX9+8B8g@mail.gmail.com> |
--===============4996898957918389353== Content-Type: multipart/alternative; boundary="000000000000d04731057ef2bcde" --000000000000d04731057ef2bcde Content-Type: text/plain; charset="UTF-8" On Mon, Jan 7, 2019 at 9:58 PM Tom Henderson <[email protected]> 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 <[email protected]> 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 --000000000000d04731057ef2bcde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr">On Mon, Jan 7, 2019 at 9:58 PM Tom Henderson <<a href= =3D"mailto:[email protected]">[email protected]</a>> wrote:<br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"> =20 =20 =20 <div bgcolor=3D"#FFFFFF"> <div class=3D"gmail-m_1059893292592447722moz-cite-prefix">Eric, Miika a= sked 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).</div> <div class=3D"gmail-m_1059893292592447722moz-cite-prefix"><br> </div> <div class=3D"gmail-m_1059893292592447722moz-cite-prefix">- Tom<br> </div> <div class=3D"gmail-m_1059893292592447722moz-cite-prefix"><br> </div> <div class=3D"gmail-m_1059893292592447722moz-cite-prefix">On 11/21/18 1= 1:37 AM, Eric Rescorla wrote:<br> </div> <blockquote type=3D"cite"> =20 <div dir=3D"ltr"><br> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr">On Tue, Nov 20, 2018 at 12:07 PM Miika Komu <<a href=3D"mailto:[email protected]" target=3D"_blank">mkomu@k= apsi.fi</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> > Eric Rescorla has entered the following ballot position for<br> > draft-ietf-hip-rfc4423-bis-19: No Objection<br> > <br> ></blockquote> <div> <br> </div> <div>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > COMMENTS<br> > S 3.1.<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 were obtained.=C2=A0= For 64 bits, this number is roughly 4 billion.=C2=A0 A<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hash size of 64 bits= may be too small to avoid collisions in a<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 large population; fo= r example, there is a 1% chance of collision<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in a population of 6= 40M.=C2=A0 For 100 bits (or more), we would not<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 expect a collision u= ntil approximately 2**50 (1 quadrillion)<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hashes were generate= d.<br> > <br> > It's not just a matter of collisions being hard, but also of being<br> > difficult to produce an HI with a given name.<br> <br> ....where name would be the hash (i.e. HIT). So I added:<br> <br> Besides accidental collisions, it is also worth noting that intentional <br> collisions are difficult to accomplish because generating a valid, <br> colliding hash along with its private-public key is computationally <br> challenging.<br> <br> Did I capture your thinking correctly?<br> </blockquote> <div><br> </div> <div>Well, this isn't a collision; it's what's called= a preimage. I.e., computing a public</div> <div>key with a given HIT. Anyway, as far as I can tell, in HIP being able to compute</div> <div>a preimage for HIT Y =3D H(K_X) is equivalent to breaking key K_X, so that means</div> <div>that that function must have reasonable strength. 2^64 is nowhere near</div> <div>enough and the typical expected security level of IETF protocols is 2^128,</div> <div>so that means that the full width of the IPv6 address has to be used.</div> <div><br> </div> </div> </div> </blockquote> <p>The second preimage attack resistance is 96 bits, plus whatever work is needed to generate the keys.=C2=A0 </p></div></blockquote><di= v>I agree that this is in RFC 7343, but it doesn't seem to be stated an= ywhere in this document, and=C2=A0 given that this text talks about both 64= bit and >=3D 100 bit hash functions, I'm not sure how to get it fro= m this text, which is in context quite confusing/<br></div><div><br></div><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor=3D"#FFFFFF"><= p>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.=C2=A0 My recollection is that the WG had thought 96 bits to be strong enough preimage resistance.</p></div></blockquote><div>Generally, we = are targeting the 128-bit security level for new deployments<br></div><div>= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= ..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor= =3D"#FFFFFF"><p> </p> <blockquote type=3D"cite"> <div dir=3D"ltr"> <div class=3D"gmail_quote"><br> <div> <br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> > S 4.3.<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet.=C2=A0 Consequently, = a HIT should be unique in the whole IP<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0universe as long as it is be= ing used.=C2=A0 In the extremely rare case of<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0a single HIT mapping to more= than one Host Identity, the Host<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Identifiers (public keys) wi= ll make the final difference.=C2=A0 If there<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0is more than one public key = for a given node, the HIT acts as a hint<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0for the correct public key t= o use.<br> > <br> > How do you handle second-preimage attacks on the hash?<br> <br> I guess you are referring to this:<br> <br> <a href=3D"https://tools.ietf.org/html/rfc7343#section-5" rel= =3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/rfc7343#secti= on-5</a><br> <br> (Please let me know if an explicit reference is needed)<br> </blockquote> <div><br> </div> <div>No, I'm referring to the point I raised above.</div> </div> </div> </blockquote> <p>Would you prefer to add a statement such as "The defense agains= t 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."?<br></p></div></blockquote><div>I think you need t= o lay the situation out rather more completely than this. I mean, the curre= nt text doesn't even say "preimage". You need to describe the= threat, how the-potential attack works, and why it's difficult<br></di= v><div><br></div><div>-Ekr</div><div> <br></div></div></div> --000000000000d04731057ef2bcde-- --===============4996898957918389353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec --===============4996898957918389353==--