On Fri, Jul 26, 2024 at 3:25 AM Bob Beck <bbe=40google....@dmarc.ietf.org> wrote:
> > > On Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho <yrosomakho= > 40zscaler....@dmarc.ietf.org> wrote: > >> 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. >> > > No matter what your opinion on standardizing SSLKEYLOGFILE, > https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ does not > contain this MUST NOT guidance as in this draft. > > This guidance does appear to be included in the base draft under "1.1 Applicability Statement". > MUST NOT guidance for only this portion of SSLKEYLOGFILE functionality > that is not present for the rest of specification calls into question how > an application developer shipping SSLKEYLOGFILE functionality in an > application is supposed to follow this guidance. Is only this portion of > the functionality supposed to be removed in "production" > > It seems to me like if this is what the IETF wants to advise, This advice > is being given in the wrong draft. > > -Bob > > >> >> 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> 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> >>> Sent: Thursday, July 25, 2024 9:16 AM >>> To: TLS List <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 >>> 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 >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- Steven Valdez | Chrome Privacy Sandbox | sval...@google.com | Cambridge, MA
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
