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

Daniel Kahn Gillmor <> Mon, 13 April 2015 07:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E6661B2E8A for <>; Mon, 13 Apr 2015 00:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aoa_sNYx8BhB for <>; Mon, 13 Apr 2015 00:14:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E1201B2E88 for <>; Mon, 13 Apr 2015 00:14:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 77C7BF984 for <>; Mon, 13 Apr 2015 03:14:46 -0400 (EDT)
Received: by (Postfix, from userid 1000) id BBC521FF48; Mon, 13 Apr 2015 02:14:45 -0500 (CDT)
From: Daniel Kahn Gillmor <>
In-Reply-To: <>
References: <> <> <20150407063133.GA5877@LK-Perkele-VII> <>
User-Agent: Notmuch/0.18.2 ( Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Mon, 13 Apr 2015 03:14:45 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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 07:14:50 -0000

On Mon 2015-04-13 02:01:52 -0400, Dave Garrett wrote:
> 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.

This is the cleanest and most backward-compatible suggestion i've heard
yet for a la carte algorithm selection in TLS.  If we decide to do a la
carte algorithm selection, this seems like a variant i could be
comfortable with.

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

I'm not convinced that we want to use 0 for PSK (this may be purely
aesthetic: it makes PSK sound like the "default", and if we later find
other non-DH key exchange we want to stuff in this registry, it'd be
nice to group them together, and there are no available neighbors close
to 0).  I think i'd be ok using some other currently-unallocated
codepoint, though.

> 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_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)

We could also say that TLS 1.2 implementations that know about a new
symmetric cipher must be able to negotiate key exchange choice
independently via the supported_group ("supported_key_exchange"?)
mechanism when that cipher is selected.