On the browser side, my colleague and I actually just published some thoughts here. I hope it's useful to other folks as well. https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/
A few disconnected thoughts: I agree we need to provide downgrade protection for PQ auth. It may be counterintuitive if one hasn't thought about it, but adding PQ auth to the client and switching server certs to PQ auth *has zero security benefit*. Sure, it lets you check a box, but as long as the client trusts a single classical CA, the attacker just attacks that. It doesn't matter if the server uses a classical CA or not. Only the client's policy determines whether connections are secure, which means this is about client compatibility constraints and the state of the server ecosystem. An HSTS-like mechanism is... an answer. The doc sketches out one possible spelling. For the web at least, I think an HTTP header is preferable. It matches how the rest of the platform works and what developers know. People already know how to inspect a server's response headers, etc. It's true HTTP headers are more application-specific than a TLS mechanism, but stateful mechanisms are unavoidably application-specific. For example, in HTTP, due to the curse of cookie scoping, we'd really need includeSubDomains. And then there's privacy boundaries for correlating connections, etc. Compatibility-wise, adding new attributes to HSTS should be fine. The preload list made up an attribute <https://hstspreload.org/#submission-requirements> with no problems. That said, I think a separate header is preferable. A site may be ready for HSTS includeSubDomains, but not PQ includeSubDomains. (Or vice versa.) The time commitment a site can make (max-age) may also vary between the two. That said, I don't think HSTS-like mechanisms are good. The doc details a bunch of pitfalls. It's an attractive nuisance. As a purely opt-in scheme, they have no immediate compatibility concern. But they are risky for server operators, and their costs and risks grow as the transition progresses. Thus I see this primarily as a short-term stopgap option. I think the real, robust story will be to get to requiring PQ at just the CA level. That still isn't a small transition, but if we separate it from requiring PQ at the TLS level, it is both sufficient for downgrade protection and achievable with the tools we've been discussing over the years. (Certificate negotiation and provisioniing multiple certificates in ACME, both in a principled way by actually handling two certificates, and a transitional hacky encoding because we don't yet have a time machine.) That's discussed under "Stage 3" here: https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/#stage-3-require-a-post-quantum-pki David On Mon, Feb 9, 2026 at 3:32 PM Eric Rescorla <[email protected]> wrote: > > > On Mon, Feb 9, 2026 at 12:16 PM Yaroslav Rosomakho <[email protected]> > wrote: > >> On Mon, Feb 9, 2026 at 3:44 PM Eric Rescorla <[email protected]> wrote: >> >>> Without taking a position on the merits of this idea generally, I would >>> like to observe >>> that it's not generally the case that people are individually deciding >>> whether to trust >>> non-PQ credentials or not. Rather, their software provider--in the Web >>> case, the >>> browser vendor--makes a global policy decision for their product. In >>> some cases, >>> users can of course change their configurations, but they generally >>> don't. >>> >>> >> I don't think trust or lack thereof is strictly binary. There is a >> history of web browsers using various UI elements to inform the users about >> levels of "security" of the website. >> > > There is some history of this, but increasingly they don't do this for the > TLS > connection, for two reasons: > > 1. It's very difficult for users to make sense of these indicators. > 2. Web security is at the level of the origin, so compromise of a single > connection compromises the entire origin. > > I suppose browsers could refuse to connect with non-PQ algorithms > and allow users to override it [0], but if you just give the user an > indicator > in the URL bar or the like, it's too late because the origin is already > compromised. > > -Ekr > > [0] Although browsers increasingly are discouraging this kind of > override. > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
