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

Dave Garrett <> Sat, 04 April 2015 01:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A91CB1A1A9A for <>; Fri, 3 Apr 2015 18:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mTpHXmz_0Tjh for <>; Fri, 3 Apr 2015 18:21:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 820BE1A1A88 for <>; Fri, 3 Apr 2015 18:21:09 -0700 (PDT)
Received: by qgfi89 with SMTP id i89so19911716qgf.1 for <>; Fri, 03 Apr 2015 18:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=i2QHbxef2mJwmo539Fc/5C/Ae4kYj6RWauzTfqFln9w=; b=d7oKpL+/V6wBmFszEedCI1sF/xZBwU8wGP7ItZYqe/2EA3TaMQx7YSCFb9/xDUbjuU xs/LU29A1cvuu8nGWtlXfi9c4ArMxByucM1CCUQA1/QxfQ7hq1xZfdMTs1IvvE0l0zH4 pwsJ5WjYbjVn6V2RiK9yvBS0y03u28dvEViFSNSfeqsKc3lFmwJQaKozalQBS/9DSTIZ vFN7K9FezwqsxgOQtzoD04tY3jPm4OXvDyWLb7CrFz4v7X0mfOJfdnOTP0I54e7Dqer4 JYphKuyN3AWJVsPCd4WxbyOr8W2y37QqFonrw8FC6YHLcZAMfqp8WP+Q5iCSqG2EjJkq 9N+g==
X-Received: by with SMTP id 90mr4766929qgi.87.1428110468774; Fri, 03 Apr 2015 18:21:08 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 10sm6806319qha.38.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 03 Apr 2015 18:21:08 -0700 (PDT)
From: Dave Garrett <>
Date: Fri, 3 Apr 2015 21:21:07 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
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 01:21:11 -0000

On Friday, April 03, 2015 08:18:34 pm Tony Arcieri wrote:
> On Fri, Apr 3, 2015 at 5:05 PM, Brian Smith <> wrote:
> > Please don't change the syntax for negotiating cipher suites. Although
> > it seems like a good idea
> Personally I think it's a great idea, and a pretty simple one and also an
> incredibly needed one. In fact, this post and its ensuing discussion
> actually made me excited about TLS 1.3:
> If you read through the suggestions, I think a new syntax could actually be
> backwards compatible in terms of computing the possibility matrix /
> combinatorial explosion of all authentication and (symmetric) encryption
> ciphers/ciphersuites.
> I think this sort of approach sorts out a lot of collusion and confusion
> (not in the Claude Shannon sense) which has been lingering in TLS for years.

On Friday, April 03, 2015 08:40:02 pm Martin Thomson wrote:
> On 3 April 2015 at 17:05, Brian Smith <> wrote:
> > I don't think the current mechanism is problematic
> > enough (at all, really) to justify that effort.
> I think that I've the same view.
> Then you have to consider interaction problems where some
> implementations have hardware for certain things, and software for
> others.  Not only does that produce strong preferences for some things
> over others, it also can lead to holes in support tables, making a la
> carte selection tricky.
> That was always the clincher for me.

After the initial discussion, the middle point between the current system and my initial "just dump it all in a pile" idea (which Nico more elegantly named a la carte), is just to split cipher suites into symmetric and asymmetric suites. The one for the handshake and one for the connection would be negotiated separately. This could work rather well without too much change.

That said, how much combinatorial explosion are we even dealing with anymore? We ditched all non-ephemeral handshakes. There's fewer variations now, at least at the moment.

A non-hypothetical example:

OCB wants to define in its current draft:

     CipherSuite TLS_DHE_RSA_WITH_AES_128_OCB = {TBD1, TBD1}
     CipherSuite TLS_DHE_RSA_WITH_AES_256_OCB = {TBD2, TBD2}
     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_OCB = {TBD3, TBD3}
     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_OCB = {TBD4, TBD4}
     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_OCB = {TBD5, TBD5}
     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_OCB = {TBD6, TBD6}
     CipherSuite TLS_PSK_WITH_AES_128_OCB = {TBD7, TBD7}
     CipherSuite TLS_PSK_WITH_AES_256_OCB = {TBD8, TBD8}
     CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
     CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}
     CipherSuite TLS_ECDHE_PSK_WITH_AES_128_OCB = {TBD11, TBD11}
     CipherSuite TLS_ECDHE_PSK_WITH_AES_256_OCB = {TBD12, TBD12}

If we just split handshake from connection, it would just be:

defined in TLS 1.3/2.0 spec:

     CipherSuite TLS2_DHE_RSA = TBD
     CipherSuite TLS2_ECDHE_RSA = TBD
     CipherSuite TLS2_ECDHE_ECDSA = TBD
     CipherSuite TLS2_PSK = TBD
     CipherSuite TLS2_DHE_PSK = TBD
     CipherSuite TLS2_ECDHE_PSK = TBD

(by the way, do we really want plain PSK?)

and OCB would only need to define:

     CipherSuite TLS2_AES_128_OCB = TBD
     CipherSuite TLS2_AES_256_OCB = TBD

That's already fewer suites. All new ciphers would only need to define one or two suites, as the 6 handshakes would be common to all. It'd be a hell of a lot easier to configure and negotiate into the future. We already add weird SCSV fake suites, so adding a few newly handled ones shouldn't break the world.

Just splitting it into only two parts would avoid the risk of support holes you'd get with the full a la carte route.

There's plenty of space in the registry to keep adding piles and piles of variations for each suite, but I have seen actual instances where a server and client actually do support the same handshake and connection ciphers in TLS 1.2, but don't negotiate it because the specific combination isn't listed. The current system does lead to some support holes as-is.