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]
