From d64bfcdd4aff399219736541484bd0109b3e88c7 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 14 Oct 2020 10:58:27 +1100 Subject: [PATCH 1/2] Clear up confusion about label encoding This was, I think clear, but the use of HKDF-Expand-Label and the encoding of labels into octets could be even more explicit. Closes #4197. --- draft-ietf-quic-tls.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index efd7f46348..29f0cd90a5 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -924,8 +924,10 @@ based on the client's initial Destination Connection ID, as described in 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. +cipher suite. Note that labels, which are described using strings, are encoded +as bytes using ASCII {{?ASCII=RFC0020}} without quotes or any trailing NUL +byte. Other versions of TLS MUST provide a similar function in order to be +used with QUIC. 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 to derive the @@ -950,10 +952,11 @@ 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=DOI.10.6028/NIST.FIPS.180-4}}. +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=DOI.10.6028/NIST.FIPS.180-4}}. This process in pseudocode is: From 7d7a1caa00d61da3a76e2918bf401c96cf293b26 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 16 Oct 2020 10:36:48 +1100 Subject: [PATCH 2/2] hyphenate your bites Co-authored-by: Jana Iyengar --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 29f0cd90a5..0c2fa2cdf8 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -953,7 +953,7 @@ 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 from TLS -{{!TLS13}} to produce a 32 byte secret. Packets constructed by the server use +{{!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=DOI.10.6028/NIST.FIPS.180-4}}.