> as a developer you rely on ways to decrypt traffic for debugging purposes. As a developer, I use a variety of tools for debugging purposes; in most cases, I find that I have no need to export keys and decrypt TLS ciphertext to diagnose issues.
> The draft does not define a new mechanism but instead relies on and extends > an already existing TLS working group item, see... Yes, I opposed that one also. > It is a tool for a developer and must be enabled by the developer on one of > the involved end points to work. Correct, and this tool may have its uses. I believe the drawbacks of standardizing this tool at the IETF outweigh the benefits. Cheers, Andrei -----Original Message----- From: [email protected] <[email protected]> Sent: Saturday, August 3, 2024 9:36 AM To: Andrei Popov <[email protected]>; 'Sean Turner' <[email protected]>; 'TLS List' <[email protected]> Subject: RE: [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi Andrei, as a developer you rely on ways to decrypt traffic for debugging purposes. The draft does not define a new mechanism but instead relies on and extends an already existing TLS working group item, see https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ Hence, this is not a mechanism that allows a third party in the middle of the network communication to somehow decrypt traffic. It is a tool for a developer and must be enabled by the developer on one of the involved end points to work. Publishing the draft as informational, much like draft-ietf-tls-keylogfile is, sounds good to me though. Ciao Hannes -----Original Message----- From: Andrei Popov <[email protected]> Sent: Donnerstag, 25. Juli 2024 18:30 To: Sean Turner <[email protected]>; TLS List <[email protected]> Subject: [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH I do not support adoption, because I believe the IETF should not standardize tools and techniques for decrypting TLS-protected data. It is harder for a TLS implementer to reject requests for IETF-blessed functionality. (As long as this remains on the Informational track, I believe it's somewhat less harmful.) Cheers, Andrei -----Original Message----- From: Sean Turner <[email protected]> Sent: Thursday, July 25, 2024 9:16 AM To: TLS List <[email protected]> Subject: [EXTERNAL] [TLS]Adoption call for SSLKEYLOG Extension file for ECH At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG Extension file for ECH I-D (https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/). This message starts a two-weekl call for adoption. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this I-D, please send a message to the list and indicate why. This call will close on 8 August 2024. Thanks, Sean _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
