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. 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.
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.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.
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
