[TLS] Re: PQC Continuity draft

[Eric Rescorla <[e-mail]>]

On Fri, Feb 6, 2026 at 3:25 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> Thanks for the clarifications. A couple of quick questions to understand
> the net benefit of doing it at TLS layer:
> On 06.02.26 23:46, Eric Rescorla wrote:
>
> it's just that you wouldn't need to invent a new HTTP-level indicator for
> the client auth case.
>
> [Apologies for unfamiliarity with HTTP layer] Is it something really very
> useful in practice not to invent such an indicator? or in other words, is
> inventing it really costly to be avoided?
>

I think opinions vary :)

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.
>>
>> Is the commitment per connection or per client? Could you explain how
>> does one infer that?
>>
>
> It's supposed to be per client, but, as you suggest here, the server
> doesn't necessarily know the client's identity.
>
> So if it's per client, is it correct to conclude that the proposed
> mechanism is only useful for TLS *with* *client authentication*?
>
> If so, then we circle back to the point that client authentication
> typically requires HTTP support.
>
With the understanding that i'm opining on someone else's design....

The way that this design works is that the server advertises support for
a given algorithm on a client-by-client basis and then clients remember
that the server has support. Once the server has advertised that algorithm
for *any* client, it needs to support it for the lifetime of the
advertisement,
because otherwise the client might break. However, the server doesn't
need to know which client is which, just that it needs to remember which
advertisement is longest.

Thanks,
-Ekr


I don't have a good example to hand, but TLS is a very commonly used
> protocol, so I was just being cautious.
>
> Sure, thanks.
>
> -Usama
>