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

[Dave Garrett <[e-mail]>]

On Saturday, April 04, 2015 12:52:50 am Aaron Zauner wrote:
> Added the PSK ciphersuites after lengthy discussion with nikos and peter
> gutmann, they assure me it's of importance to the embedded world.

I'm fine with (EC)DHE_PSK, but I thought the consensus was that non-ephemeral cipher suites were not permitted any longer. I thought usage of plain PSK would be against TLS 1.3 & HTTP/2 consensus. If it really is needed, I think they should be prohibited in general TLS and only allowed via the IoT application profile.

> > Just splitting it into only two parts would avoid the risk of support holes you'd get with the full a la carte route.
> > 
> > There's plenty of space in the registry to keep adding piles and piles of variations for each suite, but I have seen actual instances where a server and client actually do support the same handshake and connection ciphers in TLS 1.2, but don't negotiate it because the specific combination isn't listed. The current system does lead to some support holes as-is.
> 
> I actually really like the idea. But there're a couple of open questions
> to that; What happens to existing ciphersuites?

There's hardly any left that are still permitted. Each cipher that would be usable in TLS 1.3+ would need to define its own set of new cipher suites. The TLS 1.3 spec could have a short section to just assign the IDs for the existing ones. Clients would propose both the old suites and the new suites in the same array. Old servers would ignore the new, and new servers would ignore the old. (again, set all new above some point so checking is just a greater/lesser than comparison) It would be an extra few bytes, but again, any system to improve this via an extension would also add an extra few bytes.

> And given we switch to a
> model of asymmetric and symmetric ciphersuites: (how) do we document all
> the implicit ciphersuites that are defined once a new symmetric or
> asymmetric algorithm is defined?

The two are separate enough that all combinations should be valid and all implementations should be capable of handling all combinations.


Dave