If you select "I am a c11r, agility good" I would like to hear from you. I hear all the time from all other three categories, but basically never from this one.
Conversation
Replying to
👋 I wouldn't want to jump to SSH3 to SSH4 in order to have a different, say, cipher mode or KEX. We defined KEX, ciphers, and auth as negotiable ID strings for core SSH2 back in '98 and have only updated (essentially) algorithm policies since.
2
2
Replying to
Why is that undesirable? Assuming new code needs to be deployed anyway, and that all new choices are reasonable, why update piecemeal?
1
1
Replying to
Why do you see the problem of protocol version rollback as easier to manage than some server having an outdated cipher configuration? My experience has been the opposite. The problem with SSH1 was that it wasn't agile *enough*..
1
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.
1
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.
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
Show replies