IETF Logo Mail Archive

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

Simon Josefsson <simon@josefsson.org> Thu, 14 January 2016 15:14 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 74BCA1B3562 for <tls@ietfa.amsl.com>; Thu, 14 Jan 2016 07:14:47 -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 DA8y5PJXB7Ms for <tls@ietfa.amsl.com>; Thu, 14 Jan 2016 07:14:45 -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 387E61A9045 for <tls@ietf.org>; Thu, 14 Jan 2016 07:14:44 -0800 (PST)
Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id u0EFERU1006761 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 14 Jan 2016 16:14:28 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Joseph Salowey <joe@salowey.net>
References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org> <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com> <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi> <EC2DC5C0-1E4D-4FD8-AB1A-4FC6BDF4ED36@isode.com> <CAOgPGoBMJKTijFmzsjYHxBCBJN-f+zfk5PCcwGGuo8XZPnHX6g@mail.gmail.com>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:160114:joe@salowey.net::qiZU+QxgE0FjE0bU:1/ea
X-Hashcash: 1:22:160114:agl@imperialviolet.org::kpuApEcP4mL3e3b4:1zyx
X-Hashcash: 1:22:160114:tls@ietf.org::7Hlivvx5Q+q4Ar3e:AQ57
X-Hashcash: 1:22:160114:alexey.melnikov@isode.com::dZVII910GQpwBr6k:KLP9
Date: Thu, 14 Jan 2016 16:14:26 +0100
In-Reply-To: <CAOgPGoBMJKTijFmzsjYHxBCBJN-f+zfk5PCcwGGuo8XZPnHX6g@mail.gmail.com> (Joseph Salowey's message of "Wed, 13 Jan 2016 08:40:29 -0800")
Message-ID: <8737u0gpm5.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; 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/x3O0WKO2ElUTgTg7oxqYr_n35z0>
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: Thu, 14 Jan 2016 15:14:47 -0000

Allocating a code point for X25519 could be done and is long overdue
(first draft September 2013).  X448 is also stable.  Code points for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.  I agree with Yoav's
assertion that the curve point verification issue is not big enough to
stall code point allocation.

/Simon

Joseph Salowey <joe@salowey.net> writes:

> Hi All,
>
> Looks like I jumped too soon on this one.  In particular, both the CFRG
> signature draft and 4492bis need to be updated.  Let's hold of on code
> point assignment until then.
>
> Thanks,
>
> Joe
> (crawling back under my rock now)
>
> On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov <alexey.melnikov@isode.com>
> wrote:
>
>>
>> > On 12 Jan 2016, at 21:31, Ilari Liusvaara <ilariliusvaara@welho.com>
>> wrote:
>> >
>> >> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:
>> >>
>> >>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson <simon@josefsson.org>
>> wrote:
>> >>>
>> >>> The same concern still applies: what does it mean to allocate code
>> >>> point for the 4492bis-05 description?
>> >>
>> >> Allocating code points just means an implementation of draft-05 is
>> >> likely to interoperate just fine with an implementation of the final
>> >> RFC.
>> >>
>> >> Of course nothing is ever final until the RFC is out, so there’s
>> >> always a risk involved, but it is considered prudent to allocate
>> >> numbers when we’re reasonably certain of the calculations and on-
>> >> the-wire formats. Any debate about whether we should or should not
>> >> check certain inputs for certain conditions need not be a bar for
>> >> allocating numbers.
>> >
>> > Assuming CFRG chairs really did declare consensus on Ed448 hash, then
>> > the final characteristics of Ed448 are known and I have a reference
>> > implementation.
>> >
>> > And the PKIX draft looks implementable (has wrong example?)
>> >
>> > More serious interop hazard is what to do with X25519/X448 and THS
>> > (some of the proposed stuff is not wire-compatible).
>>
>> This CFRG co-chair would like to see an updated CFRG draft before the code
>> point is allocated.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email