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

Dave Garrett <> Mon, 13 April 2015 06:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9863D1B2CD7 for <>; Sun, 12 Apr 2015 23:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V_ruCLRuOoZE for <>; Sun, 12 Apr 2015 23:01:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 001A81B2D28 for <>; Sun, 12 Apr 2015 23:01:55 -0700 (PDT)
Received: by qkhg7 with SMTP id g7so163111193qkh.2 for <>; Sun, 12 Apr 2015 23:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=ifdarSjzcc4JT3UFAONJ1k5dCaMnjZFBE6C7BDKuUFU=; b=EmrmUkXwekMBD50EG9Ue2g2NZzjZIqaYZc408p+hGUiWB0zYnpPG61gVlkgAO37uK6 vCN+bgD/WO5zC7WyiwFW/YSA70efDRAsDSYunU6SzOnk3T3Y040nj2Bgegkf720s+S20 xHAsS6EtCGipgnP0xjljK05+QuQR1xRlwRv6vwh8J+BAi8ppD2ph9I3P/FppmIVkIEEe LGuhHIwigTe1GHin7ZC9H4CJIGZTAdqdWOt15NVYB6kOpa/4VdyInJHlyrOyHJB9AGiE S5KApJT66voZStKUun1CazIAilTGYXs/tXqIbkxtzxwQSqH4nfpXh/eKrmVUOtz3m7w1 WVcw==
X-Received: by with SMTP id n9mr26233823qkh.91.1428904915319; Sun, 12 Apr 2015 23:01:55 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id i185sm5117472qhc.18.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 12 Apr 2015 23:01:54 -0700 (PDT)
From: Dave Garrett <>
Date: Mon, 13 Apr 2015 02:01:52 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <20150407063133.GA5877@LK-Perkele-VII>
In-Reply-To: <20150407063133.GA5877@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Message-Id: <>
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 06:01:57 -0000

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.