Hi,Eric:
We should keep the application logic independent, or unware of the underlying
TLS switchover.
If there is some errors(application request out of order/loss of application
data etc.) in the application layer, it is the responsibility of the
application itself to rectify them, for example, resend/reassemble the
application requests.
In your following example, if there is any reason(the original session broke
temporarily, or the mentioned session switch process) lead the make-payment(1)
is lost, the client should send again the make-payment(1), or also the
make-payment(2).
We should know that the TLS layer do only what the application layer command,
and feedback the application layer about the final transmit status(success, or
failure). It doesn’t care the application logic themselves.
I don’t know why the TLS switchover needs to interfere with the application
logic?
This is also the reason that we want to keep the switchover at TLS layers, and
don’t touch the complex application logic themselves.
Best Regards
Aijun Wang
China Telecom
==========================================================================================
Client Server
<------------------ First TCP/TLS Connection ---------------->
POST /make-payment (1/2) ---\ /---------------- Switch servers
X
<---------------------------/ \------------------------------>
[Buffer /make-payment (2/2)]
<-------------------------------------------------------- ACK
<-------------------- New TCP/TLS Connection ---------------->
[If in application layer, the client side doesn’t receive the response from
make-payment, it needs to send again make-payment(1) and also the
make-payment(2)]
/make-payment (1/2)-----------------------------------------à
/make-payment (2/2) ----------------------------------------->
==========================================================
From: [email protected] [mailto:[email protected]] On
Behalf Of Eric Rescorla
Sent: Sunday, January 4, 2026 10:12 AM
To: Aijun Wang <[email protected]>
Cc: [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
On Sat, Jan 3, 2026 at 5:42 PM Aijun Wang <[email protected]
<mailto:[email protected]> > wrote:
Hi, Eric:
What we want to is similar with “Resumption and Pre-Shared Key(PSK)” that is
described in https://datatracker.ietf.org/doc/html/rfc8446#section-2.2
>From this section, we can know the application layer will not aware such
>session resumption, TLS layer handles all the procedure. Right?
Not necessarily. The TLS specification takes no position on when (1) clients
should attempt resumption and (2) servers should allow it.
What you described in previous examples can all happen in the resumption
process, and the application layer should have their own additional
confirmation/retry logic.
I'm not sure that's in fact true. The purpose of the examples was to explore
that, which is why I asked you to provide your own ladder diagrams showing how
you thought this worked. Again, can you please do that?
For the mentioned
draft(https://datatracker.ietf.org/doc/draft-wang-tls-service-affinity/), the
additional exchange signals are to transfer the new server address securely
after the initial connection.
What’s the client and server need do is to correlate the corresponding
cryptographic context to the new underlying TCP connection.
Do you have any suggestions to make the above intension more clearly in
https://datatracker.ietf.org/doc/draft-wang-tls-service-affinity/?
As I said, I think this is the wrong design, so my suggestion is you don't do
it.
To the extent to which you are trying to make the case otherwise, you really
need to show your work, which this message does not do.
-Ekr
From: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]> ] On
Behalf Of 【外部账号】 Eric Rescorla
Sent: Tuesday, December 30, 2025 10:41 PM
To: Aijun Wang <[email protected] <mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> ;
[email protected]
<mailto:[email protected]> ; Mohit Sahni
<[email protected] <mailto:[email protected]> >; Aijun Wang
<[email protected] <mailto:[email protected]> >
Subject: Re: [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
On Tue, Dec 30, 2025 at 2:10 AM Aijun Wang <[email protected]
<mailto:[email protected]> > wrote:
Hi, Eric:
Contrary to your conclusions, I think the application layer and TLS/TCP layer
should(already) have their own mechanisms to assure the data integrity,
Yes, which might or might not work correctly, because they are rarely tested.
there is no necessary to consider them again at the protocol layer, we need
just some guidance for the implementation of client/server sides themselves.
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.
In this case, the client doesn't know what has happened. You need
mechanisms either at the HTTP layer--or more typically at the REST API
layer--to do the right thing, which might be an idempotency layer
combined with client-side retransmit. This is all just a
straightforward application of the end-to-end argument, and there's no
real way around it as long as systems might asynchronously fail, but
it's also a source of defects (think about how many times sites tell
you not to press the submit button twice) because these mechanisms may
not have been exercised or tested. For instance, if the server is high
reliability and the client just assumes that anything it sent works,
that will be good enough a very large fraction of the time, but not if
the server has a high failure rate.
[WAJ] From the example, we can know each application has its own confirmation
mechanism, because most of them are asynchronous.
The application knows there will be possibilities that the server crash, or the
underlay connection broken.
Yes. I said exactly this, but again, they're not always going to be
implemented correctly, and that's largely OK because most
connections don't fail. You're talking about making an exceptional
condition routine.
Unfortunately, these transaction semantics only exist at the HTTP
layer, not the TLS layer, so the TLS layer has no way of knowing to
wait for the 200 OK, it just knows that the client sent some data, but
not whether that reflects an outstanding request or something else;
recall that TLS doesn't even know about the HTTP request/response
semantics, because it's just a dumb pipe.
[WAJ] TLS needn’t aware the 200 OK signal, it is the job of application layer.
TLS/TCP needs only transmit the data from the application layer correctly to
other side.
So you're saying that in the example above, the TLS layer ought to inform
the HTTP layer that the connection has failed and trust the HTTP layer
to retry in a safe fashion?
In your email, you suggest that the client ought to:
1. Wait for the server's TCP ACK of all transmitted data, with the
implied semantics being that once the message is ACKed it will be
reliably delivered to the server, not just to the TCP stack.
[WAJ] No. I emphasize only the TCP ACK and the TCP stack. Not the application
stack. That is to say, receiving the TCP ACK doesn’t represent the application
layer ACK.
2. Buffer any data it receives form the cleint while waiting for the
ACK and retransmit it on the new connections.
[WAJ] Buffer any data it receives, but can’t transmit immediately during the
switchover process, not waiting for the application ACK.
I don't understand what you're saying here. Can you please provide:
1. A concrete description of what you believe the rules that the
TLS stack should be following.
2. New versions of my ladder diagrams that show what you believe the correct
behavior is.
-Ekr
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
