Draft: draft-ietf-quic-tls

Commentary: This was a pretty serious omission , even if it was obvious enough that no one ever noticed when implementing it . 
 said : 
 The  thing should be addressed by . The 4 bits should be " Unused " to match the transport spec . I 'll fix that . 
 said : 
 Oh , so many things to unpack from a short comment ... ,  should be explicitly empty . I 'll create a PR for this and the other , below . TLS transcript is integrated into the derivation of the keys that we use , so we do n't need to include it again . 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 . 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 . with Context , so too with  , 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 is n't guaranteed . I 'm sure that an AEAD with variable - length nonce could manage , but no sense in being imprecise . 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 .
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.  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 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.  All uses of HKDF-Expand-
Label in QUIC use a zero-length Context.
Paragraph (version B):
Note that labels, which are described using strings, are encoded as
bytes using ASCII ASCII without quotes or any trailing NUL byte.
Paragraph (version B):
Other versions of TLS MUST provide a similar function in order to be
used with QUIC.
Paragraph (version B):
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.