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

[Christian Huitema <[e-mail]>]

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]