From: Dan Brown <dbrown@certicom.com>
To: 'Johannes Merkle' <johannes.merkle@secunet.com>,
 "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt
Thread-Index: AQHOP4oAIiS+sFdG0kqWmTRP6ozCHpjkV3mA///GaUA=
Date: Tue, 23 Apr 2013 18:34:31 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF51437D8@XMB111CNC.rim.net>
References: <20130422184745.13680.44055.idtracker@ietfa.amsl.com>
 <5176C7B9.50001@secunet.com>
In-Reply-To: <5176C7B9.50001@secunet.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt
Precedence: list

Johannes,

Good catch. This probably requires a clarification.

I would suggest that the existing formats (x,y) of the correct length imply=
 a point in the finite plane, and in particular not the point at infinity. =
 In other words, whatever length-checking that peers currently use probably=
 suffices to check for this condition of not being the point-at-infinity.

I disagree that (x,y)=3D(0,0) should be interpreted as the point-at-infinity=
.  I advise against a separate check for this, and instead to rely on the le=
ngth-check and the curve equation-check.

Elliptic curves exist, e.g. y^2 =3D x^3 + x, for which (0,0) is a point on t=
he curve, but the point (0,0) would have order two, so would normally be con=
sidered invalid (excluded by a cofactor check etc.).

In the SEC1 format that you mention, which is similar to the IEEE and ANSI f=
ormat, the 00 encoding occupies the initial octet position.  This first octe=
t acts like a tag, and takes a non-zero value when the point is on the finit=
e plane.  It seems that IKE does not use this tag octet.

Best regards,

Dan

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Johannes Merkle
> Sent: Tuesday, April 23, 2013 1:41 PM
> To: ipsec@ietf.org
> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt
> 
> I hope I am not too late as the document write-up has already been sent
> out.
> 
> Section 2.3 specifies:
>    A receiving peer MUST check
>    that its peer's public value is valid; that is, it is not the point-
>    at-infinity, and that the x and y parameters from the peer's public
>    value satisfy the curve equation, that is, y**2 =3D x**3 + ax + b mod
> p
> 
> How can a peer check this? I am not aware of any encoding rule for the
> point-at-infinity in RFC 5903 or RFC 5114. Does
> the encoding of SEC1 apply, where the point-at-infinity is encoded to
> 0x00? According to RFC 5903 this would be padded
> with zeros, so that the decoding algorithm of the receiving peer would
> obtain x=3D0 and y=3D0. These do certainly not
> fulfill the curve equation as the discriminant -16*(4*a^3 + 27*b^2)
> must be non-zero.
> 
> So isn't the requirement to check that the value it is not the point-
> at-infinity confusing and redundant?
> 
> Johannes
> 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the IP Security Maintenance and
> Extensions Working Group of the IETF.
> >
> > 	Title           : Additional Diffie-Hellman Tests for IKEv2
> > 	Author(s)       : Yaron Sheffer
> >                           Scott Fluhrer
> > 	Filename        : draft-ietf-ipsecme-dh-checks-03.txt
> > 	Pages           : 11
> > 	Date            : 2013-04-22
> >
> > Abstract:
> >    This document adds a small number of mandatory tests required for
> the
> >    secure operation of IKEv2 with elliptic curve groups.  No change
> is
> >    required to IKE implementations that use modular exponential
> groups,
> >    other than a few rarely used so-called DSA groups.  This document
> >    updates the IKEv2 protocol, RFC 5996.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-03
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-03
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> 
> --
> 
> Mit freundlichen Gr=FC=DFen,
> Dr. Johannes Merkle
> Principal Beratung, Elektronische Identit=E4ten
> Public Sector
> secunet Security Networks AG
> Mergenthaler Allee 77
> 65760 Eschborn
> Germany
> Telefon +49 201 54 54-3091
> Telefax +49 201 54 54-1325
> Mobil   +49 175 2224439
> johannes.merkle@secunet.com
> www.secunet.com
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.