Re: [TLS] sslkeylogfile
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
Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-01.txt
Hi, I think this is great work and something the TLS WG should adopt and work on. Reducing the total number of bytes is very important not only in constrained IoT, but also in TLS based EAP methods, and in applications where handshake time to completion is important. I quicky read the -02 draft. It seems to be in a good shape. Some comments: - I think it would be good if the draft described how it works with draft-ietf-tls-subcerts. While the latest version of draft-ietf-tls-subcerts talks about “delegated credential” and not certifcates, they are commonly refered to as subcerts. - I think draft-kampanakis-tls-scas-latest could considered allowing suppressing also the end-entity certificate for use cases when draft-ietf-tls-subcerts is used. Cheers, John From: TLS on behalf of Kampanakis, Panos Date: Friday, 4 March 2022 at 16:42 To: tls@ietf.org Cc: Bytheway, Cameron Subject: Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-01.txt Hi all, The updated -01 version fixes a couple of nits identified by Ilari, removes the needs for two different tlsflags, one each direction, and does not require an acknowledgement of the ICA suppression tlsflag based on discussions about the tlsflags draft https://mailarchive.ietf.org/arch/msg/tls/SIvCO_ZFmNfTEeyiuZOcdBzTdAo/ There are more issues we are tracking based on discussions in this list https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-24c7ac234ac8e19f&q=1&e=76ac0dba-b0c6-4ac8-9538-5faabd060cb2&u=https%3A%2F%2Fgithub.com%2Fcsosto-pk%2Ftls-suppress-intermediates%2Fissues -Original Message- From: internet-dra...@ietf.org Sent: Friday, March 4, 2022 10:34 AM To: Bas Westerbaan ; Bytheway, Cameron ; Martin Thomson ; Kampanakis, Panos Subject: [EXTERNAL] New Version Notification for draft-kampanakis-tls-scas-latest-01.txt CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. A new version of I-D, draft-kampanakis-tls-scas-latest-01.txt has been successfully submitted by Panos Kampanakis and posted to the IETF repository. Name: draft-kampanakis-tls-scas-latest Revision: 01 Title: Suppressing CA Certificates in TLS 1.3 Document date: 2022-03-04 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-01.txt Status: https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/ Htmlized: https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest Diff: https://www.ietf.org/rfcdiff?url2=draft-kampanakis-tls-scas-latest-01 Abstract: A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sslkeylogfile
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. Cheers, John From: TLS on behalf of Martin Thomson Date: Wednesday, 26 October 2022 at 02:18 To: Peter Gutmann , 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
