* The ultimate goal is to simplify adoption of ECH for both developers of TLS software and implementers Understood; I do not question the goals of the authors.
* Without a standard approach to troubleshooting every developer has to build an individual set of bespoke troubleshooting tools. The troubleshooting approach used in this I-D is more invasive than it needs to be. Troubleshooting can be accomplished in a number of ways, including logs/traces that do not disclose all TLS-protected data. * We tried to keep wording in line with the keylogfile draft - for instance in the applicability statement it is worded that "this mechanism MUST NOT be used in a production system". That’s nice, but in practice this does not prevent abuse of the feature. I would rather SSLKEYLOGFILE was documented by the SW vendors who choose to implement it, in a repository outside of the IETF. I understand I’m in the rough on this. Cheers, Andrei From: Yaroslav Rosomakho <yrosomakho=40zscaler....@dmarc.ietf.org> Sent: Thursday, July 25, 2024 10:12 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: TLS List <tls@ietf.org> Subject: Re: [⚠️] [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH You don't often get email from yrosomakho=40zscaler....@dmarc.ietf.org<mailto:yrosomakho=40zscaler....@dmarc.ietf.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Thank you for the feedback, Andrei. Yes, it is intended to stay on the informational track as an extension to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the keylogfile draft - for instance in the applicability statement it is worded that "this mechanism MUST NOT be used in a production system". Happy to add stronger wording if that helps. The ultimate goal is to simplify adoption of ECH for both developers of TLS software and implementers. Without a standard approach to troubleshooting every developer has to build an individual set of bespoke troubleshooting tools. Ability to inspect ECH negotiation in off the shelf tools such as Wireshark during development or tests would significantly help adoption. Best Regards, Yaroslav On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>> wrote: 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 <s...@sn3rd.com<mailto:s...@sn3rd.com>> Sent: Thursday, July 25, 2024 9:16 AM To: TLS List <tls@ietf.org<mailto:tls@ietf.org>> 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 -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
