Hence we wanted (well was the lead designer of course 25 years ago, but I was eagerly watching) to have a protocol that can handle future eventualities.
Conversation
Because it's much harder to work with "TLS 1.2 is the good one, but only if you use a ECDHE suite, or also DHE but only if your moduli are big enough" than "TLS v25+ is good".
I think SSH avoided some of this thanks to OpenSSH being the majority of the ecosystem.
1
1
Well *nix distributions have their own configurations managed by those security teams and that probably helped mostly. Web server configuration was left to web masters! So, in a way, not related to protocol design so much.
1
2
Btw how would having TLSv25 with flexible version negotiation be much different from "cipher suites" ? You'd have transition periods with people with TLSv21 and v23 calling in etc so you'd need that. It would essentially mean just calling "suite" a "version".. same thing.
1
1
You need protocol version negotiation for other reasons. It already solves the problem of moving to newer ciphers. Don't need more attack surface / complexity. It's a lot simpler for interoperability too. There's simply a version number, not a bunch of other parameters too.
1
Hmm. Note that you need a protocol to do the version negotiation. What is the version of that protocol? Cipher suites are numbers too.
1
You need a versioned protocol unless you get it perfect from the start and anticipate all future needs.
You do not need to negotiate anything else, and older protocol versions get phased out.
Those wanting to reduce attack surface can phase out the older protocols sooner.
1
TLS 1.3 not only has cipher suite negotiation but forces you to implement AES-GCM. It isn't optional, and it isn't useful or reasonable to implement without a hardware implementation. Forcing having substantial attack surface and complexity beyond just having cipher negotiation.
1
It's actually harder to push a broad migration to a new optional cipher than it is to move to a new protocol version doing nothing beyond switching the cipher.
It's not simply that you have multiple mechanisms. It's that it's an optional feature vs. a protocol version upgrade.
1
If you ignore how organizations, software, etc. work in the real world then that's a problem. Having a mess of optional extensions, etc. is terrible. You have an explosion of complexity from the combination of each set of options across different implementations/versions.
1
The protocol version upgrades deal with multiple problems at once, vastly reducing the explosion of different combinations. It's a lot simpler and easier for the ecosystem to adopt and phase out the older versions. You need non-cryptographers to understand and care to upgrade.
TLS 1.3 also has the half-baked 0-RTT feature... which is another form of runtime negotiation and continues the tradition of expecting non-cryptographers to use and configure the protocol correctly. It really shouldn't have shipped in that state.
1
I'd say that protocol version negotiation protocols are harder than you think, phasing does not happen magically, and you kind of made the same point right there.
1
Show replies