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. For the purpose of this discussion you can read "TLS layer" as "TLS". 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. 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. 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. 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. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
