Thank you EKR for the detailed and thought out review. Please see my comments below, tagged YS.
From: Eric Rescorla <[email protected]> Date: Wednesday, 4 February 2026 at 17:04 To: Yaron Sheffer <[email protected]> Cc: TLS WG <[email protected]> Subject: Re: [TLS] PQC Continuity draft Document: draft-sheffer-tls-pqc-continuity-00.txt Yaron, Thanks for posting this. While I do think that this kind of PQ ratcheting mechanism is potentially useful as part of a PQ transition, I'm not sure that this is the right design. The first question is whether this is at the right layer. As you indicate, the only place where we have really deployed something analogous is at the HTTP layer, with HSTS and HPKP (now deprecated). You don't really justify why this ought to be at the TLS layer instead, but ISTM that there are two main arguments that one could make: 1. It's generic and so you don't need to add it for other protocols. 2. It allows you to handle the client authentication case as well (though I'm not sure how well this really works the way you have suggested, see below). On the other hand, we already have HSTS, so it seems like there is an argument for reusing that machinery, which you could do just by adding a new keyword. This has the advantage that you can probably deploy just by reconfiguring your server, rather than upgrading your TLS stack and potentially your server to support the new extension. YS: at a high-level, there's also the architectural argument: we should address a TLS rollback at the TLS layer. More technically, I don't think HSTS has a good extensibility story (e.g., no IANA registry), and in fact from skimming the RFC it appears that a new keyword would break existing recipients. In addition, HSTS implicitly assumes that the TLS connection is trusted, we would need to analyze the behavior when this is not the case, i.e. an active rollback attack. Clearly, either version will work, so ultimately, this seems like a question that ought to be resolved by asking what implementors are more likely to deploy. Have you talked to people who say they would deploy this? In the specific case of the Web, what do browser vendors and server operators propose? YS: I have not talked to them and I welcome this discussion, in fact the TLS WG is a great venue for that. Turning to the specific design, this mechanism seems to want to be generic rather than just tied to PQ versus non-PQ in that the server provides a specific algorithm [0], but actually isn't because of the algorithm selection mechanism described in S 3.2 where once the server has indicated support for some PQ algorithm the client then can support *any* PQ algorithm, not just the indicated one. This creates the situation where the server's extension really means something like: 1. I always will authenticate with PQ. 2. I am able to do specific PQ algorithm X. As a result, the client can't just treat the extension as algorithm negotiation but needs to maintain a PQ-vs-non-PQ table. YS: I am definitely NOT trying to replace the existing alg selection. I agree with your analysis (both points 1+2 above). The need for this client-side algorithm table can be easily supported by adding a binary "is PQ" column to the IANA registry. We're early enough in the migration process that adding this information to clients is realistic. Relatedly, the text in S 3.4 isn't quite right: 2. The sender MUST keep track of the time duration it has committed to, and use a PQ certificate to authenticate itself for that entire duration. The sender MAY change its certificates and may switch between PQ signature algorithms at will, provided the peer indicates acceptance of these algorithms. Once the server has committed to algorithm X it needs to maintain algorithm X for the validity period, even if it also supports algorithm Y. YS: I'm not sure why you're saying that. The draft (and maybe it's not clear enough) is about the server committing to do PQ in general, not committing to a particular protocol. Moreover, because the algorithm in the extension must be the same as the server used (see S 3.1) [1], the extension signature_algorithm field as-is is either redundant or harmful, depending on how one interprets the specification. Specifically, the text says: The signature_algorithm in this extension MUST be the signature algorithm that the sender's end-entity certificate is associated with. SignatureScheme is defined by [RFC8446]. However, this doesn't provide security alone because what matters is that the entire chain be protected with some PQ algorithm, not just the algorithm associated with the SPKI in the EE cert. Consider what happens if the server has a certificate with an ML-DSA key, but which is signed with an ML-DSA/P-256 hybrid. If the spec is read literally, the extension would have ML-DSA in it and the client would then be permitted to just offer ML-DSA in CH, which would cause negotiation failure [1]. YS: I totally agree that the entire certificate chain must be PQ-signed. I was actually considering to add such text but couldn't find any normative requirement in LAMPS documents for the certificate chain to be fully-PQ, which I think is essential regardless of the current draft. In order for this to work, the client instead needs to support the entire set algorithms that would be required to validate and use the server's EE certificate, including any signatures on it. Moreover, this means that: 1. The client needs to have cache invalidation logic in case it ceases to support one of those algorithms. 2. The server needs to know what it is committing to in order to make sure it has such a certificate for the validity period (e.g., is it committing to this precise chain structure? what about cross-signing?). I haven't worked through this entirely, but I think the correct semantics need some fairly close study to avoid creating situations where one side or another is bricked. YS: totally agree, this is still a -00. In S 3.1 you say that this can be used for both server authentication and client authentication, but the setting isn't really symmetrical. S 3.2 says: * The peer SHOULD include the cached algorithm in the signature_algorithms extension of its ClientHello (or CertificateRequest for servers), and MUST NOT include legacy (non- PQC) algorithms. I don't see how this works: the client (usually) knows the server's identity in advance but the server usually does not know the client's in advance, so how does it know whether it has cached information or not prior to receiving the client's certificate. One might attempt to resolve this by just saying that the server should send its ordinary signature_algorithms and then reject any non-PQ algorithms from the client, but I don't think that quite works as-is because the client might initially prefer PQ and then later not prefer PQ leading to a failure. At least, I think you would need a warning that you shouldn't advertise this extension as a client unless you are committing to always sending a PQ cert if possible. YS: agree. https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/4 -Ekr [0] See John Mattsson's comment at https://mailarchive.ietf.org/arch/msg/tls/WCC6JNWTNgMiCd8GcZiX1Mv6fA8/ [1] Ignoring for the moment signature_algorithms_cert, but we can replicate this issue in that case as well. On Sun, Feb 1, 2026 at 9:04 AM Yaron Sheffer <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
