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

From: "Jerome A. Solinas" <[email-masked]>
Date: Fri, 22 Jan 2010 13:48:17 -0500

Paul Hoffman wrote:
> First off, thank you for bringing the topic to the WG. As the Designated Expert, you are certainly allowed to make decisions without asking, so it is extra nice that you ask on decisions that might be controversial.
>
> On this particular topic, I would note that RFC 4753 is Informational RFC, not a standards-track document. Thus, I would think that desires of the authors of the RFC should have a heavier influence than the rest of us, although our input might be important inputs to them (and maybe to the Designated Expert). Maybe we should put the issue aside until we hear from them, which could be after the holiday.
>
> --Paul Hoffman, Director
>   
We would recommend keeping the same numbers (19, 20, 21) since it 
appears that all existing implementations have made the correction.  
Also, we would prefer to keep RFC4753 and RFC5114 distinct since we'd 
like to keep a separate document as a Suite B reference.  If the 
inclusion of the three ECP groups in two different standards is causing 
confusion, it might be worth thinking about removing them from the 
upcoming RFC5114 update.

-- Jerome A. Solinas, RFC4753 coauthor

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 23 Jan 2010 00:13:10 -0800 (PST)

I agree with Jerome's opinion. Let's leave 19, 20, and 21 the way
they are. If there is confusion between the 2 RFCs than let's fix it
in a -bis favoring the former of the two.

  Dan.

On Fri, January 22, 2010 10:48 am, Jerome A. Solinas wrote:
> Paul Hoffman wrote:
>> First off, thank you for bringing the topic to the WG. As the Designated
>> Expert, you are certainly allowed to make decisions without asking, so
>> it is extra nice that you ask on decisions that might be controversial.
>>
>> On this particular topic, I would note that RFC 4753 is Informational
>> RFC, not a standards-track document. Thus, I would think that desires of
>> the authors of the RFC should have a heavier influence than the rest of
>> us, although our input might be important inputs to them (and maybe to
>> the Designated Expert). Maybe we should put the issue aside until we
>> hear from them, which could be after the holiday.
>>
>> --Paul Hoffman, Director
>>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jan 2010 11:18:21 +0200

> appears that all existing implementations have made the correction.

Not true.

For example our QuickSec OEM IPsec toolkit did originally use only X,
but then some vendor complained that RFC4753 uses both X and Y so we
"fixed" our toolkit to use both. All version shipped between 2007 and
end of 2009 uses both X and Y, and only the latest version uses only
X.

Yes, this will mean that our latest version is not compatible with our
old versions, so most likely that will cause the connections timeout
when ECP groups are used, thus most likely users will then just notice
that "Do not use ECP, it does not work".

And note, that we only modified our code when some OTHER vendor told
us that RFC4753 uses both X and Y.

So we were not the only implementation out there which followed
original RFC4753.

Also as our customer has quite a long product cycles usually meaning
that the release we make now will most likely get into the products
only after year or two, and when we provide fixes for old versions for
them, they might or might not make their actual products, that is not
something we can tell. Usually it takes long time to get them into
their products, which means the QuickSec toolkit based implementations
using X and Y are going to be out there for long time... 
-- 
[email-masked]