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

Viktor Dukhovni <> Wed, 08 April 2015 02:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB48D1A1B27 for <>; Tue, 7 Apr 2015 19:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jg6x99SYAmz5 for <>; Tue, 7 Apr 2015 19:54:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB9851A1A1E for <>; Tue, 7 Apr 2015 19:54:40 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 0A100283031; Wed, 8 Apr 2015 02:54:39 +0000 (UTC)
Date: Wed, 8 Apr 2015 02:54:39 +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: Wed, 08 Apr 2015 02:54:42 -0000

On Mon, Apr 06, 2015 at 08:25:02PM -0700, Tony Arcieri wrote:

> 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 see no unanimity.  I think that long-term the cross product
simplifies maintenance (simpler internal tables with less duplication),
and makes it easier to sensibly sort the cipher-suites by independent
preferences for each feature.

Yes, there'll need to be new APIs for specifying separate preferences
for the key agreement suites vs. bulk crypto suites.  Some may find
this an opportunity to drop legacy interfaces.

In OpenSSL many of the building blocks are already there, thus
we can build up a cipher-suite from its parts:

    $ openssl ciphers -v kECDHE+aECDSA+AES128+AESGCM

All that's missing is separate ordered cipherstring settings for
the components.  These would be UI improvements I think.  Yes, not
easy retrofits into existing applications, but ultimately worth it
IMHO.  Assuming of course TLS is still the swiss-army knife of
security protocols and needs to support a range of choices for each
element of the cipher-suite.

Were any radical simplification to just 1 or 2 (composite) ciphersuites
actually realistic, then breaking those down would be silly.  As
it stands I don't see a likely choice of just 2 ciphersuites that
serve all TLS users, and thus ala carte makes sense to me.