[TLS] Last Call comment: draft-ietf-tls-mlkem-09 - named-gro up downgrade / negotiation policy

Hi,

One Last Call comment on draft-ietf-tls-mlkem-09, on the deployment
security surface rather than the cryptography, which the Security
Considerations already treats thoroughly.

The document registers standalone ML-KEM groups whose whole purpose is a
post-quantum guarantee, but the Security Considerations gives no guidance
on how a deployment ensures that guarantee actually holds against an
active attacker or a permissive peer. One short paragraph would close
that.

To be precise about what is and is not a problem:

- Modifying supported_groups within a single ClientHello is not a silent
  downgrade. The Finished MAC covers the full handshake transcript
  (RFC 8446, Section 4.4.4), so a tampered ClientHello diverges the
  transcripts and the handshake aborts. No change needed there.

- The residual risk is at named-group granularity, where TLS 1.3 has no
  downgrade signal. RFC 8446 Section 4.1.3's downgrade protection is
  version-granular only. So (a) an active attacker can induce fallback
  across connections by black-holing the PQC handshake (unknown group,
  or an oversized/fragmented ClientHello) so the client or application
  retries with a reduced offering, and transcript protection does not
  span separate connections; and (b) a client that offers ML-KEM
  alongside classical groups completes on classical with no signal that
  PQC was available but not used. In neither case does the client learn
  that its post-quantum intent was defeated.

For an Informational document registering standalone PQC groups, it is
worth stating that the assurance has to come from local policy, not from
the handshake. Suggested text for Security Considerations:

    TLS 1.3's downgrade-protection mechanism (RFC 8446, Section 4.1.3)
    operates at the granularity of the protocol version, not the
    negotiated named group. Within a single connection, modification of
    a ClientHello's supported_groups is detected via the Finished
    transcript hash (Section 4.4.4). However, the protocol provides no
    signal by which a client can detect that its post-quantum
    key-establishment intent was defeated by induced fallback across
    connections or by a peer that prefers a classical group.
    Deployments that require post-quantum key establishment MUST enforce
    this by local policy, refusing to complete a handshake that did not
    use an approved ML-KEM or hybrid group, rather than relying on
    offering these groups alongside classical ones.

Related, the large ClientHello that standalone ML-KEM produces (the
ML-KEM-768 encapsulation key is 1184 bytes, ML-KEM-1024 is 1568, and
multiple offered groups compound it) feeds the induced-fallback vector
above wherever it crosses record or datagram boundaries and trips
intolerant middleboxes. A sentence acknowledging that ClientHello-size
interaction would reinforce the same point.

Thanks for the work on this draft.

Mark Langston

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]