Countries like Iran would probably love if this went through. This seems like a very dangerous feature that’ll make data collection significantly easier for rogue states.
On Fri, Aug 2, 2024 at 20:10 Christian Huitema <huit...@huitema.net> wrote: > I agree with Andrei. SSLKEYLOG is an extremely dangerous feature. > I think the draft should only be adopted if it clearly state that the > feature MUST NOT be deployed in production software. > > Using an environment variable may be a fine way to specify on which file > copies of keys have to be written, but it is a terrible way to specify > whether these keys should be. Environment variables can be installed by > scripts, etc., and I can think of many ways of doing that without user > awareness. > > I think that this functionality should be only compiled into builds that > are specifically designated as "debug only", and that it should be > turned on explicitly by some kind of user interaction. But really, I > support Andrei's statement that there are many less intrusive ways to do > debugging, such as using QLOG files in the case of QUIC. Enabling key > export is a kind of nuclear option, and it should be hard to use, by > design. > > -- Christian Huitema > > > On 7/25/2024 11:01 AM, Andrei Popov wrote: > > * 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/ < > 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 > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
