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

[Christian Huitema <[e-mail]>]

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 - 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.

The security considerations of 
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ are pretty 
clear, but the discussion pointed out that environment variables can be 
installed without knowledge of most users. More protection is needed. 
Examples are explicit run time options, such as asking the user to set a 
special configuration flag to enable the feature, and compile time 
protections, which would only enable that configuration flag in special 
versions of the application.

I think what the keylogfile draft is missing is some kind of scenario 
description. I have seen this feature widely used in "development" 
builds -- the QUIC Interop Runner (https://interop.seemann.io/) depends 
on it. In that case the scenario is simple, and a compile time solution 
works fine.

I understand that this feature could be useful when debugging network 
problems, and that the most used solution today is to collect and then 
analyze packet captures. That workflow is less simple, because the 
problem is typically discovered "in production". That's were the tension 
arises. On one hand, running that feature in production is pure folly. 
On the other hand, explaining to the user how to turn on the SSLKEYLOG 
feature and collect a PCAP can be a bit challenging. There will be a 
push to interpret the MUST NOT as "MUST NOT but we know very well that 
you will".

There are plausible defenses about this, such as tweaking the UI to make 
very obvious that the application is running in a degraded mode, with no 
security. But these defenses have cost, both in terms of implementation 
and in terms of reputation. The IETF can probably help developers "do 
the right thing" ... and defend their choices!

If it is not too late, it would be nice to explain that in a "deployment 
considerations" of draft-ietf-tls-keylogfile.

As for exporting the ECH key, there is a much simpler solution. If the 
problem is "get a PCAP for debugging", just turning of ECH for the 
debugging session would suffice. And it would also make the trade-off 
between debugging and safety pretty obvious.

-- Christian Huitema