[TLS] Re: PQC Continuity draft

[Muhammad Usama Sardar]

On 07.02.26 01:50, Eric Rescorla wrote:

    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 :)

Fair point, I guess I would like to hear those opinions from the WG :)

With the understanding that i'm opining on someone else's design....

Understood. Authors can correct if there is a difference.

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

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.

for *any* client, it needs to support it for the lifetime of the advertisement,

Thanks, that was very helpful.

Here is a preliminary model of my understanding for it:

 * Client C1
 * Client C2
 * Server S
 * Algorithm A
 * Lifetime of commitment L1
 * Lifetime of commitment L2

Say L1 < L2
For simplicity, say both connections are established at same time t = 0

# Server side

 * S promises algorithm A for lifetime L1 to C1 but S doesn't know
   identity of C1 (handshake without client authentication).
 * S promises algorithm A for lifetime L2 to C2 but S doesn't know
   identity of C2 (handshake without client authentication).
 * S needs to keep track of time to always compare: current time <
   max(L1, L2) to keep supporting the promised algorithm A.

# Client side

 * C1 stores identity of server S, algorithm A and lifetime L1 in its
   state.
 * C2 stores identity of server S, algorithm A and lifetime L2 in its
   state.
 * C1 needs to keep track of time to always compare: current time < L1
 * C2 needs to keep track of time to always compare: current time < L2


*Concern*: Trusted clocks are not always available, e.g., in TEEs.








1. C1 asks for a connection for S.
2. MITM gets the compromised key from S and impersonates S.
3. C1 gets tricked to establish a connection with MITM rather than S.



Thanks.

-Usama

*Assumption*: The mechanism may be useful only when client needs to make a lot of connections to the exact same server S. Now if the server advertised different algorithms A1 and A2 to different clients C1 and C2, I think it needs to support both for max(L1,L2), if it does not know client's identities (handshake without client authentication). *Bigger concern*: What if S is already compromised at the time of connection (t=0)? or eventually gets compromised until max(L1,L2). Client continues to believe it is connecting to a secure server. How does the proposed extension protect? Now in my understanding, the "downgrade attack" that the draft is trying to prevent is: Is this correct? If so, how does the proposed extension protect? The initial connection may already be to already-compromised server (S), no? What am I missing?

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org