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.
but then those secrets
themselves need to undergo some internal transformations to be
useful. E.g., the [sender]_write_key and [sender]_write_iv.
Agree, this is about the later stages (using HKDF-Expand-Label) not shown in Figure in Section 7.1.
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.
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.

> 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


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

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

> ---
>
> 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?

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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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

Reply via email to