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]

Reply via email to