Below. From: Eric Rescorla <[email protected]> Date: Thursday, 5 February 2026 at 16:16 To: Yaron Sheffer <[email protected]> Cc: TLS WG <[email protected]> Subject: Re: [TLS] PQC Continuity draft
On Thu, Feb 5, 2026 at 5:53 AM Yaron Sheffer <[email protected]<mailto:[email protected]>> wrote: 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. This does not appear to me to be correct based on S 6.1. If an STS header field contains directive(s) not recognized by the UA, the UA MUST ignore the unrecognized directives, and if the STS header field otherwise satisfies the above requirements (1 through 4), the UA MUST process the recognized directives. Obviously, it's an open question how clients actually behave. YS: I agree on both points. I was misreading paragraph 4 of the same section. 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. I don't understand what scenario you have in mind. YS: I'll take it back - the behavior could be well defined even in the case of an attack. Having said that, our discussion here seems to demonstrate that an HSTS-level implementation would move a lot of TLS-specific logic into the application, including signature algorithms and (probably) certificate chains. The existing HSTS clearly doesn't have such deep integration with TLS. 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. Actually, the point I was trying to make was that TLS WG was not necessarily sufficient for that, because the community question is bigger than TLS. 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. That doesn't work mechanically. Once the server has advertised algorithm X, the client is only required to offer X, which means that if the server switches to PQ algorithm Y, it is risking a handshake failure. YS: per S. 3.2, "It [the client in this case] MAY include other PQC signature algorithms, according to local policy." Are you saying that this is not workable? -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
