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

[Andrei Popov <[e-mail]>]

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.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Dave Garrett
Sent: Sunday, April 12, 2015 11:02 PM
To: [e-mail]
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.


Dave
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls