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

From: Johannes Merkle <[email-masked]>
Date: Fri, 30 Nov 2012 13:11:51 +0100

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.

-- 
Johannes

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 30 Nov 2012 09:57:25 -0800 (PST)

Hi Johannes,

On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote:
> Since there was considerable objection to the point compression method in
> the WG, we have removed this option altogether

  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.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 30 Nov 2012 18:26:25 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: Friday, November 30, 2012 12:57 PM
To: Johannes Merkle
Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; [email-masked]
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 
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 30 Nov 2012 23:03:51 +0200

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.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Fri, 30 Nov 2012 21:39:08 +0000

Hi Johannes,

Dan't question made me realise something I hadn't noticed before. 

In section 2.3, the draft says:
   For the encoding of the key exchange payload and the derivation of
   the shared secret, the methods specified in [RFC5903] are adopted.

   In an ECP key exchange in IKEv2, the Diffie-Hellman public value
   passed in a KE payload consists of two components, x and y,

However, according to RFC 5903:
      The Diffie-Hellman shared secret value consists of the x value of
      the Diffie-Hellman common value.

In fact RFC 5903 replaced 4753 just to say that the encoding consists only of x, not both x and y.

This also relates to Dan't question. If the y value is missing, what is there to verify?

Yoav

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 30 Nov 2012 22:00:55 +0000

With ECDH, there are two separate EC points that are output by the algorithm:

- There's the public value xG (where x is our secret); this is passed in the KE payload
- There's the shared secret value xyG (where x is our shared secret, and y is the peer's secret); this is used in the key derivation function.

What RFC5903 says is:
- The public value xG will be expressed as explicit x, y coordinates.
- The shared secret value xyG (that is, the value we give to the sk generation function) will be only the x coordinate; the y coordinate will not be used.

Yes, this implies that doing point compression on the shared secret value doesn't make much sense (as point compression discards all but one bit of y -- the format that RFC5903 chooses already discards all the bits of y).  However, the argument about point compression was never about the shared secret value; instead, it was about the repesentation that appeared in the KE payload (that is, the one that is specified to have both the x and y coordinates).

As for Dan's question, it was about whether we should validate the public value we get from the peer, well, the public value does have explicit x and y coordinates, and so it makes sense to check them.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Friday, November 30, 2012 4:39 PM
To: Johannes Merkle
Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; [email-masked]
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

Hi Johannes,

Yoav

On Nov 30, 2012, at 7:57 PM, Dan Harkins <[email-masked]> wrote:

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

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 30 Nov 2012 14:09:07 -0800 (PST)

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

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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 30 Nov 2012 22:27:18 +0000

Right. I cut-and-pasted and didn't notice that it said "shared secret". Never mind. 

On Dec 1, 2012, at 12:00 AM, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:

> Email secured by Check Point