Re: [TLS] PR #23 for RFC4492bis

Yoav Nir <> Mon, 04 July 2016 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5560F128E19 for <>; Mon, 4 Jul 2016 11:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kCMV_q9e6Wip for <>; Mon, 4 Jul 2016 11:23:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17D53128E18 for <>; Mon, 4 Jul 2016 11:23:37 -0700 (PDT)
Received: by with SMTP id a66so125095336wme.0 for <>; Mon, 04 Jul 2016 11:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Gj1Y3NVNecWP2/GrpJwJiebFJxiaPdOkigk0ukFaP4w=; b=n+P4znwpM1MS9t//sbs+TMxU4enbMjuo9nnt/93nE27B/A53M4Yaj8NndQg4WVSYlI XDVB8BrgzxjIRwt27NBFljfoycnT7msHU7LEVIU5EI5Fgu+TFhD26EXaths/fhhqXD7r eQVX1FK6/R8NIQhRpnGVK+rgig+WDZA9kH9AGYGf/Z7YX+1Mwkfjbad6bVzpSFd8lgMQ YucTpWe1HiGJNxSEQGlJUhegHqPZFm36jWoBrV8ln8LKGhQeljO33MSSp/VT3KPj7blE jR0Csv213c4CqN6lmgntojQrbktsVWGhxNA2gy4+Lu4ZR6DZLKJ1vBuMYAYtXwI7txS9 ne1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Gj1Y3NVNecWP2/GrpJwJiebFJxiaPdOkigk0ukFaP4w=; b=hQMTPH1gxDSiBHeII74znbIzOeY9DJsFheoKdmA5FlUPBHz4eNqZz7cb24z25K2tqT wY2FuvlLooBZ84V6g0+MqPdRGszDNdxijWOfmW9dNOQYbakrV/CExfTEqAmuXsoiZp8+ KfOq3G4cu1w1X/Ty3gfKErkksc2JlzbktSSVDyG1e0u3gOp1++isxACUAOUOCelNS5zF J08BgmdZ5IjjgM+3Vmili4rQsP40Oh5jRxKFcQI7EgFyVFaBn6pxHzyT8W7I/sAUnOOH sJIKGrnG5/i7LkTwg1WMa1fySkkXF9l195vcKCt5deb3mHOA4SIOgIbd3KMsYqPRcKxn 3PIg==
X-Gm-Message-State: ALyK8tKRiv2ScFijR9CiiyMlOgEhIxu0hrVZ7SPGhp2lr3HUFcJ8oQhQFKzXxhKvWQYtLQ==
X-Received: by with SMTP id g190mr12722826wme.2.1467656615571; Mon, 04 Jul 2016 11:23:35 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id zj2sm3404101wjb.25.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jul 2016 11:23:34 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9E85DF5C-9DA0-4005-93F6-00499D691A15"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 04 Jul 2016 21:23:32 +0300
Message-Id: <>
References: <> <> <> <>
To: David Benjamin <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] PR #23 for RFC4492bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jul 2016 18:23:39 -0000

> On 4 Jul 2016, at 7:12 PM, David Benjamin <> wrote:
> On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir < <>> wrote:
> > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara < <>> wrote:
> >
> > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote:
> >> Hi
> >>
> >> Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted a PR.
> >>
> >> <>
> >>
> >> If there are no objections, I will accept it and submit version -08 this Friday.
> >
> > While scanning through, I noticed that the Ed25519 and Ed448 "curves"
> > are still there. I think negotiating those should be done the same way
> > as in TLS 1.3 (those would then appear as hash=7 signature=3/4 IIRC).
> IMO this makes it very complex. TLS 1.3 replaces the old signature_algorithms extension that had pairs of signature algorithm/hash algorithm with one that has 16-bit values.
> It changes things for ECDSA as well. We’re not going to change ECDSA in TLS 1.2. So if we wanted to adopt that we would still interpret 0x04,0x03 as ECDSA (with whatever curve) along with SHA-256, while 0x07,0x03 would be Ed25519, not ECDSA with some unknown hash function 0x07.
> Seems strange to me, but I’ll make whatever changes the group wants.
> Oops, I think I agreed to backport this at IETF 95 and completely forgot. Sorry about that! My bad.
> Although, thinking about it now, I'm not sure if we should bother. As you mention, it's weird since ECDSA still needs to be interpreted in the 1.2 style, despite being spelled in the 1.3 way. We'd also end up with the new scheme being defined in two places.
> It seems better to get X25519 / X448 out the door first as that has no prerequisites. X25519 in TLS already has running code today. Chrome ships it, and Google servers have it enabled. The 1.1.0 release of OpenSSL is also slated to have support.
> Ed25519 / Ed448, on the other hand, don't even have an embedding in X.509 yet (though hopefully the main question remaining will get resolved in curdle soon). Then there's the timeline for draft-irtf-cfrg-eddsa, which I'm not familiar with. New signature schemes also depend on CAs being willing to sign them which, for the web PKI, I expect will not be fast. Saying new signature schemes are only defined for 1.3 and up seems reasonable enough to me, though I suppose it depends on how the timelines for all the other drafts end up looking.

The CFRG draft is not the limiting factor. We’re waiting for draft-ietf-curdle-pkix-00. 

But honestly, I don’t think anyone is going to be issuing EdDSA certificates any time soon. The commercial CAs have just recently starting using ECDSA, and even for local CAs you generally don’t use a new algorithm until every relying party in your environment supports it.