[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

[Muhammad Usama Sardar <[e-mail]>]

On 03.01.26 21:59, Eric Rescorla wrote:

> On Sat, Jan 3, 2026 at 11:51 AM Muhammad Usama Sardar 
> <[e-mail]> wrote:
>
>     I am trying to follow this thread. I am not sure in what sense
>     both of you are using "TLS layer". It occurs 3x in RFC8446bis-14
>     but is never defined. It is also not defined in this draft. Does
>     it refer to handshake and record protocols of TLS? Or does it
>     refer to everything that is implemented as part of the TLS
>     library? or something else?
>
> In this context, it refers to the stuff defined in RFC 8446, which has 
> an implicit interface at the bottom to some reliable delivery protocol 
> and at the top to the application layer.
If at the top it is to application layer, then what exactly is "HTTP 
layer" and "REST API layer" in one of your emails, since the draft does 
not mention that. Could you please point me to the relevant RFCs/specs 
for understanding these layers in the sense you are using them and your 
ladder diagrams?
> For the purpose of this discussion you can read "TLS layer" as "TLS".
Thanks, that's very helpful.
>
>     In general, what is "TLS layer" in QUIC for example?
>
> Yes, QUIC breaks some of the TLS abstraction boundaries, but that's 
> not relevant in this case, which is about application protocols over TLS.
I don't see why QUIC is irrelevant here because the draft does 
explicitly cite QUIC. It seems to omit a single step in QUIC but does 
not seem to put QUIC out of scope. So I believe my question still stands.
>
>     On 30.12.25 15:40, Eric Rescorla wrote:
>>     I don't know what you mean by "The same session identifier".
>
>     I think it could refer to a key derived from Main Secret.
>
> Perhaps, but as noted in my previous email, I'd like to hear Aijun 
> explain the protocol he has in mind.
Noting a strange blender of TLS 1.2 and TLS 1.3 in the draft (which I 
think I have pointed out before), I can imagine authors are not much 
into TLS. So it was intended to help them. I don't see why such a key 
would not be an option.
>
>>     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 have presented this argument a couple of times but I don't
>     think it's a good one. I believe nothing in this world is
>     "/always/ going to be implemented correctly", including TLS itself
>     which has 1000+ related CVEs currently.
>
> I don't see the relevance of this point.

The relevance of my point here is that your ask seems quite unrealistic 
to me even with formal analysis. I can do the formal analysis for them 
to gain more confidence that it's not breaking anything but nothing can 
ever reach the point of "/always/ going to be implemented correctly".

> We take the environment as we find it, and try to avoid making changes 
> that break things even if other parts of the environment have defects. 
> For example, we went to a huge amount of effort to avoid having TLS 
> 1.3 fail with existing middleboxes.

Sure, but how is it relevant to the ask for "/always/ going to be 
implemented correctly"? Are you claiming that after this huge effort, 
you now have the guarantee that it's "/always/ going to be implemented 
correctly"?

Authors, could you please update the draft to TLS 1.3 and add all the 
relevant references for me to help you out?

-Usama