Re: [TLS] Ala Carte Cipher suites - was: DSA should die

Viktor Dukhovni <> Sat, 04 April 2015 15:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4501A1B2BDA for <>; Sat, 4 Apr 2015 08:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zDvKaCvXGSIg for <>; Sat, 4 Apr 2015 08:52:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DC531B2BD2 for <>; Sat, 4 Apr 2015 08:52:20 -0700 (PDT)
Received: by (Postfix, from userid 1034) id ACA9B283032; Sat, 4 Apr 2015 15:52:18 +0000 (UTC)
Date: Sat, 4 Apr 2015 15:52:18 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die
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, 04 Apr 2015 15:52:21 -0000

On Sat, Apr 04, 2015 at 06:52:50AM +0200, Aaron Zauner wrote:

> I actually really like the idea. But there're a couple of open questions
> to that;
> What happens to existing ciphersuites?

Those that are strong enough to survive into TLS 1.3 are subsumed
by the new ala-carte choices.

> And given we switch to a
> model of asymmetric and symmetric ciphersuites: (how) do we document all
> the implicit ciphersuites that are defined once a new symmetric or
> asymmetric algorithm is defined?

There's no need to document the "cross-product", just document the
inputs.  Making it a cross-product fills in gaps, for example,
there are at present no AECDH (key agreement) plus AEAD (symmetric
bulk crypto) ciphersuites.

Note that digests play a role in both the handshake and in the bulk
crypto MAC.  

For the handshake, there's the digest used in certificates (which
seems odd to negotiate as it is I think rare for either end to have
multiple variands of a given certificate chain with different
digests).  There's also the digest used for key derivation.

If the leading proposal is to go with 2 axes for the cross-product,
then I would fix the key-agreement PRF in each handshake type, and
use the supported digests extension as a "hint" to the peer to aid
in certificate selection.  I say "hint", because the peer will do
its best to send a suitable chain, when it has more than one, but
typically such "hints" are not particularly effective, and the peer
may as well use whatever it has.

For example, with DANE-EE(3) the signature of the peer certificate
is never checked and is irrelevant.