Original text:
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 <del> 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. </del>  The current encryption level secret and the label "quic key" are input to the KDF to produce the AEAD key; the label "quic iv" is used these labels provides key separation between QUIC and TLS; see key- diversity.  The KDF used for initial secrets is always the HKDF-Expand-Label function from TLS 1.3; see initial-secrets.

Reviewer comments:
This was a pretty serious omission, even if it was obvious enough that no one ever noticed when implementing it.
NAME said:
The Context thing should be addressed by . The 4 bits should be "Unused" to match the transport spec. I'll fix that.
NAME said:
Oh, so many things to unpack from a short comment... Yes, Context should be explicitly empty. I'll create a PR for this and the other, below. The TLS transcript is integrated into the derivation of the keys that we use, so we don't need to include it again. As an aside, EAP-TLS1.3 use of 0x0D in the exporter is counter to the intended use of the field. They already have all the fixed key separation necessary through the use of the exporter label. The field is intended to capture variable, contextual information such as identities or other things that are not already folded into the handshake. I agree that using a different span of the handshake transcript for key derivation would be massively disruptive, that is why I would oppose doing that. As with Context, so too with Length, though that requires a little more text to address. That's in the PR too. Note: I had to decide between NMAX and NMIN and chose N_MAX. Though the values are the same for all of the AEADs we use, that isn't guaranteed. I'm sure that an AEAD with variable-length nonce could manage, but no sense in being imprecise. I want nothing to do with Derive-Secret. That's too far into TLS internals.
I think that the separation that we have now is good and that we do not need to change the design. Regarding IV length, as stated in the PR review comment, we are using TLS cipher-suites. Therefore I think we should be using what is defined in TLS 1.3 (i.e. ) rather than specifying a different rule.

Revised text:
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  <ins> function from the negotiated cipher suite.  All uses of HKDF-Expand- Label in QUIC use a zero-length Context. 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. </ins> The current encryption level secret and the label "quic key" are input to the KDF to produce the AEAD key; the label "quic iv" is used these labels provides key separation between QUIC and TLS; see key- diversity. <ins> Both "quic key" and "quic hp" are used to produce keys, so the Length provided to HKDF-Expand-Label along with these labels is determined by the size of keys in the AEAD or header protection algorithm.  The Length provided with "quic iv" is the minimum length of the AEAD nonce, or 8 bytes if that is larger; see AEAD. </ins> The KDF used for initial secrets is always the HKDF-Expand-Label function from TLS 1.3; see initial-secrets.