On Sun, Mar 22, 2026 at 12:04:33AM +0000, John Mattsson wrote:
> That this is explicitly permitted by RFC 8446 is a major part of the
> problem, and exactly why the TLS WG has a responsibility to respond.
> RFC 8446 allows a mode that is dangerously weak in practice: it allows
> people not only to shoot themselves in the foot by using low-entropy
> PSKs (e.g., passwords), but also creates a clear path for compromise,
> including SIGINT actors marketing hardware that magically produces
> "unbreakable" PSKs.
It makes sense to recommend "psk_dhe_ke" over "psk_ke", with
X25519MLKEM768 as the "dhe". And perhaps also suggest a correction for
the text in section 10.1:
Old:
TLS supports three basic key exchange modes [IETF RFC8446]:
- (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
- PSK (Pre-shared Key)-only
- PSK with (EC)DHE
New:
TLS 1.3 supports three basic key exchange modes [IETF RFC8446]:
- Asymmetric key establishment ((EC)DHE, KEM, or Hybrid)
* KEMs presently include:
+ MLKEM512
+ MLKEM768
+ MLKEM1024
* Hybrids presently include:
+ SecP256r1MLKEM768
+ X25519MLKEM768
+ SecP384r1MLKEM1024
+ curveSM2MLKEM768
- PSK (Pre-shared Key)-only ("psk_ke")
- PSK with asymmetric key establishment ("psk_dhe_ke")
An astute reader might notice that QKD is then not the only game in town
for post-quantum security and becomes a defense in depth option, when
risk-appropriate and cost-effective.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
