On Sat, Jan 3, 2026 at 3:42 PM Muhammad Usama Sardar < [email protected]> wrote:
> On 03.01.26 21:59, Eric Rescorla wrote: > > On Sat, Jan 3, 2026 at 11:51 AM Muhammad Usama Sardar < > [email protected]> 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. > Huh? The way that TLS works is that it provides a channel for application traffic. In the case of HTTP, that application is HTTP. However, the TLS layer doesn't know what the application is or knows its semantics. This draft is trying to provide an arbitrary service for any application, and I'm challenging whether that will work adequately by looking at the case of HTTP. 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? > https://httpwg.org/specs/rfc9110.html and friends. > > 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. > QUIC is irrelevant here because it already has its own migration mechanism that preserves reliable transport semantics. https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-migration > 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"? > I'm not making an ask. What I'm saying is that I think it's likely that a lot of applications will not handle this behavior correctly because it's extra work to do so and not something that gets tested a lot. That creates a backward compatibility risk which can be averted simply by having the signal at the application layer, with the result that clients which are unaware of the signal simply continue to talk to the old server, thus preserving backward compatibility. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
