Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <> Tue, 19 January 2016 22:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 897021B36E2 for <>; Tue, 19 Jan 2016 14:08:58 -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 8njQv8m96UKd for <>; Tue, 19 Jan 2016 14:08:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 758FC1B36E1 for <>; Tue, 19 Jan 2016 14:08:55 -0800 (PST)
Received: by with SMTP id 1so419776ion.1 for <>; Tue, 19 Jan 2016 14:08:55 -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=r1+UBkCjdQvVtQ573IjKRt/i30ZvyRA0vrfsICDMRQE=; b=Bgh1+OkimOZnNPhMD5KK+d+ST2iAuOFw3wWW5mPEKkSYQ8cgFIWvadjVdd3tl/IyLB D2F83Bw5bBtJWUAMAZnZ8o4CEPorUSHp/om6sEHckXYTJxWejyUZ26f2pkTJ7MI5Uvqx T8Y5vCu/Qv/aiGGME2RR1pJqCLvABIjCV6jQw=
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=r1+UBkCjdQvVtQ573IjKRt/i30ZvyRA0vrfsICDMRQE=; b=XOCWjZ4h/ys/VW/qL01vQ+xDMoCTFALGrX8AbBcyJZLth2dOzMXXmSv+ifyUHeebId rzdBOfpqeV+WF3O/2/H8PaJJWgnVA9XExOX9EC4oXbBG5yc4wfMcnkb8YFC4KN3V0ff7 UwKz1PGvmM3riviXHTNFJybVsRpx0H8rJMSDh1YBpBwgQqQAShvIi6ozdMuy4wiEwIXG fmSLntveVj/5BzBLA75Yl5bcJvP62t67MBqkOQDE+XhK5PA7a8lIt+AQnYrXqGauYHAm GMgjAHNKAwAMRd1bKtcKRMLks9y6wuYv19/1opA+RCNGRQDBdQA4vKYXstx26Qk+cwIq tntg==
X-Gm-Message-State: ALoCoQmmGuFnYT48d/83FNVkA11m9Bt5Zfu42s+yjI5KPT1Hi+D64+dQw5Dx5W9Hiy7vkSb2AbSDjvr0BD8M2zuOAiL8LNMGKjLLFulLY9gxctl3gAspLZQ=
X-Received: by with SMTP id s85mr34767917ios.62.1453241334747; Tue, 19 Jan 2016 14:08:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 19 Jan 2016 22:08:45 +0000
Message-ID: <>
To: Brian Smith <>
Content-Type: multipart/alternative; boundary=001a113a033c8819320529b71d38
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: Tue, 19 Jan 2016 22:08:58 -0000

On Fri, Jan 15, 2016 at 10:13 PM Brian Smith <> wrote:

> David Benjamin <> wrote:
>> (Whether such certificates exist on the web is probably answerable via CT
>> logs, but I haven't checked.)
> Me neither, and I think that's the key thing that would need to be checked
> to see if my suggestion is viable.

Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more
often than not.

But it's not actually all that many hostnames (all of which presumably
don't speak TLS 1.3 yet), the existing semantics of TLS 1.2 won't change,
and whether sigalgs are stronger than a hint w.r.t. X.509 is...
controversial. I wasn't able to find anyone else doing it. So +1 from me on
dropping the 3x3 product to just the three you listed.

I'm less confident about the consequences of reusing the TLS 1.2 ecdsa_*
allocations, but I can't think of any weird behaviors, so it seems

(The one thing I can think of is requires we keep ecdsa_p384_sha256. Then a
client wishing to advertise ecdsa_p384_sha256 and not ecdsa_p256_sha256 and
yet still speaking TLS 1.2 would have problems. But if we're actually
limiting to those three, that can't happen anyway, and this hypothetical
client seems pretty weird.)

If other people still want to allow ecdsa_p384_sha256 and friends, I'm also
happy with allocating 6 values and throwing out
ecdsa_p256_sha384, ecdsa_p256_sha512, and ecdsa_p384_sha512.