Algorithm agility in some contexts can be a terrible design choice. See: JWTs.
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: Just let the attacker choose the algorithm. I'm sure nothing could go 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). I don't think this tangent applies to TLS though. On Tue, Jul 7, 2026 at 2:47 PM Nico Williams <[email protected]> wrote: > On Tue, Jul 07, 2026 at 11:22:37AM -0700, Eric Rescorla wrote: > > On Tue, Jul 7, 2026 at 11:05 AM Jan Zerebecki <[email protected]> > wrote: > > > I think we should have learned from history of TLS and other protocols > > > that having multiple possible algorithms is a security problem. > > > > I don't think we've learned that. Quite the contrary, the ability to have > > multiple algorithms is what is allowing a smooth transition to > > hybrids. > > 100%. > > I don't quite understand the hate for algorithm agility. Suppose we had > no algorithm agility, then what? We'd occasionally have to retire > entire protocols and switch to new ones that differ mainly only as to > algorithms, easy, right? But wait! we'd have to support negotiation and > deal with downgrade attacks, so it'd be back to algorithm agility, only > with extra steps. No thanks. > > See also RFC 7696, section 3.3. > > Is there a standard answer to this reply, one that works? I don't think > there is. > > 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]
