Hi David, I don't believe there is an actual "running code" problem. It's just a documentation problem and the errata corrects it.
The thing is, _if_ a running code problem exists the proposal to add new identifiers for the exact same ECP definitions would not fix it. Dan. On Mon, December 21, 2009 10:54 am, black_da...@emc.com wrote: > Dan, > >> If we allocate new numbers to do it right then we will, in fact, live >> forever with an ambiguous interpretation of groups 19, 20, and 21. I >> agree we should fix the problem and not live with ambiguity. The >> proposal >> to allocate new numbers doesn't seem to do that though. > > Fine, here's how to accomplish that goal - the RFC that allocates > the new group numbers should: > 1) explain why the group numbers 19, 20 and 21 are ambiguous; > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; > 3) instruct IANA to remove the group number registrations for > 19, 20 and 21 in a fashion that prevents reallocation; and > 4) obsolete RFC 4753. > That should avoid long term problems. > > That said, I'd like to see more reason to believe that there is > an actual "running code" problem before doing something this drastic. > If most people working with elliptic curve "just know" that only > one coordinate is used, we might not have a problem in practice. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_da...@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Monday, December 21, 2009 1:44 PM >> To: Yaron Sheffer >> Cc: ipsec@ietf.org; Yoav Nir; Tero Kivinen >> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, >> RFC5114, RFC4869, and draft- >> solinas-rfc4753bis-01) >> >> >> Yaron, >> >> If we allocate new numbers to do it right then we will, in fact, live >> forever with an ambiguous interpretation of groups 19, 20, and 21. I >> agree we should fix the problem and not live with ambiguity. The >> proposal >> to allocate new numbers doesn't seem to do that though. >> >> Dan. >> >> On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote: >> > Hi Tero, >> > >> > I support your position (and disagree with Yoav). We had better fix >> this >> > problem now by allocating a few more numbers, than live forever with >> an >> > ambiguous interpretation to the numbers that everybody's using. >> > >> > Thanks, >> > Yaron >> > >> > -----Original Message----- >> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of >> > Tero Kivinen >> > Sent: Monday, December 21, 2009 13:21 >> > To: Yoav Nir >> > Cc: ipsec@ietf.org >> > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess >> (RFC4753, >> > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) >> > >> > Yoav Nir writes: >> >> If there is such an implementation, then it's not interoperating >> >> with all the other implementations and should be fixed. >> > >> > It is following the published RFC, so why should it be fixed. I think >> > everybody agreed that making major non-interoperable change in the >> > errata was not proper way of fixing the thing (there were lots of >> > developers who had missed that). >> > >> > This whole discussion about the errata started because one implementor >> > was implementing the RFC and wanted to make sure that the y is really >> > added, and he wanted to make sure that he understood it correctly as >> > that would eman that those groups cannot be made complient to FIPS >> > 140-2. >> > >> > He had not noticed the errata. There were also other people who had >> > not noticed the errata (including me). >> > >> > I am sure there is also people who do not follow the IPsec list and >> > still do implement things (following IPsec list is not really >> > requirement for implementing IPsec). >> > >> > I am only person in our office who regularly follow IPsec list and all >> > others just take RFCs and read them and write code based on them. I am >> > not sure if any of those people actually even know how to find >> > errata... >> > >> > Made quick poll around the office, and found out that noboby here had >> > checked any of the errata for any of the RFCs they have worked on. >> > They said they usually do check for rfc-index to see if the RFC was >> > updated or obsoleted, but that is it. >> > >> >> If someone shipped something like that, then the only reason they >> >> haven't noticed yet, is because they (1) didn't test it well enough, >> > >> > Doing testing against your implementation does not detect that kind of >> > problem as everything works fine. Also for quite a lot of IPsec >> > vendors the main goal is to make implementation which works with their >> > own products and the secondary goal is that it works with other >> > vendor's product too. >> > >> >> and (2) their customers are using some other option like 1024-bit >> >> MODP group (and 3DES, but that's beside the point) >> > >> > That is most likely true for all current IPsec implementations. >> > Elliptic curves are not really used that much yet. That is the reason >> > I want to fix this problem now, not move it to future. >> > >> >> Anyway, making everyone add a new group "28" just so nobody needs to >> >> patch their old implementation of group "20" seems like wasted >> >> effort to me. We can keep group 20, and fix the spec to prescribe >> >> what everybody is doing anyway. >> > >> > I do not want to see the support request saying that our product does >> > not interoperate vendor X's product when using group 19 and then later >> > find out that is because the other vendor has implemented RFC4753 >> > and didn't notice the errata. >> > >> > Also it will most likely take our customer and our support quite a >> > long time before they even realize why recipient of IKE_AUTH will >> > simply drop the packet because of wrong MAC. After that wasted effort >> > I know that it will come to me, and I need to explain to our customer >> > that our code is correct and the other implementation was also correct >> > when they wrote the code, but they are not correct anymore... >> > >> > I do not think the elliptic curves are used that much in the current >> > IPsec installations, so I think we still have time to fix this problem >> > properly. >> > -- >> > kivi...@iki.fi >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> > Scanned by Check Point Total Security Gateway. >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec