Subject: [quicwg/base-drafts] TLS-31: Usage of HKDF is vague (#4197)

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Oct 2020 05:27:20 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4197

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Oct 2020 05:36:07 -0700

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 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. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4197#issuecomment-707708747

---

From: Lars Eggert <[email-masked]>
Date: Thu, 15 Oct 2020 04:17:58 -0700

Based on #4201, labeling this as "editorial"

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4197#issuecomment-709210943

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 05:12:15 -0700

Changes looks good, resolve the issue. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4197#issuecomment-709260520

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Oct 2020 16:37:27 -0700

Closed #4197 via #4201.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4197#event-3883971593