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 _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
