From: Eric Rescorla <[email protected]<mailto:[email protected]>> Date: Thursday, 5 February 2026 at 16:16 To: Yaron Sheffer <[email protected]<mailto:[email protected]>> Cc: TLS WG <[email protected]<mailto:[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: 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? I'm saying it's not sufficient to provide interoperability without more restrictions. Suppose we have two PQ algorithms, X and Y. Without loss of generality, the server has a certificate chain using algorithm X. As described in S 3.2, the client SHOULD include X in its signature_algorithms, but that it MAY include other PQ algorithms (e.g., Y). This means that it might *only* include X [0] Now, suppose that the server wants to switch to Y. If it does so within the lifetime of the original advertisement, then it might encounter a compliant client that only advertises X and then you get an interop failure. In order for this to work, the server needs to support X within the lifetime of the advertisement. YS: This is all true, but I don't see how it is different from standard algorithm migration. For maximum interoperability, clients should support (and declare) as many algorithms as their policy allows. Clearly the wording can (SHOULD) be improved in S. 3.2. -Ekr [1] The SHOULD is a bit confusing, because it implies you could just offer Y and not X, which is plainly bad. If you're going to do this at all as a client, then you MUST do X.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
