>This file doesn't have any extra information than what would be in a >serialised >session data used for session resumption. Something plenty of software >already >does.
I hope that is TLS 1.2 only. A TLS 1.3 implementation should not save any other keys than resumption_master_secret or PSKs derived from resumption_master_secret. If that is not clear in RFC 8446, I think that need to be made clear in RFC8446bis. John From: Hubert Kario <hka...@redhat.com> Date: Wednesday, 21 December 2022 at 17:03 To: John Mattsson <john.matts...@ericsson.com> Cc: Martin Thomson <m...@lowentropy.net>, Peter Gutmann <pgut...@cs.auckland.ac.nz>, tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] sslkeylogfile On Thursday, 24 November 2022 11:37:02 CET, 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. This file doesn't have any extra information than what would be in a serialised session data used for session resumption. Something plenty of software already does. > Cheers, > John > > From: TLS <tls-boun...@ietf.org> on behalf of Martin Thomson > <m...@lowentropy.net> > Date: Wednesday, 26 October 2022 at 02:18 > To: Peter Gutmann <pgut...@cs.auckland.ac.nz>, tls@ietf.org <tls@ietf.org> > Subject: Re: [TLS] sslkeylogfile > > On Tue, Oct 25, 2022, at 16:48, Peter Gutmann wrote: >> But it's not the same thing, it only seems to cover some TLS >> 1.3 extensions. >> Thus my suggestion to call it "Extensions to the SSLKEYLOGFILE >> Format for TLS >> 1.3". > > That's not the intent. Section 3.2 covers all you need for TLS 1.2. > > I did not describe the (deprecated) "RSA" key, is that in > common usage? Or, are there things that I have missed? I got > everything from > https://firefox-source-docs.mozilla.org/security/nss/legacy/key_log_format/index.html > but maybe that is no longer the best reference. > -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com<http://www.cz.redhat.com> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
