Update draft-rosomakho-tls-ech-keylogfile.md

draft-rosomakho-tls-ech-keylogfile.md

@@ -35,23 +35,21 @@ informative:
 
 --- abstract
 
-This document specifies an extension to the SSLKEYLOGFILE format {{!I-D.ietf-tls-keylogfile}} to support the logging information about Encrypted Client Hello (ECH) {{!I-D.ietf-tls-esni}} related secrets. Specifically, it introduces two new labels: ECH_SECRET and ECH_CONFIG, which respectively log the HPKE {{?RFC9180}} shared secret and the ECHConfig used for the ECH. This extension aims to facilitate debugging and analysis of TLS connections employing ECH.
+This document specifies an extension to the SSLKEYLOGFILE format  to support the logging information about Encrypted Client Hello (ECH) related secrets. Specifically, it introduces two new labels: ECH_SECRET and ECH_CONFIG, which respectively log the HPKE {{?RFC9180}} shared secret and the ECHConfig used for the ECH. This extension aims to facilitate debugging and analysis of TLS connections employing ECH.
 
 
 --- middle
 
 # Introduction
 
-The SSLKEYLOGFILE format, used for information about the secrets used in a TLS connection, is instrumental in debugging and analyzing TLS traffic. With the introduction of Encrypted Client Hello (ECH), additional secret is used during the handshake process. This document extends the SSLKEYLOGFILE format to include relevant information to decrypt ECH extension, enabling comprehensive analysis of ECH-enabled connections. This document also clarifies logging of TLS 1.3 secrets if ECH was successfully negotiated.
-
-Proposed extensions can also be used with all protocols that support ECH including TLS 1.3 {{?RFC8446}}, DTLS 1.3 {{?RFC9147}} and QUIC {{?RFC9000}}{{?RFC9001}}.
+Debugging protocols with TLS can be difficult due to encrypted communications. Analyzing these messages in diagnostic and debug tools requires inspecting the encrypted content. Various TLS implementations have informally adopted a file format to log the secret values generated by the TLS key schedule, aiding in this analysis.
 
+In many implementations, the file that the secrets are logged to is specified in an environment variable named
+"SSLKEYLOGFILE". {{!I-D.ietf-tls-keylogfile}} standardizes this format.  With the introduction of {{!I-D.ietf-tls-esni}} additional secrets are derived during the handshake to encrypt the ClientHello message. This document extends the SSLKEYLOGFILE format to also offer support for the ECH extension to enable debugging aof ECH-enabled connections. The proposed extension can also be used with all protocols that support ECH, including TLS 1.3 {{?RFC8446}}, DTLS 1.3 {{?RFC9147}} and QUIC {{?RFC9000}}{{?RFC9001}}.
 
 # Conventions and Definitions
-
 {::boilerplate bcp14-tagged}
 
-
 # SSLKEYLOGFILE Labels for ECH
 
 This document defines two new labels for SSLKEYLOGFILE format: ECH_SECRET and ECH_CONFIG. Client SHOULD log those labels if it offered ECH regardless of server acceptance. Server can log those labels only if it decrypted and accepted ECH from the client. The 32-byte Random from the Outer ClientHello message is used as client_random for these log records. Client MUST NOT log those labels for connections that use GREASE ECH extension.
@@ -76,11 +74,12 @@ SSLKEYLOGFILE entries corresponding to TLS 1.3 secrets for connections that succ
 
 # Security Considerations
 
+The applicability statement of {{!I-D.ietf-tls-keylogfile}} also applies to this document: if unauthorized   entities gain access to the logged secrets then the core guarantees that TLS provides are completely undermined. This extension is intended for use in systems where TLS only protects test data. 
+
 Access to ECH_SECRET record in SSLKEYLOGFILE allows attacker to decrypt ECH extension and defeat privacy benefits offered by the ECH. Security considerations described in SSLKEYLOGFILE are fully applicable to this extension.
 
 Ability to log KEM shared secret from HPKE key schedule introduces potential attack surface against HPKE process. Implementers need to secure relevant APIs accordingly to ensure that no unauthorised party can extract the KEM shared secret.
 
-
 # IANA Considerations
 
 This document has no IANA actions.