Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

Dan,

I'm inclined to concur with Bill Sommerfeld and you that we don't have
a "running code" problem, but my original email suggests what could
be done to retire the old identifiers _if_ we did have such a problem.

Thanks,
--David

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Dan Harkins
> Sent: Monday, December 21, 2009 3:53 PM
> To: Black, David
> Cc: ynir@checkpoint.com; dharkins@lounge.org; kivinen@iki.fi; ipsec@ietf.org; Black, David
> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-
> solinas-rfc4753bis-01)
> 
> 
>   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_David@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_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >> -----Original Message-----
> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@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-bounces@ietf.org [mailto:ipsec-bounces@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.
> >> > --
> >> > kivinen@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