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

[Yoav Nir <[e-mail]>]

On Dec 21, 2009, at 8:54 PM, <[e-mail]> 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.

No, this will solve the problem in the long term. In the short term, there are things like Windows 7 out there that already use group 19 and group 20 (and they only send x). For the vendor to follow your obsolescence plan, they would need to have a patch that replaces the use of 19 and 20 with, say, groups 27 and 28. That would mean breaking interoperability with the old unpatched Windows 7, plus all other implementations out there (there is even less running code for groups 19 and 20). So a vendor would have to support both group 19 (wrong or right interpretation) and group 27 (hopefully only one right interpretation) 

> 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.

Well, both Tero's company and mine have people who follow this list, and yet both companies made this mistake. "People just knowing" failed". Luckily for us, this running code was not yet released when they discovered the issue, so we don't have a support/upgrade problem. The real issue is with running code that's both broken and out there. Unfortunately, we can't rely on all developers on ECDH code being on this list. The mitigating factor is that those who implement by using OpenSSL code will run into the fact that OpenSSL APIs only give you the x coordinate, unless you supplement their code with your own function  that gets the y coordinate.

> 
> Thanks,
> --David