Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)

Andrei Popov <> Mon, 13 April 2015 17:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 62BCB1AD05E for <>; Mon, 13 Apr 2015 10:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_ILLEGAL_IP=1.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uESMTWq2Z7Xg for <>; Mon, 13 Apr 2015 10:32:50 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 299C71ACF56 for <>; Mon, 13 Apr 2015 10:32:50 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 13 Apr 2015 17:32:30 +0000
Received: from ([]) by ([]) with mapi id 15.01.0136.014; Mon, 13 Apr 2015 17:32:31 +0000
From: Andrei Popov <>
To: Dave Garrett <>, "" <>
Thread-Topic: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)
Thread-Index: AQHQda9fdjXdn4LJ2k69eyYuz+NEV51LMihw
Date: Mon, 13 Apr 2015 17:32:31 +0000
Message-ID: <>
References: <> <> <20150407063133.GA5877@LK-Perkele-VII> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(13464003)(24454002)(377454003)(33656002)(40100003)(46102003)(77156002)(92566002)(93886004)(87936001)(122556002)(106116001)(76576001)(19580405001)(19580395003)(107886001)(2656002)(86612001)(2501003)(54356999)(2950100001)(2900100001)(15975445007)(76176999)(102836002)(62966003)(99286002)(50986999)(74316001)(86362001)(4001410100001)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1251; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251;
x-forefront-prvs: 0545EFAC9A
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2015 17:32:31.1805 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251
Archived-At: <>
Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: 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: Mon, 13 Apr 2015 17:32:52 -0000

The idea of fixing the combinatorial mess is appealing to me, for a variety of reasons. However, negotiating the key exchange algorithm using "elliptic_curves" (or even "supported_groups") seems awkward. E.g. if someone wants to add a key exchange that is different than DHE/ECDHE, then using "supported_groups" to negotiate it will make little sense. This is already problematic today for PSK.



-----Original Message-----
From: TLS [] On Behalf Of Dave Garrett
Sent: Sunday, April 12, 2015 11:02 PM
Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)

On Tuesday, April 07, 2015 02:31:33 am Ilari Liusvaara wrote:
> Also, the certificate format negotiation is supposedly both via
> ciphersuites and an extension. And when you have the same thing in
> two places, the relevant question is "which is definitive?".

Here's a different idea for fixing the combinatorial mess: For TLS 1.3+, only use cipher suites to negotiate symmetric ciphers. Rely entirely on the extensions for the handshake.

For the handshake, mandate usage of the "supported_groups" extension (née "elliptic_curves") and the “signature_algorithms” extension for all connection attempts. (reject connection if not present and valid) If TLS 1.3+ is negotiated, then the DHE/ECDHE will be selected based on the highest preferred supported NamedGroup and RSA/ECDSA/etc will be selected based on the highest preferred SignatureAndHashAlgorithm. Assign points to NamedGroup and SignatureAlgorithm to negotiate PSK usage via the extensions. (e.g. NamedGroup=0 for plain PSK) The server would then ignore everything in proposed cipher suites other than the symmetric cipher suite components. (e.g. all of the following would be considered equivalent for TLS 1.3+: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) New ciphers that are supported via TLS 1.3+ would only need to define something in the form of TLS_EXT_WITH_x_y_z with variations of symmetric parameters (for OCB, there'd be only 2 suites). New ciphers that wish to support TLS 1.2 but without adding the litany of combinations of suites could simply allow negotiation of any of the new suites to assume DHE_RSA unless the necessary extensions are used to say otherwise. (though, just requiring the extensions to use them is not unreasonable)

This route does not change cipher suites in a major way and uses already in-draft extensions to do the negotiation, without any modifications beyond mandating their use and absolute priority over the parameters specified in the cipher suite. Not only does this make the cipher suite selection simpler and avoids endpoints not negotiating a viable combination that's just not offered in the list, but it removes any existing ambiguity over which support listing is definitive. Cipher suites negotiate symmetric and these two extension negotiate asymmetric.

TLS mailing list