From 47a4c2bfb1beb22eab393108354fe42870940cd9 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Thu, 5 Dec 2024 13:04:03 +0100 Subject: [PATCH 01/15] Merged ECH extensions into the main SSLKEYLOGFILE spec. --- draft-ietf-tls-keylogfile.md | 110 +++++++++++++++++++++++++++++++++-- 1 file changed, 105 insertions(+), 5 deletions(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index 4272bf5..d927504 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -28,6 +28,15 @@ author: fullname: Martin Thomson organization: Mozilla email: mt@lowentropy.net + - + fullname: Yaroslav Rosomakho + organization: Zscaler + email: yrosomakho@zscaler.com + - + fullname: Hannes Tschofenig + organization: University of Applied Sciences Bonn-Rhein-Sieg + abbrev: H-BRS + email: Hannes.Tschofenig@gmx.net normative: @@ -65,6 +74,10 @@ supports earlier TLS versions, though use of earlier versions is forbidden schedule. Use of this format could complement other protocol-specific logging such as QLOG {{?QLOG=I-D.ietf-quic-qlog-main-schema}}. +This document also specifies an extension to the SSLKEYLOGFILE format to support the +logging of information about Encrypted Client Hello (ECH) {{!ECH=I-D.ietf-tls-esni}} +related secrets. This enables debugging of ECH-enabled TLS and DTLS connections. + ## Applicability Statement @@ -138,8 +151,11 @@ logged secrets. ## Secret Labels for TLS 1.3 {#labels} An implementation of TLS 1.3 produces a number of values as part of the key -schedule (see {{Section 7.1 of !TLS13}}). Each of the following labels -correspond to the equivalent secret produced by the key schedule: +schedule (see {{Section 7.1 of !TLS13}}). If ECH was successfully negotiated for a +given connection, these labels MUST be followed by Random from Inner ClientHello. +Otherwise, Random from Outer ClientHello MUST be used. + +Each of the following labels correspond to the equivalent secret produced by the key schedule: CLIENT_EARLY_TRAFFIC_SECRET: @@ -203,6 +219,27 @@ additional information. An implementation of TLS 1.2 {{!TLS12}} (and also earlier versions) use the label "CLIENT_RANDOM" to identify the "master" secret for the connection. +## Secret Labels for ECH + +With the introduction of ECH {{!ECH}} additional secrets are derived +during the handshake to encrypt the Inner ClientHello message using Hybrid Public +Key Encryption (HPKE) {{?RFC9180}}. The client SHOULD log the ECH labels described below +if it offered ECH regardless of server acceptance. The server MAY log the labels only if it +successfully decrypted and accepted ECH offered by the client. The client MUST NOT log +the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!ECH}}). + +These labels MUST be always followed by Random from Outer ClientHello. + +ECH_SECRET: + +: This label corresponds to the KEM shared secret derived during the HPKE key schedule process. + Length of the secret is defined by the KEM negotiated for use with ECH. + +ECH_CONFIG: + +: This label is used to log the ECHConfig used for construction of the ECH extension. The + value is logged in hexadecimal representation, similarly to other entries in the SSLKEYLOGFILE. + # Security Considerations {#security} @@ -218,7 +255,8 @@ by any entity that is not otherwise authorized to observe or modify the content of connections for which secrets are logged could represent a privilege escalation attack. Implementations that enable logging also need to ensure that access to logged secrets is limited, using appropriate file permissions or -equivalent access control mechanisms. +equivalent access control mechanisms. To minimize the risk of accidental activation +in production, implementers SHOULD incorporate appropriate compile-time controls. In order to support decryption, the secrets necessary to remove record protection are logged. However, as the keys that can be derived from these @@ -261,9 +299,19 @@ that result in renegotiation, and forge Finished messages. Implementations can avoid the risks associated with these capabilities by not logging this secret value. +Access to the ECH_SECRET record in the SSLKEYLOGFILE allows the attacker to decrypt +the ECH extension and thereby reveal the content of the Inner ClientHello message, +including the payload of the Server Name Indication (SNI) extension. + +Access to the HPKE-established shared secret used in ECH introduces a potential +attack surface against the HPKE library since access to this keying material +is normally not available otherwise. + # IANA Considerations +## SSLKEYLOGFILE media type + The "`application/sslkeylogfile`" media type can be used to describe content in the SSLKEYLOGFILE format. IANA \[has added/is requested to add] the following information to the "Media Types" registry at @@ -340,6 +388,28 @@ Change controller: : IESG {: spacing="compact"} +## SSLKEYLOGFILE labels registry + +IANA is requested to create a new registry "SSLKEYLOGFILE Labels", within the +existing "Transport Layer Security (TLS) Parameters" registry page. +This new registry reserves labels used for SSLKEYLOGFILE entries. +The initial contents of this registry are as follows. + +| Value | Description | Reference | +| --- | --- | --- | +| CLIENT_RANDOM | Master secret in TLS 1.2 and earlier | This document | +| CLIENT_EARLY_TRAFFIC_SECRET | Secret for client early data records | This document | +| EARLY_EXPORTER_MASTER_SECRET | Early exporters secret | This document | +| CLIENT_HANDSHAKE_TRAFFIC_SECRET | Secret protecting client handshake | This document | +| SERVER_HANDSHAKE_TRAFFIC_SECRET | Secret protecting server handshake | This document | +| CLIENT_TRAFFIC_SECRET_0 | Secret protecting client records post handshake | This document | +| SERVER_TRAFFIC_SECRET_0 | Secret protecting server records post handshake | This document | +| EXPORTER_SECRET | Exporter secret after handshake | This document | +| ECH_SECRET | HPKE KEM shared secret used in the ECH | This document | +| ECH_CONFIG | ECHConfig used for construction of the ECH | This document | + +New assignments in the "SSLKEYLOGFILE Labels" registry will be administered by IANA through +IETF Review procedure {{!RFC8126}}. --- back @@ -397,10 +467,40 @@ CLIENT_RANDOM \ 9517e744e3117c3ce6c538a2d88dfdf ~~~ +The following shows a log entry for a TLS 1.3 connection that successfully +negotiated ECH. + +~~~ +# NOTE: '\' line wrapping per RFC 8792 + +ECH_SECRET \ + 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ + e8828ec09909cc9363179dc13b62498550c8637129345263011a1678370ca52a +ECH_CONFIG \ + 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ + fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d594\ + e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 +CLIENT_HANDSHAKE_TRAFFIC_SECRET \ + 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ + a195b63ec4270609692a204c08e63e74d9ae58e377d11a383bfe641a63c01140 +SERVER_HANDSHAKE_TRAFFIC_SECRET \ + 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ + 022d1cb827a90f27dadde0c99110c2b7d0f362fdfe420a04818aa223e5f2c14c +CLIENT_TRAFFIC_SECRET_0 \ + 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ + c2310f7db71109de88bab6f2f433fdc1704aecc0d57349cbf9113e5033178172 +SERVER_TRAFFIC_SECRET_0 \ + 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ + 04ffc7c154f71ba5f530c7344b0496f60ce71b9b7c6b0e203ea574bfcdf14e27 +EXPORTER_SECRET \ + 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ + befb5db5ac6785b5dd4c6a8c4693c379ec0a1486b5fd035b25e50c3c95abc500 +~~~ + # Acknowledgments {:numbered="false"} The SSLKEYLOGFILE format originated in the NSS project, but it has evolved over -time as TLS has changed. Many people contributed to this evolution. The author -is only documenting the format as it is used. +time as TLS has changed. Many people contributed to this evolution. The authors +are only documenting the format as it is used while extending it to cover ECH. From 543a132142f1ecdcbec72f1d560c95091d8b46a5 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:26:57 +0000 Subject: [PATCH 02/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index d927504..d4e5006 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -74,9 +74,8 @@ supports earlier TLS versions, though use of earlier versions is forbidden schedule. Use of this format could complement other protocol-specific logging such as QLOG {{?QLOG=I-D.ietf-quic-qlog-main-schema}}. -This document also specifies an extension to the SSLKEYLOGFILE format to support the -logging of information about Encrypted Client Hello (ECH) {{!ECH=I-D.ietf-tls-esni}} -related secrets. This enables debugging of ECH-enabled TLS and DTLS connections. +This document also defines labels that can be used to log information +about exchanges that use Encrypted Client Hello (ECH) {{!ECH=I-D.ietf-tls-esni}}. ## Applicability Statement From ec28ca7bfee658bc871790b561830a2a4b614ce0 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:27:30 +0000 Subject: [PATCH 03/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index d4e5006..9a89281 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -151,7 +151,7 @@ logged secrets. An implementation of TLS 1.3 produces a number of values as part of the key schedule (see {{Section 7.1 of !TLS13}}). If ECH was successfully negotiated for a -given connection, these labels MUST be followed by Random from Inner ClientHello. +given connection, these labels MUST be followed by the Random from the Inner ClientHello. Otherwise, Random from Outer ClientHello MUST be used. Each of the following labels correspond to the equivalent secret produced by the key schedule: From 551c39d871e0751c966d3689f710684c768078d0 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:27:42 +0000 Subject: [PATCH 04/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index 9a89281..08e50bc 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -152,7 +152,7 @@ logged secrets. An implementation of TLS 1.3 produces a number of values as part of the key schedule (see {{Section 7.1 of !TLS13}}). If ECH was successfully negotiated for a given connection, these labels MUST be followed by the Random from the Inner ClientHello. -Otherwise, Random from Outer ClientHello MUST be used. +Otherwise, the Random from the Outer ClientHello MUST be used. Each of the following labels correspond to the equivalent secret produced by the key schedule: From 71188e4465a3cf5d91e71b76b1423f929c2c2e88 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:27:51 +0000 Subject: [PATCH 05/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index 08e50bc..e7c4bb9 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -220,7 +220,7 @@ label "CLIENT_RANDOM" to identify the "master" secret for the connection. ## Secret Labels for ECH -With the introduction of ECH {{!ECH}} additional secrets are derived +With ECH {{!ECH}}, additional secrets are derived during the handshake to encrypt the Inner ClientHello message using Hybrid Public Key Encryption (HPKE) {{?RFC9180}}. The client SHOULD log the ECH labels described below if it offered ECH regardless of server acceptance. The server MAY log the labels only if it From 2969710c4983ce4b1c245577d570e5f4b17f2a41 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:28:00 +0000 Subject: [PATCH 06/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index e7c4bb9..b184b53 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -222,7 +222,7 @@ label "CLIENT_RANDOM" to identify the "master" secret for the connection. With ECH {{!ECH}}, additional secrets are derived during the handshake to encrypt the Inner ClientHello message using Hybrid Public -Key Encryption (HPKE) {{?RFC9180}}. The client SHOULD log the ECH labels described below +Key Encryption (HPKE) {{?RFC9180}}. A client can log the ECH labels described below if it offered ECH regardless of server acceptance. The server MAY log the labels only if it successfully decrypted and accepted ECH offered by the client. The client MUST NOT log the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!ECH}}). From cd8326fa25d53dd9f6bec829c44474a2a13c3e18 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:28:13 +0000 Subject: [PATCH 07/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index b184b53..ee9487b 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -223,7 +223,7 @@ label "CLIENT_RANDOM" to identify the "master" secret for the connection. With ECH {{!ECH}}, additional secrets are derived during the handshake to encrypt the Inner ClientHello message using Hybrid Public Key Encryption (HPKE) {{?RFC9180}}. A client can log the ECH labels described below -if it offered ECH regardless of server acceptance. The server MAY log the labels only if it +if it offered ECH regardless of server acceptance. The server can log the labels only if it successfully decrypted and accepted ECH offered by the client. The client MUST NOT log the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!ECH}}). From 59726a05403e87a1382ccaf7f70f9c531ae946aa Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:28:39 +0000 Subject: [PATCH 08/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index ee9487b..6972693 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -224,7 +224,8 @@ With ECH {{!ECH}}, additional secrets are derived during the handshake to encrypt the Inner ClientHello message using Hybrid Public Key Encryption (HPKE) {{?RFC9180}}. A client can log the ECH labels described below if it offered ECH regardless of server acceptance. The server can log the labels only if it -successfully decrypted and accepted ECH offered by the client. The client MUST NOT log +successfully decrypted the ECH offered by the client, though it could choose to do so +only when it accepts ECH. the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!ECH}}). These labels MUST be always followed by Random from Outer ClientHello. From b06594a40ce97e82365418592c81252522ab1078 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:30:40 +0000 Subject: [PATCH 09/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index 6972693..b618455 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -228,7 +228,7 @@ successfully decrypted the ECH offered by the client, though it could choose to only when it accepts ECH. the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!ECH}}). -These labels MUST be always followed by Random from Outer ClientHello. +These labels MUST be always use the Random from the Outer ClientHello. ECH_SECRET: From 5dcc9450659c5a21a74cdde7db1e4d446da37694 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:30:59 +0000 Subject: [PATCH 10/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index b618455..294b6ae 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -232,7 +232,7 @@ These labels MUST be always use the Random from the Outer ClientHello. ECH_SECRET: -: This label corresponds to the KEM shared secret derived during the HPKE key schedule process. +: This label corresponds to the KEM shared secret used by HPKE (`shared_secret` in the algorithms in {{Section 5.1.1 of !HPKE=RFC9180}}. Length of the secret is defined by the KEM negotiated for use with ECH. ECH_CONFIG: From 69ddef1154fab664c9ba8123c8b78003c269f6ea Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:31:20 +0000 Subject: [PATCH 11/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index 294b6ae..e85a071 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -237,8 +237,8 @@ ECH_SECRET: ECH_CONFIG: -: This label is used to log the ECHConfig used for construction of the ECH extension. The - value is logged in hexadecimal representation, similarly to other entries in the SSLKEYLOGFILE. +: The ECHConfig used to construct the ECH extension. The value is logged + in hexadecimal representation. # Security Considerations {#security} From 889278b40d42249917a903c840c490950f2fd3f1 Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:33:06 +0000 Subject: [PATCH 12/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index e85a071..b2fbe29 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -255,8 +255,7 @@ by any entity that is not otherwise authorized to observe or modify the content of connections for which secrets are logged could represent a privilege escalation attack. Implementations that enable logging also need to ensure that access to logged secrets is limited, using appropriate file permissions or -equivalent access control mechanisms. To minimize the risk of accidental activation -in production, implementers SHOULD incorporate appropriate compile-time controls. +equivalent access control mechanisms. In order to support decryption, the secrets necessary to remove record protection are logged. However, as the keys that can be derived from these From b69fe526d2a0a01359b1c3f680e74efaa4a90ddd Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Fri, 6 Dec 2024 17:40:13 +0000 Subject: [PATCH 13/15] Update draft-ietf-tls-keylogfile.md --- draft-ietf-tls-keylogfile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index b2fbe29..b14752c 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -228,7 +228,7 @@ successfully decrypted the ECH offered by the client, though it could choose to only when it accepts ECH. the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!ECH}}). -These labels MUST be always use the Random from the Outer ClientHello. +These labels MUST always use the Random from the Outer ClientHello. ECH_SECRET: From e98c452073126bf8057d6d1ca3f4fb76f509fbfc Mon Sep 17 00:00:00 2001 From: Yaroslav Rosomakho Date: Tue, 10 Dec 2024 06:11:47 -0800 Subject: [PATCH 14/15] Update draft-ietf-tls-keylogfile.md Co-authored-by: Martin Thomson --- draft-ietf-tls-keylogfile.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index b14752c..8a3fc12 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -226,7 +226,6 @@ Key Encryption (HPKE) {{?RFC9180}}. A client can log the ECH labels described be if it offered ECH regardless of server acceptance. The server can log the labels only if it successfully decrypted the ECH offered by the client, though it could choose to do so only when it accepts ECH. -the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!ECH}}). These labels MUST always use the Random from the Outer ClientHello. From cdff69c4c5444bc5390a8461af6676ca0aad6a20 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 12 Dec 2024 08:20:51 +1100 Subject: [PATCH 15/15] Close paren, wrap --- draft-ietf-tls-keylogfile.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md index 8a3fc12..fe35a4a 100644 --- a/draft-ietf-tls-keylogfile.md +++ b/draft-ietf-tls-keylogfile.md @@ -231,7 +231,8 @@ These labels MUST always use the Random from the Outer ClientHello. ECH_SECRET: -: This label corresponds to the KEM shared secret used by HPKE (`shared_secret` in the algorithms in {{Section 5.1.1 of !HPKE=RFC9180}}. +: This label corresponds to the KEM shared secret used by HPKE + (`shared_secret` in the algorithms in {{Section 5.1.1 of !HPKE=RFC9180}}). Length of the secret is defined by the KEM negotiated for use with ECH. ECH_CONFIG: