The sequence of events was this: 1. Jan said something unrelated. 2. You said the specific thing I replied to (quoted in my previous email). 3. Seeing a "why would anyone be against cipher agility?" question, I answered your question. 4. You expressed confusion.
I've made my persuasive arguments already, but since you're confused, let me explain this as painstakingly as possible so you can understand a) why I chimed in in response to that specific thing you said and b) what exactly I mean. Agility is a vague term that can mean many different things to many different people if they begin with different prior beliefs and assumptions. In the broadest possible sense, the issue isn't that algorithms can ever change. The problem is that proponents of "crypto agility" often want what JWT has: 1. Mix-and-match ciphersuites from multiple constituent parts 2. Determined at runtime 3. Signaled in-band by the messages intended to be protected by the cryptography being negotiated Those are the kinds of design decisions that lead to the "use an RSA public key as a symmetric HMAC key by changign the alg header" confusion attacks that plague JWT implementations. When you say something like, "I don't understand the hate for algorithm agility," that's the canonical example of where algorithm agility goes wrong. This debate belongs elsewhere and doesn't really intersect with TLS, but that's the asnwer to the question you ltierally asked. I don't know what you're arguing. If your argument is "don't get this > wrong", then I agree 100%. If your argument harkens back to what I was > originally responding to, namely that algorithm agility is bad, then I > disagree 100%. If you wonder aloud why people are against algorithm agility and then are astonished when someone explains how poorly thought-out algorithm agility can introduce security footguns, I don't know what you expected. The concept of algorithm agility is very broad. You could say that WireGuard allowing a future v2 ciphersuite is "algorithm agile" since something is, at some point in the history or future of the universe, negotiated. A previous email of yours suggested as much. But I would argue that the word wouldn't mean anything. You could say that "no no it's only agility if it's determined at runtime", but then you need to be more specific still. Tink implements agility by making your algorithm selection problem really a key rotation problem. (Your NIST P-256 keypair will never be used for Ed25519, even if you can collapse both to 32 random bytes.) JWT lets you use an RSA public hey for H256 and that decision is negotiated by the payload an attacker can mutate. Are both of those decisions algorithm agility too? I think the original sin of this whole tangential debate is a poor definition of terms. In my designs, I promote Alacrity instead of Agiltiy: https://soatok.blog/2024/08/28/introducing-alacrity-to-federated-cryptography/ That is all I have to say on this matter. On Tue, Jul 7, 2026 at 5:12 PM Nico Williams <[email protected]> wrote: > On Tue, Jul 07, 2026 at 03:29:11PM -0400, Soatok Dreamseeker wrote: > > Respectfully, when we're talking about "negotiation", I mean any > situation > > where anyone ever decides to use Algorithm A instead of Algorithm B in > any > > conceptual way. That definition is too broad to be useful. > > Generally that's going to involve negotiation somewhere. > > > I mean something much more specific: a runtime decision about which > > algorithm to use. In JWT's case, this decision is determined entirely by > an > > in-band signal, which was not very well thought out. See: RSA-to-HMAC JWT > > algorithm confusion attacks, or alg=none. > > https://www.howmanydayssinceajwtalgnonevuln.com/ > > I don't know what you're arguing. If your argument is "don't get this > wrong", then I agree 100%. If your argument harkens back to what I was > originally responding to, namely that algorithm agility is bad, then I > disagree 100%. > > Nico > -- >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
