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

[Muhammad Usama Sardar]

Hi UFMRG and CFRG,






Thanks,
Usama

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. [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 <muhammad_usama.sar...@tu-dresden.de>
To:     tls@ietf.org
CC:     Hugo Krawczyk <h...@ee.technion.ac.il>







*Issue 1: Ambiguity of "Session Keys"*

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

/Details:*
*/

Appendix F.1 of RFC8446bis-12 states:





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



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





---

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


/*

/Details:/



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





---*
*

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


/*

/Details:/







---

*Issue 4: Full key derivation schedule:
*


/*

/Details:/

The text in section 7.1 says

> This produces a full key derivation schedule shown in the diagram below.





Thanks,

Usama

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

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.) > 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: 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]): 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". /TL;DR/: Please confirm if this is correct and if so, mention it explicitly in RFC8446bis.*/ 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: 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. /TL;DR/: These two have been colluded in ProVerif implementation [2].*//*Are there any already known real-world security implications of doing so?*/ 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. /TL;DR/: Please add /full/ key derivation schedule in specifications in RFC8446bis.*/ 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. [2] https://github.com/Inria-Prosecco/reftls/blob/master/pv/tls-lib-draft20.pvl

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

smime.p7s
Description: S/MIME Cryptographic Signature

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