Re: Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)
Eric Rescorla <[email protected]> Wed, 21 Nov 2018 11:37:03 -0800
| Newsgroups | gmane.ietf.hipsec,gmane.ietf.hip |
|---|---|
| Message-ID | <CABcZeBPUvZW0qa5X+SGzAaDgJhArw5Q3NSnSj6cYhBce4cnzqw@mail.gmail.com> |
--===============6057043714504134378== Content-Type: multipart/alternative; boundary="0000000000002711c2057b31e2d6" --0000000000002711c2057b31e2d6 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 20, 2018 at 12:07 PM Miika Komu <[email protected]> wrote: > Hi Eric, > > On 5/7/18 00:41, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-hip-rfc4423-bis-19: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3709 > > > > > > Maybe I'm missing something important, but I don't see in this > > document how you go from a HI (or HIT) to the corresponding IP > > locator. That seems pretty critical to making this work. Can you point > > me in the right direction? > > (I interpret "right" direction here as how to implement this in > practice; please let me know if you were asking for something else) > > Existing applications can utilize LSIs or HITs, for instance, via > /etc/hosts in Linux or if the developer/user uses them directly. > Mappings can be configured manually. A better way is to use ,e.g., DNS > to store the FQDN, HIs, IP address mappings: > > https://tools.ietf.org/html/rfc8005 > > An application can receive LSIs or HITs from DNS queries when a HI > record exists for a host. This can be implemented in the local resolver > library (e.g. glibc in Linux) supports it and sends the HI-to-IP address > mapping to the local HIP daemon. As an alternative implementation > technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux): > > https://tools.ietf.org/html/rfc6538#section-4.1 > > As yet another alternative, RFC5338 (section 3.2) suggests interposing > HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in > Linux) that translate HIs into LSIs and HITs to the application and > cache the IP address mapping to the HIP daemon: > > https://tools.ietf.org/html/rfc5338#section-3.2 > > That's all for existing applications. New HIP native applications could > use DNS library extensions for getaddrinfo() that would be implemented > e.g. in glibc in Linux: > > https://tools.ietf.org/html/rfc6317 > > All of the mentioned references are mentioned in the draft. Should I add > something more compressed along these lines of text or is this too > detailed? > Maybe I'm missing something, but it seems like this is not an interoperable state of affairs. > IMPORTANT > > S 11.3.1. > >> avoiding manual configurations. The three components are further > >> described in the HIP experiment report [RFC6538]. > >> > >> Based on the interviews, Levae et al suggest further directions to > >> facilitate HIP deployment. Transitioning the HIP specifications > to > >> the standards track may help, but other measures could be taken. > As > > > > This confuses me, because we seem to be looking to advance some of the > > HIP specs (e.g., hip-dex) at PS > > Can you elaborate? And do you mean protocol stack by PS? > Proposed Standard. > > 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. > S 4. > >> 'well known', some unpublished or 'anonymous'. A system may self- > >> assert its own identity, or may use a third-party authenticator > like > >> DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity > assertion > >> to another namespace. It is expected that the Host Identifiers > will > >> initially be authenticated with DNSSEC and that all > implementations > >> will support DNSSEC as a minimal baseline. > > > > This wasn't a very good assumption when 4423 was published, and it > > seems even worse now, given the low rate of deployment of DNSSEC and > > the fact that we know many middleboxes break DNSSEC. > > Then I guess it would be fine to remove the last sentence? > Yes, I think that would be good to do. > > 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. > > S 5.1. > >> At the server side, utilizing DNS is a better alternative than a > >> shared Host Identity to implement load balancing. A single FQDN > >> entry can be configured to refer to multiple Host Identities. > Each > >> of the FQDN entries can be associated with the related locators, > or a > >> single shared locator in the case the servers are using the same > HIP > >> rendezvous server Section 6.3 or HIP relay server Section 6.4. > > > > This is becoming a less common practice. How do you handle anycast, > > which is the modern practice? > > I added the following statement: > > "It is also worth noting that opportunistic mode is also required > > > in practice when anycast IP addresses would be utilized as locators:" > > Does this address your concern? > > Btw, opportunistic mode is further described in the following documents: > I'm not following how this solves the problem. It seems like you're still going to get badly suboptimal routing. -Ekr > Existing apps: > > https://tools.ietf.org/html/rfc6538#section-2.3.2 > https://tools.ietf.org/html/rfc5338#section-3.2 > > HIP native apps: > > https://tools.ietf.org/html/rfc6317#section-4.1.1 > > > S 7. > >> > >> The encapsulation format for the data plane used for carrying the > >> application-layer traffic can be dynamically negotiated during the > >> key exchange. For instance, HICCUPS extensions [RFC6078] define > one > >> way to transport application-layer datagrams directly over the HIP > >> control plane, protected by asymmetric key cryptography. Also, > S-RTP > > > > Nit: SRTP, no hyphen > > Thanks, fixed! > --0000000000002711c2057b31e2d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <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]"= >[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi E= ric,<br> <br> On 5/7/18 00:41, Eric Rescorla wrote:<br> > Eric Rescorla has entered the following ballot position for<br> > draft-ietf-hip-rfc4423-bis-19: No Objection<br> > <br> > When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s<br> > introductory paragraph, however.)<br> > <br> > <br> > Please refer to <a href=3D"https://www.ietf.org/iesg/statement/discuss= -criteria.html" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/i= esg/statement/discuss-criteria.html</a><br> > for more information about IESG DISCUSS and COMMENT positions.<br> > <br> > <br> > The document, along with other ballot positions, can be found here:<br= > > <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis= /" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/dr= aft-ietf-hip-rfc4423-bis/</a><br> > <br> > <br> > <br> > ----------------------------------------------------------------------= <br> > COMMENT:<br> > ----------------------------------------------------------------------= <br> > <br> > Rich version of this review at:<br> > <a href=3D"https://mozphab-ietf.devsvcdev.mozaws.net/D3709" rel=3D"nor= eferrer" target=3D"_blank">https://mozphab-ietf.devsvcdev.mozaws.net/D3709<= /a><br> > <br> > <br> > Maybe I'm missing something important, but I don't see in this= <br> > document how you go from a HI (or HIT) to the corresponding IP<br> > locator. That seems pretty critical to making this work. Can you point= <br> > me in the right direction?<br> <br> (I interpret "right" direction here as how to implement this in <= br> practice; please let me know if you were asking for something else)<br> <br> Existing applications can utilize LSIs or HITs, for instance, via <br> /etc/hosts in Linux or if the developer/user uses them directly. <br> Mappings can be configured manually. A better way is to use ,e.g., DNS <br> to store the FQDN, HIs, IP address mappings:<br> <br> <a href=3D"https://tools.ietf.org/html/rfc8005" rel=3D"noreferrer" target= =3D"_blank">https://tools.ietf.org/html/rfc8005</a><br> <br> An application can receive LSIs or HITs from DNS queries when a HI <br> record exists for a host. This can be implemented=C2=A0 in the local resolv= er <br> library (e.g. glibc in Linux) supports it and sends the HI-to-IP address <b= r> mapping to the local HIP daemon. As an alternative implementation <br> technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux):<b= r> <br> <a href=3D"https://tools.ietf.org/html/rfc6538#section-4.1" rel=3D"noreferr= er" target=3D"_blank">https://tools.ietf.org/html/rfc6538#section-4.1</a><b= r> <br> As yet another alternative, RFC5338 (section 3.2) suggests interposing <br> HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq"= ; in <br> Linux) that translate HIs into LSIs and HITs to the application and <br> cache the IP address mapping to the HIP daemon:<br> <br> <a href=3D"https://tools.ietf.org/html/rfc5338#section-3.2" rel=3D"noreferr= er" target=3D"_blank">https://tools.ietf.org/html/rfc5338#section-3.2</a><b= r> <br> That's all for existing applications. New HIP native applications could= <br> use DNS library extensions for getaddrinfo() that would be implemented <br> e.g. in glibc in Linux:<br> <br> <a href=3D"https://tools.ietf.org/html/rfc6317" rel=3D"noreferrer" target= =3D"_blank">https://tools.ietf.org/html/rfc6317</a><br> <br> All of the mentioned references are mentioned in the draft. Should I add <b= r> something more compressed along these lines of text or is this too detailed= ?<br></blockquote><div><br></div><div>Maybe I'm missing something, but = it seems like this is not an interoperable state of affairs.</div><div><br>= </div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > IMPORTANT<br> > S 11.3.1.<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding manual configurations.=C2=A0 Th= e three components are further<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0described in the HIP experiment report [= RFC6538].<br> >>=C2=A0 =C2=A0 <br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Based on the interviews, Levae et al sug= gest further directions to<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0facilitate HIP deployment.=C2=A0 Transit= ioning the HIP specifications to<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0the standards track may help, but other = measures could be taken.=C2=A0 As<br> > <br> > This confuses me, because we seem to be looking to advance some of the= <br> > HIP specs (e.g., hip-dex) at PS<br> <br> Can you elaborate? And do you mean protocol stack by PS?<br></blockquote><d= iv><br></div><div>Proposed Standard.</div><div> <br></div><div>=C2=A0</div>= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;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; for example, t= here is a 1% chance of collision<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in a population of 640M.=C2=A0 F= or 100 bits (or more), we would not<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 expect a collision until approxi= mately 2**50 (1 quadrillion)<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hashes were generated.<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>enou= gh 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><br></div><div><br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> > S 4.<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0'well known', some unpublished o= r 'anonymous'.=C2=A0 A system may self-<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0assert its own identity, or may use a th= ird-party authenticator like<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0DNSSEC [RFC2535], PGP, or X.509 to '= notarize' the identity assertion<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0to another namespace.=C2=A0 It is expect= ed that the Host Identifiers will<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0initially be authenticated with DNSSEC a= nd that all implementations<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0will support DNSSEC as a minimal baselin= e.<br> > <br> > This wasn't a very good assumption when 4423 was published, and it= <br> > seems even worse now, given the low rate of deployment of DNSSEC and<b= r> > the fact that we know many middleboxes break DNSSEC.<br> <br> Then I guess it would be fine to remove the last sentence?<br></blockquote>= <div><br></div><div><br></div><div>Yes, I think that would be good to do.</= div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;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 being 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 Ho= st Identity, the Host<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Identifiers (public keys) will 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 to 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#section-5</a><br> <br> (Please let me know if an explicit reference is needed)<br></blockquote><di= v><br></div><div>No, I'm referring to the point I raised above.</div><d= iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > S 5.1.<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0At the server side, utilizing DNS is a b= etter alternative than a<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0shared Host Identity to implement load b= alancing.=C2=A0 A single FQDN<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0entry can be configured to refer to mult= iple Host Identities.=C2=A0 Each<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0of the FQDN entries can be associated wi= th the related locators, or a<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0single shared locator in the case the se= rvers are using the same HIP<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0rendezvous server Section 6.3 or HIP rel= ay server Section 6.4.<br> > <br> > This is becoming a less common practice. How do you handle anycast,<br= > > which is the modern practice?<br> <br> I added the following statement:<br> <br> "It is also worth noting that opportunistic mode is also required <br> <br> <br> in practice when anycast IP addresses would be utilized as locators:"<= br> <br> Does this address your concern?<br> <br> Btw, opportunistic mode is further described in the following documents:<br= ></blockquote><div><br></div><div>I'm not following how this solves the= problem. It seems like you're still going to get</div><div>badly subop= timal routing.</div><div><br></div><div>-Ekr</div><div><br></div><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <br> Existing apps:<br> <br> <a href=3D"https://tools.ietf.org/html/rfc6538#section-2.3.2" rel=3D"norefe= rrer" target=3D"_blank">https://tools.ietf.org/html/rfc6538#section-2.3.2</= a><br> <a href=3D"https://tools.ietf.org/html/rfc5338#section-3.2" rel=3D"noreferr= er" target=3D"_blank">https://tools.ietf.org/html/rfc5338#section-3.2</a><b= r> <br> HIP native apps:<br> <br> <a href=3D"https://tools.ietf.org/html/rfc6317#section-4.1.1" rel=3D"norefe= rrer" target=3D"_blank">https://tools.ietf.org/html/rfc6317#section-4.1.1</= a><br> <br> > S 7.<br> >>=C2=A0 =C2=A0 <br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0The encapsulation format for the data pl= ane used for carrying the<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0application-layer traffic can be dynamic= ally negotiated during the<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0key exchange.=C2=A0 For instance, HICCUP= S extensions [RFC6078] define one<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0way to transport application-layer datag= rams directly over the HIP<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0control plane, protected by asymmetric k= ey cryptography.=C2=A0 Also, S-RTP<br> > <br> > Nit: SRTP, no hyphen<br> <br> Thanks, fixed!<br> </blockquote></div></div> --0000000000002711c2057b31e2d6-- --===============6057043714504134378== 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 --===============6057043714504134378==--