The SSLKEYLOGFILE Format for TLS
draft-ietf-tls-keylogfile-05

While I'm normally not a fan of storing keys in log files, if the use is restricted to test systems, and there is tight access control to access the files, it can provide a valuable diagnostic tool.  I certainly like it MUCH better than using NULL encryption.

Thanks for the work to document this widely used de facto standard. My only comments are minor, and mostly nits.

In Section 2, "Including this field allows..." sounds like an argument for including it, but it's not an optional field. Consider a more declarative phrasing, such as "This field is used to correlate..."

===NITS FOLLOW===

Abstract, "supports the logging information" => "supports logging information" or "supports the logging of information"
Section 2.2, "An implementation ... use" => "An implementation ... uses" or "Implementations ... use"
Section 4.2, "in depth" => "in-depth"

Hi Martin, Yaroslav, and Hannes, 

Thanks for the effort put into this specification to document SSLKEYLOGFILE format. The document is well-written with a clear applicability scope. The format is useful and should be used with special care, obviously.

Special thanks to S. Turner for the comprehensive write-up.

Thanks to Jean-Michel Combes for the OPSDIR review (his first review of the team, btw). Although Jean-Michel indicated that the document is Ready, his review includes two aspects for which I hoped a follow-up from the authors:

1.	Position this work vs the use of NULL encryption
2.	Implications on operations to prevent misuses

In reference to the first point, I’d like to remind that BCP 195 includes the following:

      Nevertheless, this
      document does not discourage software from implementing NULL
      cipher suites, since they can be useful for testing and debugging.

There are cases where the use of SSLKEYLOGFILE may be superior than use of NULL encryption or fallback to non-TLS. I understand that we are not making any recommendation about the use of SSLKEYLOGFILE, but it would be helpful to call out how it is different vs. the other choices.

Please find below some additional few comments:

# Insist on the intended use in the abstract as well

OLD:
   A format that supports the logging information about the secrets used
   in a TLS connection is described.

NEW:
   A format that supports the logging information about the secrets used
   in a TLS connection is described.  This format is intended for use in
   systems where TLS only protects test data.  

# Other misuse guards 

CURRENT:
   For software that is compiled, use
   of conditional compilation is the best way to ensure that deployed
   binaries cannot be configured to enable key logging.

Can we mention other guards such as those mentioned in the OPSDIR review (e.g., right managements)?

# Add RFC8792 to the references list as this is required to unfold the examples.

Cheers,
Med

Thank you to Russ Housley for the GENART review.