IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Tue, 12 January 2016 20:21 UTC

Return-Path: <ynir.ietf@gmail.com>
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 39B781A886E for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 12:21:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 aO_RHy8GmyYQ for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 12:21:27 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938AB1A887C for <tls@ietf.org>; Tue, 12 Jan 2016 12:21:27 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id u188so271215685wmu.1 for <tls@ietf.org>; Tue, 12 Jan 2016 12:21:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=LwiW77vZbEsiT4mUs+B0mJua9OHjGKbQhBBQsuU/hB0=; b=Y4D85UtfKhN6av4tieAlW61HR8xQz6zozHq8/od7DodDL06Nuy5aN18N3PDcneXrW4 HL2g2uD0lpYm9JOFNthUmHQ94HbImHCz+Wj5iBZPLKzjgrnwPKm3qDYYopG3H49UgjNt eKYRP3NKJWGlgIfSPzWLi0hFVnCwM9T4edpALD6eem4m0YLn7Fj/UVx43MmZgxQMHYW0 I4ci2hQ6HihP2P0ThYZXmWrY0Zv5gFBym6Z2/dRYPWP7ABM/kW86Yo757qLvxue9yvyd g52MEf+vH8D3D69f/TmpIkU3xegm9H0JeyIkj9wEUKyPryDQysaeCbpX984eUAbzMp1M nflQ==
X-Received: by 10.194.205.103 with SMTP id lf7mr139703659wjc.147.1452630086150; Tue, 12 Jan 2016 12:21:26 -0800 (PST)
Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id u191sm16517811wmd.4.2016.01.12.12.21.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jan 2016 12:21:24 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3145C0EC-89E3-4FA3-ABFB-733AC045F894"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20160112202611.187f8263@latte.josefsson.org>
Date: Tue, 12 Jan 2016 22:21:21 +0200
Message-Id: <3B7B953C-C6B4-433A-A645-AA26446472B8@gmail.com>
References: <39175FA5-0D33-43FC-B315-372A0C62B08C@tableau.com> <20160112202611.187f8263@latte.josefsson.org>
To: Simon Josefsson <simon@josefsson.org>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/uFgm7zV64_gjayjZQcPjyj0u04o>
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 20:21:29 -0000

> 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.

Yoav

v2.23.0 | Report a Bug | By Email