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

Yoav Nir <> Tue, 07 April 2015 05:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF2CD1B31AA for <>; Mon, 6 Apr 2015 22:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qfuKIDZkQ0CZ for <>; Mon, 6 Apr 2015 22:51:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8913B1B31A9 for <>; Mon, 6 Apr 2015 22:51:29 -0700 (PDT)
Received: by wgyo15 with SMTP id o15so33776183wgy.2 for <>; Mon, 06 Apr 2015 22:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hSY08MvdOkjqWeP4kk2h8qyRpb9eGyjT3elwRc5rKBY=; b=NBI0uT/hfydJA9CzoX6oBCPRlRmD1Oqz6WJNvCY0bhCFCKvz2TghQcXHt9vzfz+NuG Qr1snvciC+TPGWfbLIk58fMU/i8BSdIuSwokk5TMbTQEN8MgsDw0JjVSrklyVexn9sDw p0x7anOujR86d7qi86Bs/g7MWOOE3khzokxk8cfPoe3tSCKEQMLscQlfg0sSOA6KoQjK UZsuThCfWqZWHeoOhdw3cWunYhWb6DvjFvOgL9xmSY1JBcclUQkxh5lFYfh4jxAum9JH uQVjMFnAkCX776ENhs0nhsluR2RYGUfCgaPAVLofM23AdLDk502BQuBhW2F9hTgMgM1S j9bA==
X-Received: by with SMTP id ju2mr28723920wjc.61.1428385888243; Mon, 06 Apr 2015 22:51:28 -0700 (PDT)
Received: from ([]) by with ESMTPSA id hw7sm9324670wjb.24.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Apr 2015 22:51:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A987AA6-2287-4CD0-A808-3EDA7A45B16D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Tue, 7 Apr 2015 08:51:22 +0300
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Tony Arcieri <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
Cc: "<>" <>
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: Tue, 07 Apr 2015 05:51:32 -0000

> On Apr 7, 2015, at 6:25 AM, Tony Arcieri <> wrote:
> On Sat, Apr 4, 2015 at 4:55 PM, Salz, Rich < <>> wrote:
> > Please don't change the syntax for negotiating cipher suites.
> +1, for the reasons Brian said.
> Looks like the opinion of TLS implementers is this far unanimously against this proposal. I would like to give the counterpoint from a TLS user perspective.

I’m a TLS implementer and I kind of like a-la-carte, but wouldn’t mind either way. Might have something to do with me having been an IKE implementer before I was a TLS implementer.

> I am more or less in charge of the ciphersuite selection for a large web site with a lot of users. I find the present means of describing ciphersuites to TLS stacks to be difficult at best. As myself and many others have described, we're essentially being asked to compute the combinatorial explosion of different ciphersuite configurations by hand. Guess what happens when you do that? People make mistakes. I think the TLS libraries should have an easier-to-use configuration format that computes things for me so I don't have to. I understand why TLS implementers are reluctant to provide that. It's more work for them. But so far none of them have said why this is qualitatively bad.

This is about UI, not about wire format. I totally agree that the OpenSSL string format for specifying ciphersuites is a horrid mess, but nothing is stopping an implementer from creating an a-la-carte UI and translating the user preferences to a combinatorial explosion on the wire.

> The proposed approach of splitting up what is more or less key exchange vs symmetric cipher configuration (please excuse that rough description, I know how deep the rabbit hole under this bikeshed goes) and require you specify both parts in order of preference sounds like it should fit within all of the existing TLS configuration frameworks and notations. People would only use the new syntax with TLS 1.3+ compatible libraries, and it should be fully backwards compatible with the old one.

So sure, UIs range in sophistication from a set of radio buttons labeled “secure”, “not so secure”, and “not secure” to a list of ciphersuites, each with a check box next to it, and those kind of UI choices can be expressed in string configuration as well. 

> I also think that requiring this sort of configuration could help designers TLS tease out these concepts internally so they aren't colluded into an amorphous mush of algorithms, every possible combination of which a TLS deployer is expected to whitelist.

I think implementers understand what goes on behind the long list of ciphersuites.

> Seems like a huge win to me. So what's the problem from an implementer perspective besides "it'd be hard”?

There’s always that fear that some combination of algorithms will turn out to be not secure, while other combinations of each of those algorithms will be fine.