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

[Yaron Sheffer <[e-mail]>]

Hi Nazmus,

Thank you for your review and the issues you submitted. We will review and address them shortly.

Best,

    Yaron

On 02/08/2026 7:43, Nazmus Salehin Sammo wrote:

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" rel="nofollow">https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/29

[2] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/27" rel="nofollow">https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/27

[3] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/28" rel="nofollow">https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/28

[4] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/26" class="moz-txt-link-freetext" rel="nofollow"> https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/26

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