[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

[Eric Rescorla <[e-mail]>]

On Sun, Jan 4, 2026 at 1:27 AM Aijun Wang <[e-mail]> wrote:

>                                      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)-----------------------------------------à
>

You had said earlier that the TLS stack should also be buffering and
re-sending `make-payment(1/2)`. Is that still your view?

-Ekr


> ==========================================================
>
>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]]
> *On Behalf Of *Eric Rescorla
> *Sent:* Sunday, January 4, 2026 10:12 AM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]>
> 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:* [e-mail] [mailto:[e-mail]]
> *On Behalf Of *【外部账号】 Eric Rescorla
> *Sent:* Tuesday, December 30, 2025 10:41 PM
> *To:* Aijun Wang <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Mohit Sahni
> <[e-mail]>; Aijun Wang <[e-mail]>
> *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 <[e-mail]>
> 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
>
>
>
>