On 8/3/2024 11:03 AM, Eric Rescorla wrote:
...
The main SSLKEYLOGFILE document already contains the following
applicability statement [1], which also is referenced here in S 5:
The artifact that this document describes - if made available to
entities other than endpoints - complet
Hiya,
On 03/08/2024 19:03, Eric Rescorla wrote:
I'd like to make sure we're all on the same page about this draft.
The IESG has already approved the original TLS document on
SSLKEYLOGFILE [0], which contains the keying material necessary to
decrypt the connection. It's currently in the RFC Edit
* IMO the best place to start would be to try to build some consensus on
which problems we want to solve (including whether existing approaches are
sufficient) rather than on the details of specific proposals.
I strongly agree with this.
Cheers,
Andrei
From: Eric Rescorla
Sent: Saturday,
> 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 in
Hi folks,
I'd like to make sure we're all on the same page about this draft.
The IESG has already approved the original TLS document on
SSLKEYLOGFILE [0], which contains the keying material necessary to
decrypt the connection. It's currently in the RFC Editor Queue.
The draft under discussion wou
I’m not a TLS insider but I’ve been watching this discussion, and…
On Aug 3, 2024 at 9:36:16 AM, hannes.tschofenig=40gmx@dmarc.ietf.org
wrote:
> 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
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 mech
I agree that an interim focused on this topic would be a good idea.
IMO the best place to start would be to try to build some consensus on
which problems we want to solve (including whether existing approaches are
sufficient) rather than on the details of specific proposals. Once we've
done that,
> I think the draft should only be adopted if it clearly state that the
> feature MUST NOT be deployed in production software.
Of course, the draft can be adopted and then the WG can make that change.
> I think that this functionality should be only compiled into builds that
> are specifically
