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

[Andrei Popov <[e-mail]>]

> as a developer you rely on ways to decrypt traffic for debugging purposes.
As a developer, I use a variety of tools for debugging purposes; in most cases, I find that I have no need to export keys and decrypt TLS ciphertext to diagnose issues.

> The draft does not define a new mechanism but instead relies on and extends an already existing TLS working group item, see...
Yes, I opposed that one also.

> It is a tool for a developer and must be enabled by the developer on one of the involved end points to work.
Correct, and this tool may have its uses. I believe the drawbacks of standardizing this tool at the IETF outweigh the benefits.

Cheers,

Andrei

-----Original Message-----
From: hannes.tschofenig=[e-mail] <hannes.tschofenig=[e-mail]>
Sent: Saturday, August 3, 2024 9:36 AM
To: Andrei Popov <[e-mail]>; 'Sean Turner' <[e-mail]>; 'TLS List' <[e-mail]>
Subject: RE: [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[You don't often get email from hannes.tschofenig=[e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Andrei,

as a developer you rely on ways to decrypt traffic for debugging purposes. The draft does not define a new mechanism but instead relies on and extends an already existing TLS working group item, see https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
Hence, this is not a mechanism that allows a third party in the middle of the network communication to somehow decrypt traffic. It is a tool for a developer and must be enabled by the developer on one of the involved end points to work.

Publishing the draft as informational, much like draft-ietf-tls-keylogfile is, sounds good to me though.

Ciao
Hannes

-----Original Message-----
From: Andrei Popov <Andrei.Popov=[e-mail]>
Sent: Donnerstag, 25. Juli 2024 18:30
To: Sean Turner <[e-mail]>; TLS List <[e-mail]>
Subject: [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

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]>
Sent: Thursday, July 25, 2024 9:16 AM
To: TLS List <[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/) 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]
To unsubscribe send an email to [e-mail]

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]