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