From 9a378ded96957fbe62155a94735e74f843fe0c0f Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Mon, 2 Dec 2024 10:32:58 -0500 Subject: [PATCH] Clarify that DTLS uses the DTLS HKDF-Expand-Label We've made a mess of things and now every extension that cites HKDF-Expand-Label needs to clarify this. This seems like a mistake. Worse, if a future TLS 1.4 change the "tls13" prefix to "tls14", every extension will now become ambiguous! I've left that alone in this document, but we may need to contend with this later. In hindsight, we should have excluded the implicit "tls13 " prefix from the HKDF-Expand-Label function. Instead, the version-dependent labels could have been incorporated into individual labels as needed. (In particular, I don't think this label actually needed to be version-dependent.) Instead we seem to have implicitly decided that HKDF-Expand-Label is part of the "interface" that TLS exposes to its extensions, without remembering to say so clearly. Anyway, this PR does the minimal thing to paper over this mess. --- draft-ietf-tls-esni.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index 0058c984..2e32ab8d 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -1184,7 +1184,8 @@ ServerHello.random with the following string: where HKDF-Expand-Label is defined in {{RFC8446, Section 7.1}}, "0" indicates a string of Hash.length bytes set to zero, and Hash is the hash function used to -compute the transcript hash. +compute the transcript hash. In DTLS, the modified version of HKDF-Expand-Label +defined in {{RFC9147, Section 5.9}} is used instead. The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or below. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see