Thanks Martin, That seems much better. That is sufficient to me.
John From: Martin Thomson <m...@lowentropy.net> Date: Friday, 25 November 2022 at 08:21 To: John Mattsson <john.matts...@ericsson.com>, Peter Gutmann <pgut...@cs.auckland.ac.nz>, tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] sslkeylogfile Thanks for the input John, I agree on both points, the minor one and the substantive one. https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a9cf421cb99ab6e7&q=1&e=0ee2a1ca-4130-4e5f-8a35-f027f40b7759&u=https%3A%2F%2Fgithub.com%2Fmartinthomson%2Fsslkeylogfile%2Fpull%2F1 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
