Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <> Sat, 16 January 2016 01:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D5C8D1B34BD for <>; Fri, 15 Jan 2016 17:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P_FuHEamsZA6 for <>; Fri, 15 Jan 2016 17:10:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D79B41B2B0C for <>; Fri, 15 Jan 2016 17:10:16 -0800 (PST)
Received: by with SMTP id z14so24482706igp.0 for <>; Fri, 15 Jan 2016 17:10:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=T3HONsypk3ARvlaRWr0ZMOINrWPTrzEZX07P87Ic4pI=; b=T569sDQd9m7t8oGPVQ1dQmmuG/V3+9XSA747pWmcZEawYD7Hxg5j0cBEPEKi3/XSTZ V+7xEh2/n7XVx+fq6gIRM+cQ2xmjbb+/TB0UtMcCa4jBnWozJvx3yFpQ1rE6oyVcTzsE jHR7hXRWs5EfHt4T47igsfU+GaYRVmmJ4jr2Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=T3HONsypk3ARvlaRWr0ZMOINrWPTrzEZX07P87Ic4pI=; b=PB/KXGJOb2BZjmk+VdLVuxHhj2JWy0//5PtAj34F7oSRDWZgIZutOq3ZyFAHMoI/yO 2AMF0rZCs0ZnvD/gVNYcdVx1Ve4KveGLnlYCZ+1vI/HyNWFtXFjv8VfN7rJ7XUZm6pD/ R1FSLzWcJPY08RNOsgNulDDEkjgzKSaHQCOeDY8oY6yqhvs+jKNUCD7OkUYc19hcXROK vdYtLNV1WETMX139ghPMQqnG4JU9tl/Yx6yzzlPz8k4+BbxqydRGAvwmIv6hn81DgVQL OyZbPQJMEjVB66mp7gk5KlT7AmeRawQC6B78d8HxAON+UCZK4buywTHOqvKCZF4tJ/2X OSdg==
X-Gm-Message-State: AG10YORGAOxnEI8uLuLZqqE4331uMkYLpglNv8h6DAhkdFE844nSjqD266/Ce6ipz3ocMFdcVJBjOh19ttjfvDRC
X-Received: by with SMTP id pk1mr1365490igb.11.1452906616225; Fri, 15 Jan 2016 17:10:16 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Sat, 16 Jan 2016 01:10:06 +0000
Message-ID: <>
To: Brian Smith <>
Content-Type: multipart/alternative; boundary=047d7b2e3fe6c0b0e20529692ee5
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Jan 2016 01:10:19 -0000

On Fri, Jan 15, 2016 at 7:08 PM Brian Smith <> wrote:

> David Benjamin <> wrote:
>> 4. Deprecate ecdsa_sha256, etc., in favor of new
>> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
>> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
>> introduces new premultiplications, it’s only 9 values with the pruned TLS
>> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
> Have you considered the possibility of using this mapping?:
> TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
> TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384.
> TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521.

> Then:
> 1. You don't have to define any new values.
> 2. The extension size would be smaller.

Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
lose them. I just wrote out all 9 without thinking about it much. Apart
from "please don't cause me interop pain", I don't have strong opinions
about how aggressively we prune the list.

My main worry is, for better or worse (I realize this is a point of
contention), some servers apply sigalgs to both CertificateVerify and
certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the
definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a

Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though
it would prevent them from adopting TLS 1.3 without switching certificates.
Alternatively, if people decide that sigalgs and certificates officially
have nothing to do with each other in TLS 1.3, then things are fine but we
wouldn't have a way to negotiate such algorithms. I was hoping to avoid
that issue for this proposal, but there is some interaction.

(Whether such certificates exist on the web is probably answerable via CT
logs, but I haven't checked.)

If changing the existing meaning is a nuisance, another option is to
continue to allocate new values but only define ecdsa_p256_sha256,
ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
is) for TLS 1.3 and later.

> 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
> (I don't have any particular affinity for that profile other than it seems
> to have made choices that have historically been shown to be above average,
> and it might be a good idea to avoid interop failure with other
> implementations that might have a special affinity for it.)

What interop faliures are you worried about here?

> - ecdsa_p256_sha384
>> - ecdsa_p256_sha512
>> - ecdsa_p384_sha256
> - ecdsa_p384_sha512
>> - ecdsa_p521_sha256
>> - ecdsa_p521_sha384
> The subset of your proposed values I listed above do not seem helpful. For
> example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get
> truncated to 256 bits.

Good point. That makes some of the combinations unlikely.

> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
>> RSA}, they should ignore it since hash 7 doesn't exist.
> I think we should expect more pure ECC (no RSA) deployments soon. In that
> case, it would be better if new ECC-based values used the value "ECDSA" (3)
> instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them
> as support for RSA.

Sure, if you like, read my sentence replacing '1' with '3' and 'RSA' with
'ECDSA'. The same footnote applies. :-)

I don't think it makes sense to strategically assign the second byte for
new numbers. Either we believe TLS 1.2 implementations are unlikely to
react to 0x0703 and not worry about it, or we believe they will and we
reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to
u16 hack is too silly and don't do it at all.)