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

[Tero Kivinen <[e-mail]>]

Scott C Moonen writes:
> Tero, what you propose seems the right way to go in principle, but I 
> suspect we are solving a problem that doesn't exist.  Is there any crypto 
> library or device that exposes the y coordinate for use in the ECDH 
> secret?  It seems pretty well established that the x coordinate serves as 
> the ECDH secret.  Moreover, since the y coordinate provides only one more 
> bit of independent information, it's actually misleading to use it.

At least in our crypto library it would be possible to get both of
them out if we wanted. I checked our implementation and currently it
seems to return only x, but that was changed July 2009 after this
dicussion started on the list. Before that the code was modified in
2007 to follow RFC4753, and the original code was written in 2001.

This means that all our implementations we have released between
2007-2009 are using the orignal RFC4753 version, thus nobody will be
interoperable with those.

> I seriously doubt there is any implementation that does not implement the 
> intent of the erratum, if only because there are immense practical 
> barriers to implementing the RFC as written.  Given that, I think the 
> practical result of what you propose will actually be more confusion and a 
> longer period of time before all implementations (as well as all 
> standards/profiles) are able to re-stabilize to the new ECDH landscape. 
> The practical cost of making this change is greater than the practical 
> benefit it buys.

There are as all our QuickSec implementations with versions 4.4 - 5.0
do include the original RFC 4753 code, and only the latest QuickSec
5.1 was modified to include errata.

(I just now noticed this myself).

Note, that none of our customers have complained to us that we are not
compatible with other vendor's product using groups 19-21, so that
either means nobody uses those groups, or some of those other vendors
have also implemented RFC4753 without errata... 

> On the other hand, if there is such an implementation, then we probably do 
> need to do something like what you propose.

As we need to do something on those versions anyway, I rather make
patch that will fix them to follow the new RFC, and also change the
group numbers to match new group numbers for those old versions, as
then customers using those versions will not break their own
interoperability with old versions (it is ok, if they decide to select
some other Diffie-Hellman group as old versions do not support new
numbers, but it is not ok for the implementations to get MAC failures
when trying to use those groups). 
-- 
[e-mail]