Thanks for the input John, I agree on both points, the minor one and the substantive one.
https://github.com/martinthomson/sslkeylogfile/pull/1 is my attempt to put something stronger about usage/applicability up front. Do you think that is sufficient? On Thu, Nov 24, 2022, at 21:37, John Mattsson wrote: > Hi, > > Two high level comments: > > > - OLD: "though use of earlier versions is strongly discouraged [RFC8996]" > > That is not what RFC 8996 says. RFC 8996 says > > - "TLS 1.1 MUST NOT be used." > - "TLS 1.1 MUST NOT be used." > > Please change to something that aligns with RFC 8996 such as > > NEW: "though use of earlier versions is forbidden [RFC8996]" > > > - "Access to the content of a file in SSLKEYLOGFILE allows an attacker > to break the confidentiality protection on any TLS connections that > are included in the file." > > This is true but does not at all reflect the implications of the > existence of a file for long-term storage of keys like this. Storing > any of the keying material like this completely breaks the stated > forward secrecy property of TLS 1.3 as it creates new long-term keys. > It does not matter how well the file is protected i.e., > > "Ensuring adequate access control on these files therefore becomes > very important." > > is not enough. The theoretical security properties are still broken > badly. I think this draft is problematic, but I can understand the need > to standardize this existing format. I think the fact that > SSLKEYLOGFILE breaks the security properties of TLS 1.3 needs to very > clearly described. As a consequence, I think the only allowed use case > standardized by TLS WG should be limited to non-production debugging. > If governments and companies wanting visibility do other things, that > would be outside of IETFs control. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
