Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-keylogfile-04: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
