Thank you for responses. Please see inline. On 22.05.25 17:36, Eric Rescorla wrote:
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)
Agree, this is the first stage that is shown in Figure in Section 7.1.
Agree, this is about the later stages (using HKDF-Expand-Label) not shown in Figure in Section 7.1.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.
Seems fair to me, I am not asking 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.
Agree.
I tend to disagree unless you mean that client_early_traffic_secret and early_exporter_master_secret are not "session keys". These two secrets are not derived from Main Secret as currently defined. These are derived from Early Secret. If you actually mean that these are not session keys, I would like to know why.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.
I would appreciate an explicit entry in Table 2, rather than burying it deep in Section 4.2.11.2. Something like:> 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.
Mode = PSK | Handshake Context = ... | Base Key = binder_key
> --- > > 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.
Thanks for confirmation.
I am not a cryptographer either, so I may be completely wrong. I'll try to clarify my thought. I don't think "0" and "" are interchangeable in a way ProVerif implementation seems to indicate by using just one constant for both. It works in ProVerif because both endpoints are using the same key derivation functions. But if one endpoint was using "0" and the other was using "", they should end up with a different HKDF-Expand-Label, and never agree on transcript hash.> 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.
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?> --- > > 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.
For revised text, how about something like this:"This produces the /first stage/ of key schedule shown in the diagram below."
Also curious whether there was any reason to put "key derivation schedule" rather than "key schedule" since the former does not appear anywhere else in the whole document.
Please also add a caption to this figure. It would be easier to refer to it by just saying figure N rather than figure in Section 7.1.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
