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.
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/ On Tue, Jul 7, 2026 at 3:26 PM Nico Williams <[email protected]> wrote: > On Tue, Jul 07, 2026 at 02:55:38PM -0400, Soatok Dreamseeker wrote: > > Algorithm agility in some contexts can be a terrible design choice. See: > > JWTs. > > JWTs are a lot like certificates. They need algorithm agility. You > might object to the details of how it was done here or there, but that's > not a good reason to object to the concept altogether. > > The complexity of algorithm negotiation is simply irreducible and > unavoidable because cryptographic algorithms occasionally age out. > > The only choice is where to put the negotiation. > > > You can do it safely: Bind the algorithm selection to the cryptographic > key > > (so it's not "just" a byte sequence, but also its algorithm and parameter > > choices). Tink does this. > > > > You can do it unsafely: [...] > > This is not an objection to algorithm agility. This is is pointing out > how to do it right / not do it wrong. > > > Versioned protocols (whereby you retire version N and specify a new > version > > N+1 when an attack is discovered) makes sense when you want your protocol > > to be a rigidly defined thing that only cryptographic security experts > can > > update. WireGuard does this (though it's still using v1 after all these > > years). > > You end up having negotiation anyways. I'd rather have negotiation in > the protocol than in the next version of the protocol. > > > I don't think this tangent applies to TLS though. > > I don't think it applies to any protocols. > > Nico > -- > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
