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

[Daniel Kahn Gillmor <[e-mail]>]

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

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.

        --dkg