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
