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

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