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

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

Hi UFMRG and CFRG,

We presented some issues about the implementation of TLS 1.3 key 
schedule in formal models in the past meetings (e.g., 119 [1] and 120 [2]).

We have found some additional issues (see forwarded email below) in the 
key schedule for which we did not receive satisfactory answers at TLS WG 
(follow-up discussion [3] and [4]). I was wondering if someone has any 
insights/opinions on the following issues on TLS 1.3 key schedule to 
share with us.

Thanks,
Usama

[1] 
https://datatracker.ietf.org/meeting/119/materials/slides-119-cfrg-formal-analysis-of-ra-tls-00
[2] 
https://datatracker.ietf.org/meeting/120/materials/slides-120-ufmrg-towards-formal-analysis-of-attested-tls-01.pdf
[3] https://mailarchive.ietf.org/arch/msg/tls/Ho98JDz06Tuz_bQZPMNdgIs3Q5A/
[4] https://mailarchive.ietf.org/arch/msg/tls/qTkiEMP3E5bmfJhmfUaCTE2HuhA/



-------- Forwarded Message --------
Subject: 	Re: [TLS] Key Hierarchy TLS 1.3 RFC8446(bis)
Date: 	Wed, 21 May 2025 21:04:41 +0200
From: 	Muhammad Usama Sardar <[e-mail]>
To: 	[e-mail]
CC: 	Hugo Krawczyk <[e-mail]>



Following up on an old thread with some additional 
issues/questions/observations:

(Almost all of it applies to RFC8446 too, but I am using bis as a 
reference.)

*Issue 1: Ambiguity of "Session Keys"*

/TL;DR/: Please define "session keys" /precisely/. */
/*

/Details:*
*/

Appendix F.1 of RFC8446bis-12 states:

 > A set of "session keys" (the various secrets derived from the main 
secret) from which can be derived a set of working keys.

Figure in section 7.1 shows that there are 4 secrets derived from main 
secret:

 1. client_application_traffic_secret_0
 2. server_application_traffic_secret_0
 3. exporter_secret
 4. resumption_secret

 From the above statement, I am assuming that the set of all these four 
secrets is what constitutes "session keys". But then the literature 
sharply contradicts this. For example, Dowling et al. [1] label 4 other 
keys in addition to these as "session keys" (see Figure 2 in [1]):

  * client_early_traffic_secret
  * early_exporter_master_secret
  * client_write_key for Record type = Handshake
  * server_write_key for Record type = Handshake

The first two in this list are derived from Early Secret while the last 
two are derived from Handshake Secret, immediately contradicting the 
description of "session keys" in Appendix F.1 quoted above.

So it would be helpful to explicitly state which keys exactly are 
included in "session keys".

---

*Issue 2:* *"Binder Finished Key"*

/TL;DR/: Please confirm if this is correct and if so, mention it 
explicitly in RFC8446bis.*/
/*

/Details:/

Dowling et al. [1] also mention "Binder Finished Key" derived from 
Binder Key (Figure 2 and Table 1 in [1]). In my read of RFC8446bis-12 
(particularly section 4.4 and 4.4.4), I could not figure out where this 
is coming from. The only mention of binders in these sections is:

 > The PSK binders also perform key confirmation, in a similar fashion.

Perhaps the intention here was not to say key confirmation alone, but 
also handshake integrity via Finished message?

Specifically, Table 2 never mentions binder key, as one of the base keys 
for the derivation.

---*
*

*Issue 3: Empty string vs. zero-filled string* *in key schedule:*

/TL;DR/: These two have been colluded in ProVerif implementation 
[2].*//*Are there any already known real-world security implications of 
doing so?*/
/*

/Details:/

ProVerif implementation [2] of key schedule has colluded empty string "" 
with a zero-filled string "0". I think other than the two "0" in 
HKDF-Extract for Early Secret and Master Secret, all others should be 
empty strings instead and hence should be represented by some other 
constant other than "zero" in ProVerif. I will create an issue on this 
in the reftls repo.

In my understanding, "0" is intended for the case of /no prior key/ for 
HKDF-Extract and "" is intended for the case of /no additional context/ 
for HKDF-Expand-Label.

Does someone know any security implications that could originate from -- 
for example -- using "0" instead of "" in HKDF-Expand-Label? I think 
depending on HMAC construction used, this might lead to security 
concerns, generating unexpected keys and breaking the key agreement at 
the very least.

---

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

I, Arto, Hannes and Thomas tried to consolidate this in our earlier work 
(Figure 2 in [3]), and match each symbol to the TLS specifications 
(Tables 2-5). But we missed issue 3 at least (and perhaps more). I would 
be happy if someone could have a look at the key schedule (section IV in 
[3]) to help us thoroughly validate the formal model. This would be very 
helpful for the formal analysis of drafts (e.g., attested TLS) which 
propose changes in the key schedule.

Thanks,

Usama

[1] https://eprint.iacr.org/2020/1044.pdf

[2] 
https://github.com/Inria-Prosecco/reftls/blob/master/pv/tls-lib-draft20.pvl

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