[ 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]>
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
