[TLS]Re: [⚠] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Amir Omidi <[e-mail]>]

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 <[e-mail]> 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=[e-mail]>
> > *Sent:* Thursday, July 25, 2024 10:12 AM
> > *To:* Andrei Popov <[e-mail]>
> > *Cc:* TLS List <[e-mail]>
> > *Subject:* Re: [⚠️] [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG
> > Extension file for ECH
> >
> >
> >
> > You don't often get email from yrosomakho=[e-mail]
> > <mailto:yrosomakho=[e-mail]>. 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=[e-mail]
> > <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
> >     Sent: Thursday, July 25, 2024 9:16 AM
> >     To: TLS List <[e-mail] <mailto:[e-mail]>>
> >     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 -- [e-mail] <mailto:[e-mail]>
> >     To unsubscribe send an email to [e-mail]
> >     <mailto:[e-mail]>
> >
> >     _______________________________________________
> >     TLS mailing list -- [e-mail] <mailto:[e-mail]>
> >     To unsubscribe send an email to [e-mail]
> >     <mailto:[e-mail]>
> >
> >
> > _______________________________________________
> > TLS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>