Hi, Eric and Martin:
During my presentation in IETF 124 meeting for this service affinity proposal, you raised the following questions that can be summarized as the followings: 1) How to assure there is no application data loss during the switch take place? 2) How to keep the application unware about the switchover, because the TCP connection switchover? Regarding to the question 1), after discussing with some experts offline, we think: 1.1) TLS is based on TCP, and the TCP layer can assure the application data be transferred successfully to the peer, based on the TCP ACK mechanism. 1.2) The client can decide when to switchover, based on the peer’s TCP ACK. 1.3) If some application data comes to the client during the switchover, the client can store them temporarily. This is local implementation consideration, needs not the extension of the protocol. Regarding to question 2), we think: 2.1) The application runs on the TLS layer. If the TLS layer doesn’t notify the application during the switchover, the application needs not be aware for the underlying switchover 2.2) TLS layer should only keep the switchover as quickly as possible, for example, reuse the previous negotiated shared key etc, as we proposed in the draft. 2.3) The application needs just send the data to the same TLS instance. How about your concerns regarding to the above explanation? Should we include them into the document for further clarify if the above considerations is reasonable? Happy holiday to you all! Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Eric Rescorla Sent: Tuesday, October 28, 2025 4:13 AM To: Mohit Sahni <[email protected]> Cc: Aijun Wang <[email protected]>; [email protected]; [email protected]; Aijun Wang <[email protected]> Subject: [TLS] Re: FW: New Version Notification for draft-wang-tls-service-affinity-00.txt On Mon, Oct 27, 2025 at 1:02 PM Mohit Sahni <[email protected] <mailto:[email protected]> > wrote: Hi Eric, One concern regarding using HTTP Alt Svc is that this limits the solution to HTTP based application, however TLS based solution helps with other application protocols too e.g. FTP or SMTP or any other protocol that uses STARTTLS construct. Yes, I'm aware of that. However, for the reasons Indicated in my response upstream, I think it's a feature that it happen at the application layer in a protocol-specific fashion. -Ekr -Mohit On Sun, Oct 26, 2025 at 7:55 PM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Eric: Thanks for your comments. Your understanding of the overall procedure for this proposal is correct. But, as indicated by Usama and replied by Mohit, the detail procedures in Figure 2 of this document should be based on TLS 1.3 https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc8446-23section-2D2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc8446-23section-2D2&d=DwIFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=S278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&s=B0_YVjIgvDRP9AWMrgVcHGU594aeWIXGEZAZqvD8Liw&e=> &d=DwIFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=S278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&s=B0_YVjIgvDRP9AWMrgVcHGU594aeWIXGEZAZqvD8Liw&e= If there is any misunderstanding due to the above ignorance, let's discuss further based on our future update based on TLS 1.3 Anyway, I try to explain our considerations in more detail inline below. Best Regards Aijun Wang China Telecom -----Original Message----- From: [email protected] <mailto:[email protected]> [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of 【外部账号】 Eric Rescorla Sent: Saturday, October 25, 2025 1:24 AM To: Aijun Wang <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [TLS] FW: New Version Notification for draft-wang-tls-service-affinity-00.txt Document: draft-wang-tls-service-affinity-00.txt I'm a little confused about the requirements driving this design. At a high level, it seems to me that you have the following set of events: 1. The client connects to the server using TLS via an anycast address A1. 2. The server tells the client that it can/should be reached at a new non-anycast address A2. 3. The client reconnects to the server at A2. 【WAJ】Yes I would make several points. First, the mechanism you propose seems heavyweight for this purpose. In particular, I don't understand why you need any authentication at all for the new address indication (the MigrationToken) because the client is going to authenticate to the server via normal TLS mechanisms. Recall that TLS is designed for a Dolev-Yao style attacker and doesn't trust the network at all, including the binding of DNS name to IP address; even if the client were provided with a completely false IP address for the server this would not allow impersonation of the server. 【WAJ】The "Migration_Token" is manly used to bind the new connection to the previous session. Second, I don't understand why you need the server to validate the MigrationToken. What properties are being bound to this token? It seems better to just bind whatever properties those are into the session ticket and treat this as a new connection. 【WAJ】The main properties in "Migration_Token" is the session_id, which can be used to lookup the previous negotiated PSK. Such design can eradicate the new PSK negotiation procedure. Third, I'm skeptical that the TLS layer is the right place to do this kind of migration, because you have race conditions where one side initiates a migration and the other side has outstanding data which will never be processed. These kinds of issues need to be resolved at the application layer, which is also a more convenient layer to initiate migration. 【WAJ】The initial purpose is to switch the address ASAP. There may be some race conditions(would you like to illustrate some?) and extra signal may be necessary later to refine the switchover. Overall, ISTM that a better design would be to just use something like HTTP Alt-Svc to steer the client to a different address, rather than doing this at the TLS layer. If you disagree, I think it would be helpful to explain the requirements that lead to this design. 【WAJ】Before proposing the switchover at TLS layer, we have analyzed the other possible solutions, for example, via application load balance, http redirection and DNS redirection(please review https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dwang-2Dtls-2Dservice-2Daffinity-2D00-23name-2Dintroduction <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dwang-2Dtls-2Dservice-2Daffinity-2D00-23name-2Dintroduction&d=DwIFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=S278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&s=wjYYFdlQkm_hyIPH5wlCSjErLDcYyWrJ_FkapLN_7k0&e=> &d=DwIFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=S278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&s=wjYYFdlQkm_hyIPH5wlCSjErLDcYyWrJ_FkapLN_7k0&e= ). The reason that we propose the switchover at TLS layer, due to the optimization selection decision is made at the network itself(together with the availability of server resource), not at the application layer. The application is difficult to know which is the best server that can match the client's QoS requirements.(we call it the combination optimization process, which is the goal of the CATS WG). And, actually, QUIC has also such migration process: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc9000-23name-2Dconnection-2Dmigration <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc9000-23name-2Dconnection-2Dmigration&d=DwIFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=S278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&s=IhoM_hlC_ptCYdMMOa72ZAogUt3qS7ywnXCGgH8gpWA&e=> &d=DwIFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=J7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=S278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&s=IhoM_hlC_ptCYdMMOa72ZAogUt3qS7ywnXCGgH8gpWA&e= -Ekr On Tue, Oct 21, 2025 at 2:10 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: > Hi, All: > > We have submitted one new draft regarding to the service affinity > function for TLS based application. > We are also applying the time slot for the presentation on the coming > IETF > 124 meeting. > > Wish to get your comments/suggestions on this topic before the > meeting, and we can also discuss further during the on-site meeting. > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: [email protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]> ] > Sent: Friday, October 17, 2025 4:34 PM > To: Aijun Wang <[email protected] <mailto:[email protected]> >; > Ketul Sheth < > [email protected] <mailto:[email protected]> >; Mohit > Sahni > <[email protected] <mailto:[email protected]> >; Wei Wang > <[email protected] <mailto:[email protected]> > > Subject: New Version Notification for > draft-wang-tls-service-affinity-00.txt > > A new version of Internet-Draft draft-wang-tls-service-affinity-00.txt > has been successfully submitted by Wei Wang and posted to the IETF repository=
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
