Thanks for your note. Some responses below.
> 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: > > client_application_traffic_secret_0 > server_application_traffic_secret_0 > exporter_secret > 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". I agree that there is some ambiguity here, but it seems like to some extent the ambiguity is in the published literature. The general idea here is that we generate a set of keying material from the various secrets (Early, Handshake, Main/Master) but then those secrets themselves need to undergo some internal transformations to be useful. E.g., the [sender]_write_key and [sender]_write_iv. ISTM that one could prove either the security of the directly derived keys or of the leaf keys, but that this document doesn't need to take a position on this. WRT to the particular list you have from Dowling, I don't understand why one would include [sender]_write_key for handshake, but not for application. However, this text does seem clear even if others used a different definition; given that this is not part of the protocol definition but just in an appendix listing the security properties, I think it's reasonable to say as-is. > 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. Here too, it seems like we have a situation where the specification is clear: 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). It seems like Dowling has chosen to call the output of the computation indicated in S 4.4.4 but with BaseKey as the binder key as a "Binder Finished Key". I don't think that's an unreasonable choice, even though it's not technically a Finished key, just computed in the same fashion. > --- > > 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. That's correct. > 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. I'm not a cryptographer but I don't know of any impacts. Glancing quickly at the specification, it doesn't appear that there are any situations where you could have either "" or some value, so I don't *think* there's room for ambiguity here. I'm not sure what you mean by "depending on HMAC construction used", as HMAC is a single construction just instantiated with hashes. I agree it would be good to get some confirmation here. > --- > > 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. -Ekr On Mon, Nov 11, 2024 at 7:20 AM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote: > Just a quick update/reminder on this: > > The authors acknowledged that their implementation of key schedule in > ProVerif was incorrect [5-6]. So this part of the mystery was resolved. > > However, it is still unclear whether there are any *practical* attacks if > Derive-Secret is skipped in generating handshake and master secrets. > > Again, I am not much into computational analysis. I may be missing > something but I would very much like to know what I am missing. Is there > any intuitive explanation for understanding why Derive-Secret is required? > > Usama > On 22.12.23 11:11, Muhammad Usama Sardar wrote: > > Hi Hugo, > > Following the related sources [1-4], it appears to be - as Eric called it > - a theoretical and futuristic concern. In my understanding, the main > concern was that with the key hierarchy of draft 18: > > - the Handshake Secret could collide with binder_key if the attacker > is somehow able to match (EC)DHE secret with the label to the corresponding > Derive-Secret. > - the Handshake Secret could collide with client_early_traffic_secret > if the attacker is somehow able to match (EC)DHE secret with the label to > the corresponding Derive-Secret. > > The reasoning for 2nd Derive-Secret is even more far-fetched. If in the > future the IKM input to HKDF-Extract (zero) changes, then similar collision > may happen between Master Secret and client_handshake_traffic_secret or > server_handshake_traffic_secret. So my question more precisely is: > > - Is there any *practical* security implication for missing the > additional Derive-Secrets? Has this ever been *practically* exploited? > Has anyone else explored this? > > Now about the Inria paper that you have mentioned, I am not much > knowledgeable about computational analysis. I understand that it helped > them remove the assumption (that DH group elements do not match the > corresponding labels) in their proof in CryptoVerif but the corresponding > formal analysis in ProVerif in the same paper does not support this view, > i.e., all properties remain the same regardless of the additional > Derive-Secret. > > Moreover, the implementation of key hierarchy in draft 20 in ProVerif by > the authors is incorrect [5-6]. For instance, due to a strange reason and > beyond our understanding, the draft 20 implementation does not use the > Derive-Secret for Master Secret [5]. Do you have any thoughts/opinion on > this? The same implementation is being used by other extensions as a > baseline, including Lurk [7]. > > Usama > > [1] https://github.com/tlswg/tls13-spec/pull/875 > > [2] https://mailarchive.ietf.org/arch/msg/tls/cS4vdMvENOGdpall7uos9iwZ5OA/ > > [3] > https://datatracker.ietf.org/meeting/98/materials/slides-98-tls-tls13-00 > > [4] > https://www.youtube.com/watch?v=oSwXkhVd2ts&list=PLC86T-6ZTP5jo6kIuqdyeYYhsKv9sUwG1&ab_channel=IETF-InternetEngineeringTaskForce > > [5] https://github.com/Inria-Prosecco/reftls/issues/6 > > [6] https://github.com/Inria-Prosecco/reftls/issues/7 > > [7] https://github.com/lurk-t/proverif > > > On 17.12.23 21:05, Hugo Krawczyk wrote: > > See full thread here > https://mailarchive.ietf.org/arch/msg/tls/cS4vdMvENOGdpall7uos9iwZ5OA/ > > See also how this helped analysis here (search for reference [73] > https://inria.hal.science/hal-01528752v3/file/RR-9040.pdf > > On Sat, Dec 16, 2023 at 1:16 PM Muhammad Usama Sardar < > muhammad_usama.sar...@tu-dresden.de> wrote: > >> Hi all, >> In the key schedule (section 7.1) of RFC8446(bis), what is the rationale >> for using *Derive-Secret(., "derived", "")* in the derivations of >> Handshake and Master Secrets? Since this change was made in draft 19, I >> expect there should be some reasoning of why this was added. Specifically, >> what are the security implications if this step is missed, i.e., >> >> - if Early Secret is directly used as the Salt argument for >> HKDF-Extract of Handshake Secret; >> - and similarly if Handshake Secret is directly used as the Salt >> argument for HKDF-Extract of Master Secret. >> >> Regards, >> >> Usama >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
