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

Tony Arcieri <> Tue, 07 April 2015 03:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B93BF1B30DE for <>; Mon, 6 Apr 2015 20:25:25 -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 UDpYud6quE7H for <>; Mon, 6 Apr 2015 20:25:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9ED591B30D6 for <>; Mon, 6 Apr 2015 20:25:23 -0700 (PDT)
Received: by obbfy7 with SMTP id fy7so70326683obb.2 for <>; Mon, 06 Apr 2015 20:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f1ke/JyOue5vN2RKQ7TSCUX9XyZx3hS4CUonAdn66Dg=; b=nsJ6lXwUeRp4KBKHDdUTZOSSClnS2346WlqL6IsFygONNKjJ+Gu7qTm1nuDtIACPQ3 B7xWgxP7QhDVcfPyMeVsElv1vb5KZycMCU/GAccuj2Tc2vCdHTpqqXZ2981m7WgHyPBb 6H/hOI0oreJT28ri9p/7+548IXDj8tq73uey7+EAjE/6/yjV1/RPI7K3DPuTMP3LoJG4 aPoproPsKILvEPPGh/mPGv+QMlAMupVHT1JV41FNHbxBIhHiaOALadVHh4jE0J3ucD0W d95fjO3EUZJSOV5UyPdWbM3/D8B+Ip04iAf5xgs0JNpjdoyhxBpSapqYI0zKrwlLtwUn 0kTQ==
X-Received: by with SMTP id d15mr22478133obt.58.1428377123095; Mon, 06 Apr 2015 20:25:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Apr 2015 20:25:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Tony Arcieri <>
Date: Mon, 6 Apr 2015 20:25:02 -0700
Message-ID: <>
To: "Salz, Rich" <>
Content-Type: multipart/alternative; boundary=e89a8fb1fca4070c9b051319f752
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 03:25:25 -0000

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

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.

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.

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.

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