[CiPHPerCoder]

> All the criticism of cryptographic agility that I have seen has involved an attacker negotiating a downgrade to a broken protocol.

Consider this an additional data point, then: https://paragonie.com/blog/2019/10/against-agility-in-crypto...

In the years since I wrote that, several people have pointed out that "versioned protocols" are just a safe form of "crypto agility". However, when people say "crypto agility', they usually mean something like what JWT does.

What JWT does is stupid, and has caused a lot of issues: https://www.howmanydayssinceajwtalgnonevuln.com/

If you want to use JWT securely, you have to go out of your way to do so: https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l...

> But if the protocol is not yet broken, then being agile isn't a concern, and if/when the protocol does become broken, then you can remove support for the broken protocol, which is what you'd be forced to do anyway, so a flexible approach just seems like a more gradual way to achieve that future transition.

This makes sense in situations where you have versioned protocols :)

This doesn't work if you're required to support RSA with PKCS1v1.5 padding until the heat death of the universe.

[thadt]

Hmmm, some recent protocols (thinking of MLS[1] here) have moved into a middle territory where they have a lot of options for piecing together a cryptographic suite, but then version that whole suite within the protocol. You can still change suites without changing the protocol, but it's not nearly as 'agile' as earlier suite and primitive negotiations.

Maybe something more like "cryptographic mobility" instead of "agility"? You can carefully decamp and move from one suite (versioned protocol) to another without changing all your software, but you're not negotiating algorithms and semantics on the fly.

[1] https://datatracker.ietf.org/doc/rfc9420