[TLS] Re: Key Hierarchy TLS 1.3 RFC8446(bis)

[Muhammad Usama Sardar]

On 02.06.25 19:52, Eric Rescorla wrote:

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.

Are you trying to say that clarifications on key schedule are not useful? Specially, given that many people have got it wrong?

    On 30.05.25 18:08, Eric Rescorla wrote:

On Mon, Jun 2, 2025 at 10:35 AM Muhammad Usama Sardar <muhammad_usama.sar...@tu-dresden.de> 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


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?

This does not appear to be correct. But more generally, I'm just not following

The thing that I am really struggling to understand is that the key for PskBinderEntry is computed the same way as finished key but then you said earlier that it is "not technically a Finished key" [1]. So what is the definition of a Finished key and why does the key for PskBinderEntry not fulfill that criteria (while being computed in exactly same way)?

[1] https://mailarchive.ietf.org/arch/msg/tls/Ho98JDz06Tuz_bQZPMNdgIs3Q5A/

      * 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.

Thanks, I will check this.

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org