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

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