Hiya,
On 18/05/2023 05:43, John Mattsson wrote:
I think IETF should state in the LS that: 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 amongdevelopers, implementers, and users alike.
I'm not sure that the copyright issue really comes up wrt this NIST activity - seems more likely NIST would issue some report on "NIST's ideas for HOWTO do TLS badly" rather than try define a borked version of TLS a la ETSI. (I'd also guess that even people who want to weaken TLS would learn lessons from others failed attempts;-)
Reuse of key sharesviolate the design and operational assumptions of TLS 1.3
The above is the key point yes. I do think there's value in having something to point imeplementers at that says the IETF don't agree with NIST's bad ideas here.
and render this NIST profile as a qualitatively different protocol that should be named accordingly. We therefore formally request that NIST alter the name of its work on a protocol with key share reuse so that implementors, users, and governments are not confused about its properties or the properties of TLS.
Again, not sure thinking about this in terms of a different "weaker NIST-version of TLS" is likely the best way to try get them to see sense. In this case it may be better to point at MUSTs or SHOULDs or other RFC text they're asking be violated. Cheers, S. PS: FWIW, mostly unrelated, but this NIST activity (and I guess the dual-ec debacle) makes at least me somewhat less keen on just accepting NIST's choices for PQ things. If that applied to others, it may become relevant (in terms of the ease of achieving consensus) when we get to which hybrid stuff to standardise for TLS in the not too distant future.
Where the above text is more or less copy pasted from the LSs to ETSI. Cheers, John On 2023-05-17, 20:43, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote: 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<mailto:tls-boun...@ietf.org>> on behalf of John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:40ericsson....@dmarc.ietf.org>>
Date: Tuesday, 16 May 2023 at 15:59
To: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org<mailto:40akamai....@dmarc.ietf.org>>, tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto: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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-0709a0af3bfcfd71&q=1&e=572ebc85-77e0-4e77-bfd3-3dc82a21c3bf&u=https%3A%2F%2Fgithub.com%2Femanjon%2FPublications%2Fblob%2Fmain%2FEricsson%2520comments%2520on%2520NIST%2520SP%25201800-37A%2520May%252013.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><https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-0709a0af3bfcfd71&q=1&e=572ebc85-77e0-4e77-bfd3-3dc82a21c3bf&u=https%3A%2F%2Fgithub.com%2Femanjon%2FPublications%2Fblob%2Fmain%2FEricsson%2520comments%2520on%2520NIST%2520SP%25201800-37A%2520May%252013.pdf%3chttps://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%3e>
Cheers,
John From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of Salz, Rich <rsalz=40akamai....@dmarc.ietf.org<mailto:40akamai....@dmarc.ietf.org>>
Date: Tuesday, 16 May 2023 at 13:19
To: tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: [TLS] NIST Draftcomments 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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls_______________________________________________ TLS mailing list TLS@ietf.org<mailto: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
