On Thu, Feb 5, 2026 at 5:53 AM Yaron Sheffer <[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.
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.
> 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.
-Ekr
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
