Right, and there are many different design schemes that get lumped up in the term "algorithm agility". Many of these designs are bad. We should probably be more specific when we talk about "agility".
In TLS's case, negotiation is an unavoidable part of the design, and being able to add new algorithms without requiring TLS 1.4 (or 4.0, or whatever the next iteration of the actual protcool is) is kind of the ground assumption most of us are working with. Because the term "agility" is not specified clearly and can refer to many different ideas (some are actually fine, but some are very unsafe), when someone asks broadly why anyone would oppose algorithm agility, JWS is my goto example to answer such open-ended inquiries. On Tue, Jul 7, 2026 at 10:33 PM Paul Wouters <paul= [email protected]> wrote: > On Tue, 7 Jul 2026, Nico Williams wrote: > > [ a bit off topic but hopefully still interesting for some ] > > > I don't quite understand the hate for algorithm agility. Suppose we had > > no algorithm agility, then what? > > You can look at WireGuard's lack of PQC support for such an example. > > The workaround implemented is that it supports a PreSharedKey slot to > mix into the key generation functions, similar to IPsec/IKEv2's RFC 8784 > (Postquantum Preshared Keys, PPK). This requires a whole TLS 1.3 PQ hybrid > key exchange to deliver that PSK to clients via the server/provisioning > route. It could optimize this by using TLS 1.3 Exported Authenticators, > but this handshake is also used for a bunch of other parameters not > negotiated in the native wireguard protocol such as VPN IP address and > DNS servers) so it's just one more added parameter in a regular TLS 1.3 > handshake. > > For small scale deployments, one would be using the SSH protocol with > its PQC codebase to successfully convey this additional PQC PSK for > wireguard to use. > > Where as IKEv2/IPsec, called by many to have too much agility support, > specified a single Additional Key Exchange method (RFC 9370) that allows > one to either negotiate a pure or hybrid (or more than two) key exchanges > (draft-ietf-ipsecme-ikev2-mlkem, currently in the RFC Editor queue). Peers > advertise their local policy to either allow or deny the pure or hybrid > key exchange(s). The only caveat here is that the initial key exchange has > to fit in a UDP packet, and since MLKEM768 doesn't, the easist rollout is > to use ECC on the initial key exchange and MLKEM768 on the second one, > making hybrid a bit easier even if the ECC component in a postquantum > future is reduced to just giving the protection of an anti-ddos cookie. > > While wireguard advertises its small code base, when you factor in the > additional TLS or SSH stacks required, I think IKEv2 wins by a lot. > > > Yes, a lot of crypto agility is bad. Some crypto agility is good. If we > believe we should now be doing a migration to hybrid, and in the future > use another migration to pure PQ, then having code ready for both now > will ensure we can exercise these paths before it becomes the production > path for everyone. And yes, avoiding mistakes like we did when export > ciphers where around and took way longer to die than intended. > > Paul > > _______________________________________________ > 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]
