On Thu, May 22, 2025 at 11:15 AM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote:
> Thank you for responses. Please see inline. > On 22.05.25 17:36, Eric Rescorla wrote: > > 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 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. > I think we'd have to go over the text in this section to determine whether the statements made in this section apply to the early secret. They don't apply to the handshake secret. > > 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. > > 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. > > 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. > > 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. > I agree that they will not interoperate. I thought your question was whether the confusion about this impacted the security analysis. > > > --- > > > > 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. 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. For revised text, how about something like this: > > "This produces the *first stage* of key schedule shown in the diagram > below." > Sure. > 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. > No, I don't think of a reason. Just the way the text was written. > 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. > I'll take a look. -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
