[emn13]

I see what you mean. I'm not seeing that in this particular article, but without getting sidetracked by whether he's said that before - I think there are two flavors of agility here.

You're arguing against runtime agility. That makes sense; in fact, the more runtime agility you have, the less design-time agility you have, because all that dynamic negotiation is quite the constraint - and as you point out, a source of flaws.

Even negotiation has flavors. Classic TLS tried to make supporting old ciphers "secure", but even negotiation in which you assume the attacker _can_ control the cipher can be useful - the point then being not to do so long-term, but merely as a technique to allow non-instantaneous roll-out world wide. There's a difference between trying to support but never use legacy stuff and also refusing to specify the current gold standard, and merely having a protocol that supports multiple ciphers only to the extent necessary to occasionally replace a single old configuration with a single new one.

I'm not sure whether there's a huge difference between merely supporting research diversity, and having non-runtime but design-time agility. Perhaps those are the same thing. I guess it gets interesting where encryption primitives aren't just ephemeral communication tools, but a more intrinsic part of the software (such as in signing, and especially in stuff like blockchains) - is there a way to have at least the option of swapping primitives without weakening the guarantees today?

In any case; thanks for the clarification!