Re: [TLS] Ala Carte Cipher suites - was: DSA should die

[Yoav Nir <[e-mail]>]

> On Apr 7, 2015, at 6:25 AM, Tony Arcieri <[e-mail]> wrote:
> 
> On Sat, Apr 4, 2015 at 4:55 PM, Salz, Rich <[e-mail] <mailto:[e-mail]>> wrote:
> > Please don't change the syntax for negotiating cipher suites.
> 
> +1, for the reasons Brian said.
> 
> Looks like the opinion of TLS implementers is this far unanimously against this proposal. I would like to give the counterpoint from a TLS user perspective.

I’m a TLS implementer and I kind of like a-la-carte, but wouldn’t mind either way. Might have something to do with me having been an IKE implementer before I was a TLS implementer.

> I am more or less in charge of the ciphersuite selection for a large web site with a lot of users. I find the present means of describing ciphersuites to TLS stacks to be difficult at best. As myself and many others have described, we're essentially being asked to compute the combinatorial explosion of different ciphersuite configurations by hand. Guess what happens when you do that? People make mistakes. I think the TLS libraries should have an easier-to-use configuration format that computes things for me so I don't have to. I understand why TLS implementers are reluctant to provide that. It's more work for them. But so far none of them have said why this is qualitatively bad.

This is about UI, not about wire format. I totally agree that the OpenSSL string format for specifying ciphersuites is a horrid mess, but nothing is stopping an implementer from creating an a-la-carte UI and translating the user preferences to a combinatorial explosion on the wire.

> The proposed approach of splitting up what is more or less key exchange vs symmetric cipher configuration (please excuse that rough description, I know how deep the rabbit hole under this bikeshed goes) and require you specify both parts in order of preference sounds like it should fit within all of the existing TLS configuration frameworks and notations. People would only use the new syntax with TLS 1.3+ compatible libraries, and it should be fully backwards compatible with the old one.

So sure, UIs range in sophistication from a set of radio buttons labeled “secure”, “not so secure”, and “not secure” to a list of ciphersuites, each with a check box next to it, and those kind of UI choices can be expressed in string configuration as well. 

> I also think that requiring this sort of configuration could help designers TLS tease out these concepts internally so they aren't colluded into an amorphous mush of algorithms, every possible combination of which a TLS deployer is expected to whitelist.

I think implementers understand what goes on behind the long list of ciphersuites.

> Seems like a huge win to me. So what's the problem from an implementer perspective besides "it'd be hard”?

There’s always that fear that some combination of algorithms will turn out to be not secure, while other combinations of each of those algorithms will be fine.

Yoav