[TLS] Re: 【Reply to the comments after the presentation in Montreal】RE: Re: FW: New Version Notification for draft-wang-tls-service-affinity-00.txt

[Muhammad Usama Sardar <[e-mail]>]

[ Looping back to the point where the question was raised ]

I did some preliminary working for you. It is purely at TLS layer, i.e., 
I don't consider higher layers like HTTP. It /may/ provide you a way 
forward for this particular question.

On 30.12.25 15:40, Eric Rescorla wrote:
> On Tue, Dec 30, 2025 at 2:10 AM Aijun Wang <[e-mail]> 
> wrote:
>
>     If there is data arrival during the switchover, the internal
>     implementation logic is the application layer will call the api of
>     TLS/TCP to send some data, with the same session identifier.
>
> I don't know what you mean by "The same session identifier". There is 
> no concept in TLS that two different TCP connections are somehow the 
> same conceptual flow of data. PSK identifiers solely identify keys.

Session identifier is a common confusion that arises from TLS 1.2. In 
contrast, TLS 1.3 has no session identifiers. It instead has the concept 
of /connection/ and the identifiers of TLS 1.3 connection are just 
implicit. Depending on specific scenario, the following three keys may 
uniquely identify a TLS 1.3 connection:

 1. Shared DH secret (g^xy)
 2. Handshake secret: In addition to #1, it has randomness from PSK, if
    one is being used (and your draft seems to be using PSK).
 3. Main secret: Secrets derived from this secret have server
    authentication, as the handshake transcript up to server Finished is
    included.

So depending on your specific scenario, you could replace /session_id/ 
in /MigrationToken/ by one of those.

Having said that, you have to defend yourself why for your scenario, you 
want to do it within TLS handshake, because the draft is very confusing 
to me -- in terms of its threat model, desired security goals and 
protocol (mixing TLS 1.2 and TLS 1.3).

-Usama