Draft: draft-ietf-quic-tls

Commentary: This was , I think clear , but the use of HKDF - Expand - Label and the encoding of labels into octets could be even more explicit . 
 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 ] . 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 . 
 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 ] . 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 . 
 Based on , labeling this as " editorial " 
 Changes looks good , resolve the issue . 
 nits
Paragraph (version A):
The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of TLS13 is used, using the hash
function from the negotiated cipher suite.  Other versions of TLS
MUST provide a similar function in order to be used with QUIC.
Paragraph (version B):
The keys used for packet protection are computed from the TLS secrets
using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label
function described in Section 7.1 of TLS13 is used, using the hash
function from the negotiated cipher suite.  Note that labels, which
are described using strings, are encoded as bytes using ASCII ASCII
without quotes or any trailing NUL byte.  Other versions of TLS MUST
provide a similar function in order to be used with QUIC.
Paragraph (version A):
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.
Paragraph (version B):
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
from TLS TLS13 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.