From 4c63d3ea6098c184a58de99e243eaa75e921d4ea Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Thu, 4 Jul 2024 20:15:31 +0200 Subject: [PATCH 1/2] Update draft-rosomakho-tls-ech-keylogfile.md --- draft-rosomakho-tls-ech-keylogfile.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-rosomakho-tls-ech-keylogfile.md b/draft-rosomakho-tls-ech-keylogfile.md index cc2b26a..3ef041e 100644 --- a/draft-rosomakho-tls-ech-keylogfile.md +++ b/draft-rosomakho-tls-ech-keylogfile.md @@ -27,6 +27,10 @@ author: fullname: Yaroslav Rosomakho organization: Zscaler email: yrosomakho@zscaler.com + - + name: Hannes Tschofenig + organization: University of Applied Sciences Bonn-Rhein-Sieg + email: Hannes.Tschofenig@gmx.net normative: @@ -55,17 +59,14 @@ In many implementations, the file that the secrets are logged to is specified in This document defines two new labels for SSLKEYLOGFILE format: ECH_SECRET and ECH_CONFIG. The client SHOULD log the labels 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 32-byte random value from the Outer ClientHello message is used as the client_random value for these log records. The client MUST NOT log the labels for connections that use the GREASE ECH extension (see Section 6.2 of {{!I-D.ietf-tls-esni}}). - ## 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. Note that the value is logged in hexadecimal representation, similarly to other entries in the SSLKEYLOGFILE. - # Client_random for other TLS 1.3 SSLKEYLOGFILE Entries The SSLKEYLOGFILE uses the random value from the ClientHello message as a "connection identifier". This creates ambiguity since the TLS handshake with ECH contains two different random values, one in the Outer ClientHello structure and the second one in the Inner ClientHello. @@ -80,7 +81,7 @@ This specification extends the SSLKEYLOGFILE specification {{!I-D.ietf-tls-keylo - Access to the ECH_SECRET record in the SSLKEYLOGFILE allows the attacker to decrypt the ECH extension and thereby reveal the content of the ClientHello message, including the payload of the Server Name Indication (SNI) extension. -- Access to the HPKE-established shared secret introduces potential attack surface against the HPKE process. +- Access to the HPKE-established shared secret introduces a potential attack surface against the HPKE library since access to this keying material is not ncessarily available otherwise. Implementers MUST take measures to prevent unauthorized access to the SSLKEYLOGFILE text file. From 86f8ebef699bb6f5281f4b73b43d490fc92ef357 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Thu, 4 Jul 2024 20:18:22 +0200 Subject: [PATCH 2/2] Update draft-rosomakho-tls-ech-keylogfile.md --- draft-rosomakho-tls-ech-keylogfile.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-rosomakho-tls-ech-keylogfile.md b/draft-rosomakho-tls-ech-keylogfile.md index 3ef041e..b886cd5 100644 --- a/draft-rosomakho-tls-ech-keylogfile.md +++ b/draft-rosomakho-tls-ech-keylogfile.md @@ -91,10 +91,9 @@ This extension is intended for use in systems where TLS only protects test data. This document has no IANA actions. - --- back # Acknowledgments {:numbered="false"} -TODO acknowledge. +We would like to thank Stephen Farrell and Martin Thomson for their review comments.