Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <> Tue, 15 March 2016 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D0B912DBA6 for <>; Tue, 15 Mar 2016 10:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u6THbgD8YIza for <>; Tue, 15 Mar 2016 10:37:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B38CC12DBA2 for <>; Tue, 15 Mar 2016 10:37:30 -0700 (PDT)
Received: by with SMTP id g203so32976470iof.2 for <>; Tue, 15 Mar 2016 10:37:30 -0700 (PDT)
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; bh=7lHYj9stey376+wMwembdj+ka8bPdueydQiJVj4Mjps=; b=RPNDP9xc1NejRfxcUVg7lqqpAt4g6I+/AA4b/X5pBxTO1We/cMxLpNoFAN6eQuAmXg +IumGuSoKAv8tYKdgw5uawgnGIGmhLzXjN16s4txw//sKSE5982mWTcXbhc3xrM7TTeJ iKd6Xs5+yHkMAQs/AvwVKEVqMYyu05GGnEcN0=
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; bh=7lHYj9stey376+wMwembdj+ka8bPdueydQiJVj4Mjps=; b=DXG3PehY2EDGKdt4+/1RZByZ8cnTJsmdYBB/Ej574dcMBm1VJ1EV3d0WQLQK0eslaK rx+b5TrYRGR1U9E/lZUDJ5+TyMUIl/CadHIMtJ4vniNzYEk5/8I0oncvd/IsVWv5WvuY hkQdtkI+Jcx5pXJV03MDSyRlS8g2fhvZMnwX2ZUtGNzy9hD6jHZli5wKHwX2zbSdLUiv 8149t3z8rjEb2MOSTbll8Qiw7XLL6t+Uyhg+dF32kcuxgS+oBlLyo7OAoA/SsPGTn0bh fCSBTyzUxA1d0ppAm4b/7Ptf72GeqfE7fEaAIT9Npca6ufVbyIYRFXR1e2stBCRfOOCQ fM2Q==
X-Gm-Message-State: AD7BkJJzLzFn/Q0mtZyaB65SFYRpUnOTetFJM6WeVe3QZ2mH3JlrtOcHhpHn5kAwohJ5xQyNW186snTwuDa88jYH
X-Received: by with SMTP id o134mr36840179ioe.62.1458063449483; Tue, 15 Mar 2016 10:37:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 15 Mar 2016 17:37:20 +0000
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=001a1141fb90f7ca83052e19d9ba
Archived-At: <>
Cc: ekr <>, "" <>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
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: Tue, 15 Mar 2016 17:37:33 -0000

On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <> wrote:

> David,
> Thanks for being patient with me here. Sorry it took so long
> As usual, this seems like a question of whether we're going to want a lot
> of flexibility
> (thus motivating orthogonal negotiation) versus whether we're going to
> want little flexibility
> (thus motivating suites). I think that with the historical practice, the
> arguments for orthogonal
> negotiation were a lot stronger, but now that we seem to be leaning
> towards (a) fewer algorithms
> and (b) having algorithms which are themselves suites, I do agree that the
> pendulum is swinging
> more towards suites.

I would probably characterize it less as suites vs orthogonality, but as
wanting to keep divisions in meaningful and universal places and not
splitting up tightly-coupled decisions. The flexibility from orthogonality
can be handy, but going too far---as I believe TLS 1.2 did with signature,
prehash, and curve---complicates everything. Imagine if negotiating
AES_128_GCM required separately negotiating block cipher AES-128, mode CTR,

On balance, I guess, I'm neutral-to-supportive of this change in general,
> if others in the WG want
> to make it. On the details:
> - It seems like we could let measurements tell us what code points we
> need. If we never see
>   P256-SHA512 in the wild, then we don't need it (and can add it later if
> needed).

I guess this relates to the fun issue of how TLS sigalgs interacts with
X.509. If we believe they are at most a hint for X.509, then I think we can
freely declare that TLS 1.3+ requires curve/hash matching for NIST curves.
Unlike PKCS#1 v1.5, I doubt anyone has smartcards that can only sign

If we believe that non-matching certificates are forbidden in TLS, then,
yeah, it's a concern. I searched CT logs some time ago and found some cases
of P384-SHA256, but that was it.

I went with the small set for the draft text since it's a little cleaner
and seemed to be what most preferred, but I would be fine with allocating
P384-SHA256 too. Or maybe all 6 non-truncating values. (Or even the full 9
from my original proposal but, as others pointed out to me, P256-SHA384,
P256-SHA512, and P384-SHA512 are kinda silly.)

- I took a quick look at the PR and I'm not sure that some of the code
> points assignments are
>   right. I made comments.

Fixed those. Apparently I shifted most of the hashes by one. Sorry about

> - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll
> probably want to define
>   code points for 1.5 in both in-protocol (CertificateVerify) and
> certificates to distinguish these.

Oh? Why would they need to be separate? The others defined for both aren't.


> As far as process, it seemed like people were generally positive about
> this in this discussion,
> but I'll rely on the chairs to determine consensus.
> -Ekr
> On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin <>
> wrote:
>> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <> wrote:
>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <>
>>> wrote:
>>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <>
>>>> wrote:
>>>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In
>>>>> TLS
>>>>> > 1.2, signature algorithms are spread across the handshake.
>>>>> [...]
>>>>> > I propose we fold the negotiable parameters under one name.
>>>>> [...]
>>>>> > 2. Remove HashAlgorithm, SignatureAlgorithm,
>>>>> SignatureAndHashAlgorithm as
>>>>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate
>>>>> that
>>>>> > instead.
>>>>> I previously proposed this here:
>>>>> ekr was against it, though it hasn't been discussed that throughly.
>>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and
>>>> forgot.
>>>> ekr, are you still against this sort of thing? I think the new CFRG
>>>> signature algorithms tying decisions together is a good argument for why
>>>> we'd want this. If we believe this trend is to continue (and I hope it
>>>> does. Ed25519 is a nice and simple interface), trying to decompose it all
>>>> seems poor.
>>> I'm not sure. I agree that the CFRG thing seems to be a new development.
>>> I'll
>>> try to confirm my previous opinion or develop a new one over the weekend
>>> :)
>> ekr, did you have confirmed or new thoughts on this change?
>> From elsewhere in the thread, I put together a draft PR if you wanted
>> something to look at in that form.
>> It incorporated some of the suggestions in the thread (not mentioning the
>> really legacy values, pairing NIST curves with hashes, etc.), but that's
>> not the important part. The meat of the proposal is unifying signature
>> algorithms under one number and a shared interface, which I think is a
>> valuable simplification.
>> David