Hi, Usama:
Thanks for your endorsement to implement it at TLS layer. As your suggestion, if TLS 1.3 has no explicit session identifier, we can utilize the implicit one, for example, PSK, as the identification of the corresponding session. The idea of this draft is actually very straightforward: 1) Notify the client securely another address 2) Start one new TLS session which can utilize the PSK of the previous session(then skip the negotiation process for the new session). 3) Keep the application unnoticed, or application agnostic. Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Muhammad Usama Sardar Sent: Wednesday, January 28, 2026 8:21 PM To: Aijun Wang <[email protected]> Cc: [email protected]; [email protected]; Mohit Sahni <[email protected]>; Aijun Wang <[email protected]> Subject: [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 [ 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 <[email protected] <mailto:[email protected]> > 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
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
