Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

["Dan Harkins" <[e-mail]>]

On Fri, November 30, 2012 1:03 pm, Yaron Sheffer wrote:
> The problem I have with this discussion is, this check (if really
> required) should have been in the base protocol, because the protocol
> has supported EC groups from day one. It doesn't belong in a specific
> curve definition. We could use the errata process to add it. It's not
> ideal, but certainly better than republishing RFC 5996.

  Yes, this check is required for the reasons Scott explained.

  I think "the protocol has supported EC groups from day one" is a
bit of an overstatement. EC support was poorly defined as the protocol
says that g^ir is the shared secret and it's an octet string. That's it.
Many people who were familiar with ECDH assumed that, when doing
ECDH, that octet string is just the x-coordinate of the point that
results from completing the exchange. (Note: it's bad for protocols
to leave it up to the reader to assume).

  Then along came RFC 4753 that said the concatenation of the x-
and y-coordinates (in that order) was the thing that was "used in the
formation of SKEYSEED." Well that screwed up all the people who
(rightly) assumed that it was just the x-coordinate. This was realized
a bit late so now we have RFC 5903 which obsoletes RFC 4753 that
says the ECDH shared secret is the x-coordinate. Unfortunately,
RFC 5114 adds two more ECP groups-- 25 and 26- but says that
the format of the shared secret for them is per 4753, i.e. the wrong
way. And RFC 5114 has not (yet) been obsoleted to fix that.

  So we can have an IKEv2-compliant implementation from prior to
June 2010 that will not interoperate with an IKEv2-compliant
implementation after June 2010. And to be a truly RFC-compliant
implementation it would mean that you represent the ECDH shared
secret differently for P256 and P224. Yuck, what a mess. A recipe
for spagetti code.

  RFC 5996 followed this mess but did nothing to specify what is
the right behavior for ECDH while it was obsoleting RFC 4306.

  While I tend to agree that specification of this critical issue should
not be left to the RFC that defines the curve that horse has already
left the barn for IKEv2. As far as republishing RFC 5996 is concerned,
I think a better approach would be to acknowledge that interoperability
is problematic with IKEv2 and there's not much we can do about it now,
so the best way to proceed is to obsolete it before it gets traction in
the field. And I know a draft that can do just that!

  regards,

  Dan.

> Thanks,
> 	Yaron
>
> On 11/30/2012 08:26 PM, Scott Fluhrer (sfluhrer) wrote:
>> There should *absolutely* be a requirement that any point you receive
>> from the peer is actually a point on the curve.
>>
>> What can happen if you don't?  Well, that depends on the implementation
>> of the point addition/doubling; what happens with the normal
>> implementation is that it acts as if it was a different curve with a
>> different curve order -- this means that someone introducing a bogus
>> value can give us a point with a small order (which can't happen with
>> the normal Brainpool curves, because those curves have prime orders).
>>
>> In addition, validating the values is cheap; easily worth the gain.
>>
>>
>> Also, given the you validate the peer's value, and forbid public points
>> which are the point-at-infinity, doubling checking that the D-H common
>> value is not the point at infinity appears to be unneeded.  The
>> Brainpool Curves are (again) of prime order; this implies that the D-H
>> common value is the point at infinity only if the peer's public value is
>> the point at infinity (which ought to be forbidden), or our secret value
>> is a multiple of the curve order (in which case, our public value is the
>> point at infinity).
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Dan Harkins
>> Sent: Friday, November 30, 2012 12:57 PM
>> To: Johannes Merkle
>> Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; [e-mail]
>> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key
>> Exchange
>>
>>
>>    Hi Johannes,
>>
>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
>>> We have submitted a new revision of the Internet Draft on Using the
>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange
>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/
>>>
>>> Since there was considerable objection to the point compression method
>>> in the WG, we have removed this option altogether and define only the
>>> uncompressed KE payload format, which is in full accordance with RFC
>>> 5903.
>>>
>>>
>>> Any feedback is welcome.
>>
>>    I see that there is a requirement that an implementation MUST verify
>> that the D-H common value is not the point-at-infinity. Do you think
>> there should also be a requirement that an implementation MUST verify
>> that the x- and y-coordinates received from a peer satisfy the
>> equation of the negotiated curve (and abort the exchange if not)?
>>
>>    regards,
>>
>>    Dan.
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>