[TLS] draft-sheffer-tls-pqc-continuity-02: four comments on the client cache rules

[Nazmus Salehin Sammo <[e-mail]>]

Hi all,

I have been doing a formal analysis of the PQ authentication negotiation
drafts as part of an MRes, and I have read
draft-sheffer-tls-pqc-continuity-02 in full. Four comments on the
client-side cache rules. All four are filed on the draft's tracker with
the detail and the suggested text. I am summarising them here for the
record, rather than starting four threads.

1. Resumption is not addressed. [1]

   Enforcement is anchored entirely on the server Certificate message
   (S3.2: "apply its PQC policy to every CertificateEntry in the
   server's Certificate message"). Per RFC 8446 S4.4.2 the server sends
   Certificate for every key exchange method "except PSK", and S2.2 says
   directly that on resumption the server "does not send a Certificate
   or a CertificateVerify message". So on a resumed handshake that
   obligation applies to an empty set. It is satisfied with nothing to
   check, the MUST-abort cannot fire, and the commitment is never
   consulted. Confirmed on OpenSSL 3.6.2 with a genuine ML-DSA-65 chain:
   the resumed handshake completed (Reused, TLSv1.3) with 0 Certificate
   and 0 CertificateVerify messages. The draft has no occurrence of
   resumption, PSK, ticket or 0-RTT.

   RFC 8672 S2, covering the same TLS-layer pinning pattern, handled
   this explicitly: "As a result, PSK handshakes MUST NOT include the
   extension defined here." That reasoning rested on the misissuance
   threat model and does not carry over unchanged to the undisclosed
   CRQC attacker of S1, but it is a ready precedent. Exploitation is
   bounded by the 7-day ticket cap in RFC 8446 S4.6.1. This is not a
   harvest-now, decrypt-later attack and I am not claiming it is. The
   specification gap stands on its own, independent of any attacker.

2. The withdrawal path lacks the condition its own rule 1 has. [2]

   S3.6 rule 1 conditions caching on "after the handshake completes
   successfully". Rule 2 conditions clearing only on receiving the
   extension. The suggested fix is one clause, copied from rule 1.

   Two things to be clear about. First, the condition is not new:
   RFC 6797 S8.1 has gated all HSTS state change, including the
   max-age=0 removal, on a clean secure transport since 2012, and
   RFC 7469 S2.3.1 does the same for pin deletion. Since S1 says this
   extension is modelled on HSTS, the honest description is that the
   normative text did not restate a condition the stated model already
   has. Second, the reference implementation already does the right
   thing: it defers both the cache update and the cache delete to
   SSL_CB_HANDSHAKE_DONE behind an X509_V_OK check, and says why in a
   source comment. So there is no exploitable instance that I know of.
   My concern is only that none of that appears in the normative text,
   and a second implementer reading rule 2 literally would be conformant
   without it. S4 of the draft already says the intended thing
   non-normatively ("until they observe zero on a completed handshake"),
   which is why I think this is editorial rather than a design change.

3. A question about the port in the cache key. [3]

   S3.4 keys entries by (RFC 9525 identity, port, TLS/DTLS) and says
   entries differing in any of these MUST NOT be merged, while the
   server's obligation in S3.7 carries no port qualifier and the
   reference identity is port-independent. So the client enforces
   something narrower than the server has committed to. I am asking
   rather than asserting: I do not think this is a bypass, since under
   S3.4 no commitment is in force for the key that gets used, but I also
   do not think it is the trust-on-first-use case S5.1 documents, since
   S5.1's own justification depends on the client eventually connecting
   directly, which never happens for a port it never uses. Related: S1
   invokes HSTS, but RFC 6797 S8.3 says "the HSTS Policy applies to HTTP
   over any TCP port of an HSTS Host", so the scoping differs from the
   named model. That may be deliberate for DTLS and non-web use. If so
   it would be worth saying.

   Martin's IETF-126 comments on this cache key not working for
   browsers, and on non-uniform multi-CDN deployment, are in the same
   area. I am not claiming new ground there, only asking about the port
   dimension specifically.

4. "The port" is not defined. [4]

   S3.4 does not say whether "the port" is the authority port from the
   URI or the TCP port actually connected to. These differ under an
   HTTPS RR carrying a port SvcParam, where per RFC 9460 S9.1 the origin
   does not change. The two readings give opposite answers about whether
   a cached commitment applies, and that decides whether the scope
   question in (3) is reachable at all. Two sentences would fix it.

None of this touches issue #23. I have Tamarin models behind (1) and
(2) and am happy to share them, with the caveat that they are models of
the S3.2, S3.5 and S3.6 client state machine, not security proofs of
TLS 1.3. The OpenSSL result behind (1) is the stronger evidence.

Thanks for the draft. Rule 3 of S3.6 and the S4 text made the first two
of these much easier to pin down than they would otherwise have been.

Nazmus Salehin Sammo
Melbourne Institute of Technology, Melbourne, Australia
Student ID: MIT252100
[e-mail]

[1] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/29
[2] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/27
[3] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/28
[4] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/26