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 would extend that format to allow also
decrypting the ECH information. This of course has security and
privacy implications, but presumably fewer than the connection as a
whole, especially as the SSLKEYLOGFILE information is sufficient to
decrypt the server's certificate.
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 - completely undermines the core
guarantees that TLS provides. This format is intended for use in
systems where TLS only protects test data. While the access that
this information provides to TLS connections can be useful for
diagnosing problems while developing systems, this mechanism MUST
NOT be used in a production system.
If people feel that this statement is not strong enough, then I think
the right thing to do is adjust the original draft, potentially by
proposing new text here or to the IESG.
-Ekr
[0] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
[1]
https://www.ietf.org/archive/id/draft-ietf-tls-keylogfile-02.html#name-applicability-statement
On Sat, Aug 3, 2024 at 10:35 AM Tim Bray <tb...@textuality.com> wrote:
> 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 a
>> developer and must be enabled by the developer on one of the involved end
>> points to work.
>>
>
> If this is correct (some previous emails made me think it might not be) I
> think it would be a good idea for a strong consensus statement to this
> effect to appear in the WG product. Because if it is perceived that the
> IETF is providing and blessing MITM mechanisms, that will be… um,
> controversial.
>
> PS: I wonder what “in the middle of the network means”, exactly.
>
> _______________________________________________
> 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
