I'd like to take a step back here and talk about the overall setting. This is a minor revision to RFC 8446, which has already been published. It includes useful clarifications and we'd like to get it out the door.
You're proposing an expansion to the scope of work that will then have to be carefully checked for correctness, as the whole principle is that it's supposed to be comprehensive. I'd be happy to see that on the TLS wiki, but I don't think it's helpful to try to cram it into the RFC at this time. A few more detailed comments below. -Ekr On Mon, Jun 2, 2025 at 10:35 AM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote: > > On 30.05.25 18:08, Eric Rescorla wrote: > > > >> > Issue 2: "Binder Finished Key" >> >> I would appreciate an explicit entry in Table 2, rather than burying it >> deep in Section 4.2.11.2. Something like: >> >> Mode = PSK | Handshake Context = ... | Base Key = binder_key >> > > I don't think this change is indicated. It is not a Finished key. > > ok fine, but the least we should do is to make PSKBinderEntry explicit. I > have submitted a PR [1]. Please check. > > [1] https://github.com/tlswg/tls13-spec/pull/1392 > This does not appear to be correct. But more generally, I'm just not following why you think this is necessary. The text says: The PskBinderEntry is computed in the same way as the Finished message (Section 4.4.4) but with the BaseKey being the binder_key derived via the key schedule from the corresponding PSK which is being offered (see Section 7.1). And then 4.4.4 provides the expansion: finished_key = HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) Why is this confusing? > - The formal model of ECH [3] has invented a new key in the key > schedule, namely "client_fkad" [4] which they claim to be modeling > "[sender]_finished_key" (in addition to the two finished keys). I don't > find anything like this in the TLS or ECH specs. So where is this coming > from? > > This appears to be the Finished key used for post-handshake authentication. The third line in the table at the end of 4.4.4.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
