TLS-31: Usage of HKDF is vague

[gloinul]

Section 5.2:

The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in". The hash function for HKDF when deriving initial secrets and keys is SHA-256 [SHA].

Looking at RFC 5689 the HKDF-Expand function defines what is referenced as label as "info" input. It is a string. It is unclear that this is an ASCII string, but based on what is written it looks like something where each character is an octet is assumed, thus no UTF-16 or UTF-32 strings would work as intended.

If I am correct I think the draft can be improved by being explicit like in TLS that the label used as input into the functions as ASCII. So adding something like this sentence from RFC8446 is likely appropriate:

The labels specified in this document are all ASCII strings and do not
include a trailing NUL byte.

[gloinul]

Actually I think I understand what the issue is: Lets look at these three paragraphs in Section 5.2:

This secret is determined by using HKDF-Extract (see Section 2.2 of [HKDF]) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and a IKM of the Destination Connection ID field. This produces an intermediate pseudorandom key (PRK) that is used to derive two separate secrets for sending and receiving.

The secret used by clients to construct Initial packets uses the PRK and the label "client in" as input to the HKDF-Expand-Label function to produce a 32 byte secret; packets constructed by the server use the same process with the label "server in". The hash function for HKDF when deriving initial secrets and keys is SHA-256 [SHA].

The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include TLS 1.3.

I got the impression that the HKDF-Expand function was the one from RFC5689 and not the one from TLS1.3. So I think what is needed to clarify this is that the second paragraph needs to explicitly provide the HKDF-Expand-label function with section and document reference. I still think it should be made clear that the labels are ASCII, but that is clear in TLS 1.3 compared to RFC5689.

[larseggert]

Based on #4201, labeling this as "editorial"

[gloinul]

Changes looks good, resolve the issue.