On 04.01.26 00:50, Eric Rescorla wrote:
On Sat, Jan 3, 2026 at 3:42 PM Muhammad Usama Sardar <[email protected]> wrote:Thanks for the clarification and the reference; it is very helpful. At first glance, it neither defines "HTTP layer" nor "REST API layer". So similar to "TLS layer", you seem to have some terminology which is undefined in RFCs and may not be familiar to everyone. I will read through these specs and may have more questions to better understand your concerns and to propose some potential solutions.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.
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.
Thanks for the clarification. It resolves my concern.
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.
I think when someone brings new work, there is some "extra work" to be done somewhere. I believe changing application logic of each and every application may also be a lot of "extra work". Regarding testing, I could formally model HTTP semantics in addition to TLS to analyze the corner cases. So I don't think your argument by itself precludes the option to handle it within TLS.
-Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
