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

[Muhammad Usama Sardar <[e-mail]>]

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

>>
>>     > ---
>>     >
>>     > Issue 4: Full key derivation schedule:
>>     >
>>     > TL;DR: Please add full key derivation schedule in
>>     specifications in RFC8446bis.
>>     >
>>     > Details:
>>     >
>>     > The text in section 7.1 says
>>     >
>>     > > This produces a full key derivation schedule shown in the
>>     diagram below.
>>     >
>>     > The figure, however, by no means is anything close to a full key
>>     > schedule. It shows only the first stage of keys. Seems like it
>>     would
>>     > be very beneficial if at least the Appendix of RFC8446bis
>>     includes a
>>     > full key derivation schedule. Right now, the key schedule is
>>     > scattered around in sections 7.1, 7.3, 7.5, 4.4 and 4.4.4.
>>
>>     This diagram is already quite large, so I fear it would be a lot of
>>     work to produce something that was readable. I agree it's not helpful
>>     to say "full" here, and I'd welcome some revised text.
>>
>     Happy to propose revised text but without such a complete diagram,
>     I don't know how we can have consensus on what is a "full" key
>     schedule. For example, how can I be sure that I have not missed a
>     key buried somewhere deep in the specs? How can I be sure that the
>     "reference" key schedule -- that I am using to validate the key
>     schedule -- is correct and complete?
>
> Well "full key schedule" isn't used otherwise, so I'm not sure we need 
> to have a definition for this.
I am not asking for a definition per se. See below.
> Are you saying that there is some lack of clarity on what keys are 
> generated, or merely that
> you think it requires a close read to find it.

Well, I may be a careless reader but many experts who have several years 
of work on TLS have got it wrong too. In particular, the level of detail 
in ECH formal analysis [3] is really amazing, but they have got the key 
schedule wrong too. I will share some statistics of my preliminary working:

  * The formal model "reftls" [2] has missed at least 6 keys and has
    generated at least 12 keys incorrectly.
  * The formal model of ECH [3] has missed at least 5 keys and
    has generated at least 12 keys incorrectly.
  * 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?

I agree with you that it is perhaps a lot of work to have a full key 
schedule diagram and to still keep it readable. But I haven't received a 
satisfactory answer to my question, namely how do I ensure that my 
"reference key schedule" is correct and complete? Who other than TLS WG 
can provide such a "reference key schedule"? It is not even clear how 
many keys are there in the full key schedule.

I am not insisting on a diagram. It could be in text form, e.g., a 
complete list of *all keys* as a starting point. It could be in the 
Appendix.

I will happily propose something as a starting point. To my 
understanding, it would be table 3 in [5] + PSKBinderEntry + 
[sender]_write_iv. Is there any other key?

Usama

[2] 
https://github.com/Inria-Prosecco/reftls/blob/master/pv/tls13-draft20-only.pv 


[3] https://gitlab.inria.fr/chevalvi/echo_tls

[4] 
https://gitlab.inria.fr/chevalvi/echo_tls/-/blob/9fd6b2a0523087d41ba480c6180b9da92833ca50/libraries/key_schedule.pvl#L95

[5] https://ieeexplore.ieee.org/document/10752524