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
