[TLS] Re: LS on the work item related to QKD and TLS integration framework in SG13

[Viktor Dukhovni <[e-mail]>]

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.  🇺🇦 Слава Україні!