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

Brian Smith <> Tue, 07 April 2015 06:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 539971B31E6 for <>; Mon, 6 Apr 2015 23:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z2R3KmT3HT8p for <>; Mon, 6 Apr 2015 23:09:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C10871B31E5 for <>; Mon, 6 Apr 2015 23:09:08 -0700 (PDT)
Received: by vnbg129 with SMTP id g129so7372756vnb.4 for <>; Mon, 06 Apr 2015 23:09:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jbn1804+2LnBeSXeGHZEctz7tR94WAT0jwn7mURXVI0=; b=jCMH87XNMyT2izrxfNh/gpjsBwGAx5p5fZylYVbgDt0GW5ghIGNRIWPQwL68VcnCDw zQrHsyqd/JZ4uo4BnxhoVZjYWQlZ5c14t0My+32d7M33hRIMYYWjfLNnEhzl7dYxDIEP IQ7Ciut7VeI3BsfxnAYnEKNU8ZEn/p92s9KNdSjs9klYoXzrW9MxG0QA1kXwxTjYh2m9 ems9KSVoCl3vF7Yqyplb/WBqIkTyxyRza0Or55V+n2KcbgqKeVKeqwa7XnKZZF6HkFAj 76KOuxbMqFtg69KZ6+b7D5k74J0N87AtqsYCaa1kwoGH74jMFluyfSKc99NXP55DF/KB a0sw==
X-Gm-Message-State: ALoCoQmzciflVzrlG799rIlNAi2M1Ky09pnIaVoFg3AM8VgAOLeqVdYFghpQTmLGctjYUrLpPsU8
MIME-Version: 1.0
X-Received: by with SMTP id e10mr23366824oey.85.1428386947909; Mon, 06 Apr 2015 23:09:07 -0700 (PDT)
Received: by with HTTP; Mon, 6 Apr 2015 23:09:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Mon, 6 Apr 2015 20:09:07 -1000
Message-ID: <>
From: Brian Smith <>
To: Tony Arcieri <>
Content-Type: text/plain; charset=UTF-8
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 06:09:11 -0000

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 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.

As far as I understand, that problem doesn't have much to do with the
syntax of cipher suites in the ClientHello, because that problem is
about describing to your web server software which cipher suites to
enable on the server.
> 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.

That can be done already today, without any protocol changes, and
without any TLS library changes (at least as far as OpenSSL is
concerned). Somebody just needs to write the code to do it.

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

The client doesn't always (ever?) want to enable the entire set of
(key exchange algorithm * authentication algorithm * encryption
algorithm * integrity algorithm) combinations, so a syntax that only
allows the client to describe cipher suites by the individual
components is too limiting.

More generally, an "a la cart" syntax automates the enabling of lots
of cipher suites. But, how is enabling lots of cipher suites a good
thing? it seems like a bad idea, in general, to me.

If we had a need to have clients enable a whole lot more cipher
suites, such that the size of the ClientHello would become really
large with the current syntax, then that would be a reason to consider
a new syntax. But, it seems that when we consider that the old syntax
has to be supported for backward compatibility with TLS 1.2 and below,
it seems like the set of new cipher suites to enable would have to be
quite large before we would enjoy any positive space savings from
doing that. Thus, the idea seems counterproductive even considering
the area where it would be most likely to help.

Finally, there is a lot of value to getting TLS 1.3 done in a
reasonable time frame. Cutting unnecessary or counterproductive
changes accelerates the schedule while giving us more time to solve
more important problems.