Hiya,
On 17/05/2023 18:49, John Mattsson wrote:
Hi, Should IETF / SEC / TLS send an LS to NIST as was done with ESTI-TC-CYBER?
Yes. Other relevant bodies defining ways to weaken the hard-won security of IETF protocols really ought always be (nicely) told they're doing a bad thing. I sent NIST my own comments (also with an attempt at "nicely":-) and would encourage others to do similarly, even though it's not that likely they'll take much notice I suspect (on the basis that they even started this IMO bad-idea-factory activity). Cheers, S.
https://datatracker.ietf.org/liaison/1538/ https://datatracker.ietf.org/liaison/1616/ A lot of the comments in the LSs to ESTI-TC-CYBER also apply to the NIST work. "Our foremost concern is the use of the name Transport Layer Security (TLS), a well-known protocol which has been developed by the IETF for over twenty years. The IETF maintains copyright and change control for TLS specifications. Having a separate, different, protocol named "TLS" but developed by another SDO is a recipe for confusion among developers, implementers, and users alike." "The IETF remains strongly committed to fostering end-to-end security, and the properties of TLS enable that for key IETF protocols. We believe the ETSI work to proceed from a different design goal: to enable third-party monitoring. Because applications using TLS expect its end-to-end security properties, the re-use of the name will create misunderstandings. We therefore formally request that ETSI alter the name of its work enabling third-party monitoring so that implementors, users, and governments are not confused about its properties or the properties of TLS." "the main area of divergence from TLS 1.3 to this MSP profile is the replacement of the server’s "ephemeral" DH key with a "static" DH key, which suffices to violate the design and operational assumptions of TLS 1.3 and render this MSP profile as a qualitatively different protocol that should be named accordingly." My feeling is that the IETF community is much more against reuse of key shares now than in 2017. At IETF 116 there seemed to be consensus to discourage psk_ke. RFC8446bis and RFC9325 now have strong normative text discouraging key share reuse. I personally think it is problematic and not very constructive if IETF states that all visibility solutions are bad. It would in my view be more pragmatic to state that some technical solutions are better than other. Cheers, John From: TLS <tls-boun...@ietf.org> on behalf of John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Date: Tuesday, 16 May 2023 at 15:59 To: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>, tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3 Hi Rich, Good that you inform the TLS WG. I was planning to do that but forgot. Ericsson is likely to provide the comments in the link below. We think it is good that NIST is doing this project, visibility is a problem, but our position is that reuse of key shares is not an acceptable solution. https://github.com/emanjon/Publications/blob/main/Ericsson%20comments%20on%20NIST%20SP%201800-37A%20May%2013.pdf<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-7d2441a08db5bc25&q=1&e=aaabd95a-d6a9-4af8-9292-dd48d0908491&u=https%3A%2F%2Fgithub.com%2Femanjon%2FPublications%2Fblob%2Fmain%2FEricsson%2520comments%2520on%2520NIST%2520SP%25201800-37A%2520May%252013.pdf> Cheers, John From: TLS <tls-boun...@ietf.org> on behalf of Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> Date: Tuesday, 16 May 2023 at 13:19 To: tls@ietf.org <tls@ietf.org> Subject: [TLS] NIST Draft comments period: Addressing Visibility Challenges with TLS 1.3 Public comment period open until June 26. Quoting from https://content.govdelivery.com/accounts/USNIST/bulletins/359534b This project builds on our earlier work, “https://www.nccoe.nist.gov/tls-server-certificate-management,” which showed organizations how to centrally monitor and manage their TLS certificates. We are now focusing on protocol enhancements such as TLS 1.3 which have helped organizations boost performance and address security concerns. These same enhancements have also reduced enterprise visibility into internal traffic flows within the organizations' environment. This project aims to change that--and has two main objectives: • Provide security and IT professionals practical approaches and tools to help them gain more visibility into the information being exchanged on their organizations’ servers. • Help users fully adopt TLS 1.3 in their private data centers and in hybrid cloud environments—while maintaining regulatory compliance, security, and operations. _______________________________________________ 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
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
