Hi Yaron, Understood, but I was suggesting that the information to cache on the client would already be available with draft-ietf-tls-trust-anchor-ids. That could be either with the server TLS advertised TrustAnchorIDList which includes a quantum-resistant anchor and/or a quantum-resistant certification path CertificatePropertyList. DNS SvcParamKey records can also be configured to make this information available to the client as specified in draft-ietf-tls-trust-anchor-ids. After the client knows the server supports a PQ PKI it can cache that information and start advertising PQ Sig only ClientHellos to that server. It is not exactly “server commitment for PQ PKI”, but it is “discovery of server support for PQ PKI”.
Regardless, if the draft gets traction and ends up getting adopted, I suggest to use a new tlsflags extension value (draft-ietf-tls-tlsflags) instead and not a new pq_cert_available extension. From: Yaron Sheffer <[email protected]> Sent: Tuesday, February 3, 2026 2:29 PM To: Kampanakis, Panos <[email protected]>; TLS WG <[email protected]> Subject: RE: [EXTERNAL] [TLS] PQC Continuity draft CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Panos, The point of the protocol is to allow PQC-equipped servers to ensure that all communication to them is secure. That is, even clients that are willing to accept both legacy and PQC certs can connect to these servers securely, assuming that a CRQC (crypto-relevant quantum computer) exists and legacy connections may be compromised. In other words, the client can trust the server (including on Trust Anchors) only if it uses a PQC cert but cannot trust the server if it presents a legacy cert. Why should we care about such a weird future? Because migration to PQ will likely take years and will be gradual across millions of clients and millions of servers. If we assume that at some point CRQC will appear, we need to prevent rollback attacks on connections between modern (already migrated) clients and modern servers. Thanks, Yaron From: Kampanakis, Panos <[email protected]<mailto:[email protected]>> Date: Monday, 2 February 2026 at 18:05 To: Yaron Sheffer <[email protected]<mailto:[email protected]>>, TLS WG <[email protected]<mailto:[email protected]>> Subject: RE: [TLS] PQC Continuity draft Hi Yaron, Doesn’t draft-ietf-tls-trust-anchor-ids with certification paths already enable this? The client can find out if the server supports a quantum-resistant PKI and not accept a classical one. From: Yaron Sheffer <[email protected]<mailto:[email protected]>> Sent: Sunday, February 1, 2026 12:04 PM To: TLS WG <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] [TLS] PQC Continuity draft CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi, A few months ago, Tiru and I published a draft [1] whose goal is to minimize rollback attacks while the Internet is slowly migrating from classic to PQC (or composite) certificates. It seems that the TLS WG is now ready to turn its attention to PQ resistant signatures, and we would like to present the draft at the upcoming IETF-125. If anybody has had a chance to read the draft in the meantime, we would appreciate your feedback. People might also want to refer to the earlier discussion on this list [2]. Thanks, Yaron [1] https://datatracker.ietf.org/doc/draft-sheffer-tls-pqc-continuity/ [2] https://mailarchive.ietf.org/arch/msg/tls/qfmTs0dFq-79aJOkKysIP_3KhEI/
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
