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

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

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: 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
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>