On Sun, Oct 26, 2025 at 7:54 PM Aijun Wang <[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://datatracker.ietf.org/doc/html/rfc8446#section-2 > If there is any misunderstanding due to the above ignorance, let's discuss > further based on our future update based on TLS 1.3 > > No I'm not confused by that. > > 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. > As I said, you don't need to do that. You can bind all the information you need to the PSK. > 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. > See above. You can put this information in the PSK label > 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?) I gave an example above. To expand on this a bit: Client sends an application protocol message that induces some change on the server Server sends a migration alert. How does the client know whether its message was processed? TLS has no way of telling you, though the application layer might have an ACK. 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://datatracker.ietf.org/doc/html/draft-wang-tls-service-affinity-00#name-introduction > ). > 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). > Can you expand on this in more detail? Why can't the network inform the application of what to do, just as it does the TLS stack (they are often co-located in any case)? > And, actually, QUIC has also such migration process: > https://datatracker.ietf.org/doc/html/rfc9000#name-connection-migration Yes, I'm familiar with the QUIC mechanism, but unlike the mechanism you propose, the QUIC abstraction looks like a single connection and so issues like the one I raised above do not occur, as QUIC naturally ensures reliable transmission of application layer messages between the endpoints even during a migration. By contrast, the design you propose is just two TLS connections, which don't have this kind of continuity.e -Ekr > > > > -Ekr > > > > > > > > > > > > > > > > On Tue, Oct 21, 2025 at 2:10 AM Aijun Wang <[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]] > > Sent: Friday, October 17, 2025 4:34 PM > > To: Aijun Wang <[email protected]>; Ketul Sheth < > > [email protected]>; Mohit Sahni > > <[email protected]>; Wei Wang <[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]
