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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 13 January 2016 11:01 UTC

Return-Path: <alexey.melnikov@isode.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 305141A6F52 for <tls@ietfa.amsl.com>; Wed, 13 Jan 2016 03:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 aPd0RGbboCD5 for <tls@ietfa.amsl.com>; Wed, 13 Jan 2016 03:01:12 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id F30DF1A6F49 for <tls@ietf.org>; Wed, 13 Jan 2016 03:01:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1452682870; d=isode.com; s=selector; i=@isode.com; bh=1CJM2XYYlR684STh5LgyyrDcrBgAD3kmEC3TGbIm+dc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=l72zW3ShAsPPAIwOUuSzqDEyzLX2Emn+zWcSbnB3Dz7Hk67PZ/9jKPfrW41iFD1zndY/wy b6NMmfuuE6FcdgsMBm4cXy26coPOO2QvEsYMBkMNaIiAWedwnX1qzLQt4wExnkUkWzXojG jAt2oRLD17D3bbssTAAwtauMAuAUfXM=;
Received: from [172.22.50.30] ((unknown) [62.232.206.186]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VpYudgAbMBZ=@waldorf.isode.com>; Wed, 13 Jan 2016 11:01:10 +0000
X-SMTP-Protocol-Errors: NORDNS PIPELINING
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (13C75)
In-Reply-To: <20160112213145.GA17156@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Wed, 13 Jan 2016 11:04:37 +0000
Message-Id: <EC2DC5C0-1E4D-4FD8-AB1A-4FC6BDF4ED36@isode.com>
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>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Simon Josefsson <simon@josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/yEMb8LkVszr71zr5-HWBUpzCybE>
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: Wed, 13 Jan 2016 11:01:14 -0000

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