IETF Logo Mail Archive

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

Simon Josefsson <simon@josefsson.org> Tue, 12 January 2016 19:26 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1821F1A8738 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 11:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHYRXmWQ6KVe for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 11:26:32 -0800 (PST)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF091A8737 for <tls@ietf.org>; Tue, 12 Jan 2016 11:26:31 -0800 (PST)
Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u0CJQIAT009221 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 12 Jan 2016 20:26:19 +0100
Date: Tue, 12 Jan 2016 20:26:11 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Joe Salowey <jsalowey@tableau.com>
Message-ID: <20160112202611.187f8263@latte.josefsson.org>
In-Reply-To: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com>
References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; boundary="Sig_/3prkEI/C6Gc+IQCqGdFk+vL"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/DEl2GoEMMpkzG9NWj2GcGxP1R2U>
Cc: Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2016 19:26:35 -0000

The same concern still applies: what does it mean to allocate code
point for the 4492bis-05 description?  The document currently says to
reject invalid ECDH keys, but I believe we want to remove that text.  We
could ask Yoav to issue a 4492bis-06 quickly that fix this issue, and
then proceed with early code point allocation.

Further, I believe allocating code points for Ed25519/Ed448 is premature
since 1) the CFRG draft on Ed448 is not updated, and 2) 4492bis-05 does
not contain sufficient detail to implement EdDSA authentication in TLS.
See draft-josefsson-tls-eddsa2-02 for some discussion to make EdDSA
work in TLS, as it relates to PKIX handling as well.

To be clear: I support allocating a code point for X25519 as described
in 4492bis with the relaxed public key check.

/Simon

> Whoops, thanks for the correction.  It should be the code point
> assignment in draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448,
> Ed25519 and Ed448. 
> 
> Thanks,
> 
> Joe
> 
> 
> 
> 
> 
> On 1/12/16, 6:24 AM, "Simon Josefsson" <simon@josefsson.org> wrote:
> 
> >Adam Langley <agl@imperialviolet.org> writes:
> >
> >> Curve25519, as the name suggests, operates on 255-bit numbers. When
> >> encoded as bytes, there's obviously a 256th bit that needs to be
> >> specified.
> >>
> >> Curve25519 implementations didn't set the bit but did used to vary
> >> on how they parsed it. Some would take a 256-bit number and reduce
> >> it while others would ignore the bit completely.
> >>
> >> However, I believe that implementations have converged on ignoring
> >> it. That behaviour is specified in draft-irtf-cfrg-curves and
> >> tested via the test vectors.
> >>
> >> Currently
> >> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
> >> says that implementations SHOULD reject inputs with the high-bit
> >> set. I think that should be dropped. The X25519 function is
> >> specified in terms of bytes in draft-irtf-cfrg-curves and I think
> >> the TLS spec should just use that draft.
> >
> >I agree.
> >
> >/Simon

v2.23.0 | Report a Bug | By Email