Conversation

Cryptographic agility is the property of supporting multiple crypto algorithms (like ciphers, signature types...) in a single protocol version that are selected and negotiated at runtime. Are you (broadly speaking) a cryptographer, and do you think agility is desirable?

Not a c11r, agility good
21%
Not a c11r, agility bad
57.7%
I am a c11r, agility good
9.1%
I am a c11r, agility bad
12.2%

977 votesFinal results

Filippo Valsorda

@FiloSottile

Apr 26, 2021

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.

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.

Replying to

Why is that undesirable? Assuming new code needs to be deployed anyway, and that all new choices are reasonable, why update piecemeal?

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*..

Replying to

and

Hence we wanted (well

@tjssh

was the lead designer of course 25 years ago, but I was eagerly watching) to have a protocol that can handle future eventualities.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

7:37 PM · Apr 26, 2021Twitter Web App

Replying to

and

Hmm. Note that you need a protocol to do the version negotiation. What is the version of that protocol? Cipher suites are numbers too.

Replying to

and

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.

Show replies