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

[Tero Kivinen <[e-mail]>]

[e-mail] writes:
> >   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.

Yes. Exactly that was what I was trying to say, except same thing also
needs to be done for RFC5114, as it refers to RFC4753, and perhaps
also RFC4869 as it also refers to RFC4753. 

> That said, I'd like to see more reason to believe that there is
> an actual "running code" problem before doing something this drastic.

As I said QuickSec versions 4.4 - 5.0 (i.e. QuickSec versions released
between 2007-2009) do include original RFC4753 code, the person who
fixed our code to support RFC4753 didn't notice the errata...

As our OEM toolkit is used quite widely I think there are quite a lot
of existing products doing things without errata. Also most of those
people (our customers) are not reading this list.

> If most people working with elliptic curve "just know" that only
> one coordinate is used, we might not have a problem in practice.
-- 
[e-mail]