On Fri, Apr 7, 2023 at 2:19 PM Rob Sayre <say...@gmail.com> wrote: > Hi, > > I think this concern is really reasonable. > > I would suggest publishing it on the independent stream, not AD > sponsorship. It's not an end-run around any IETF activity, but it should be > documented. > > thanks, > Rob >
And, just in case anyone reading this is not a standards dork (like me), here is why this path exists: https://www.rfc-editor.org/about/independent/ "The Independent Submission Stream allows RFC publication for some documents that are outside the official processes of the IETF, IAB, and IRTF but are relevant to the Internet community and achieve reasonable levels of technical and editorial quality." This example seems like a textbook case. The only thing that I disagree with the chairs on is "IETF change control". I think that is radioactive and the IETF shouldn't touch it. Reasonable people can disagree, Rob > > > On Fri, Apr 7, 2023 at 11:19 AM Andrei Popov <Andrei.Popov= > 40microsoft....@dmarc.ietf.org> wrote: > >> >> - That seems way to soft and does not say anything about reusing a >> key share in an _*ECDHE*_ cipher suite for a long time making it >> static. But RFC8446bis now has added SHOULD NOT reuse key share which is >> very welcome. My preference would be MUST NOT reuse. >> >> Agreed, and I also generally agree with your analysis of options 1-4. >> >> >> >> However, the IETF standardizing any TLS MITM/visibility options would be >> a net negative, from my perspective. That would increase the (already >> significant) pressure on TLS stack implementors to provide these >> “visibility” solutions. This pressure already comes from a lot of different >> angles. >> >> >> >> Cheers, >> >> >> >> Andrei >> >> >> >> *From:* TLS <tls-boun...@ietf.org> *On Behalf Of *John Mattsson >> *Sent:* Friday, April 7, 2023 8:25 AM >> *To:* Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org>; John >> Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; Christopher Wood >> <c...@heapingbits.net>; Sean Turner <s...@sn3rd.com> >> *Cc:* TLS@ietf.org >> *Subject:* [EXTERNAL] Re: [TLS] Call for adoption of >> draft-thomson-tls-keylogfile >> >> >> >> >> >> Thanks! >> >> >> >> >“Implementations MUST NOT negotiate the cipher suites with NULL >> encryption.” >> >> I will add a link to RFC 9325 in the next version of >> draft-mattsson-tls-psk-ke-dont-dont-don’t >> >> >“Implementations SHOULD NOT negotiate cipher suites based on >> non-ephemeral (static) finite-field Diffie-Hellman (DH) key agreement.” >> >> That seems way to soft and does not say anything about reusing a key >> share in an _*ECDHE*_ cipher suite for a long time making it static. But >> RFC8446bis now has added SHOULD NOT reuse key share which is very welcome. >> My preference would be MUST NOT reuse. >> >> Cheers, >> John >> >> >> >> *From: *TLS <tls-boun...@ietf.org> on behalf of Andrei Popov < >> Andrei.Popov=40microsoft....@dmarc.ietf.org> >> *Date: *Thursday, 6 April 2023 at 20:08 >> *To: *John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>, >> Christopher Wood <c...@heapingbits.net>, Sean Turner <s...@sn3rd.com> >> *Cc: *TLS@ietf.org <TLS@ietf.org> >> *Subject: *Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile >> >> - Maybe IETF (e.g., UTA) could say what organizations should >> definitely not do (like NULL encryption). >> >> This is already done. UTA BCPs prohibit NULL encryption and static DH: >> https://www.rfc-editor.org/rfc/rfc9325.html >> >> “Implementations MUST NOT negotiate the cipher suites with NULL >> encryption.” >> >> “Implementations SHOULD NOT negotiate cipher suites based on >> non-ephemeral (static) finite-field Diffie-Hellman (DH) key agreement.” >> >> >> >> Cheers, >> >> >> >> Andrei >> >> >> >> *From:* TLS <tls-boun...@ietf.org> *On Behalf Of *John Mattsson >> *Sent:* Thursday, April 6, 2023 7:41 AM >> *To:* Christopher Wood <c...@heapingbits.net>; Sean Turner <s...@sn3rd.com >> > >> *Cc:* TLS@ietf.org >> *Subject:* [EXTERNAL] Re: [TLS] Call for adoption of >> draft-thomson-tls-keylogfile >> >> >> >> Hi, >> >> >> >> So, what should people do regarding visibility? There are obviously >> organizations that think they need visibility. I see the topic popping up >> frequently in a lot of different places. Both in IETF and outside. >> >> I see four ways to achieve visibility. >> >> >> >> 1. Do things in the endpoints. >> >> 2. Use NULL encryption >> >> 3. Use a static DH key instead of ephemeral. Share static DH key. >> >> 4. Export session keys to intermediate node. >> >> >> >> I don't see 2 and 3 are not viable solutions at all, ever. >> >> >> >> Regarding 2. it violates several of the TLS security properties. NIST >> states as the first basic assumption for network connectivity for any >> organization that utilizes zero trust is that: >> >> >> >> "The entire enterprise private network is not considered an implicit >> trust zone. Assets should always act as if an attacker is present on the >> enterprise network, and communication should be done in the most secure >> manner available. This entails actions such as authenticating all >> connections and encrypting all traffic." >> >> >> >> Regarding 3. it violates one of the fundamental TLS 1.3 security >> properties namely "Forward secret with respect to long-term keys". It also >> violates zero trust principles. Two essential zero trust principles >> according to NIST and NSA are to assume that breach is inevitable or has >> likely already occurred and to minimize the impact when breach occur. One >> type of breach is key compromise. Using PFS is a must to limit the impact >> of key compromise and therefore to follow zero trust principles. >> >> >> >> The only viable solutions I see are therefore 1 or 4: >> >> >> >> 1. do things in the endpoints >> >> >> >> 4. export sessions keys to the intermediary and making sure that the >> intermediary does not store the keys long term. Storing the session keys >> long term violates the TLS security properties and the zero trust >> principles described above. >> >> >> >> Regarding 4. there are many different solutions. >> >> >> >> - SSLKEYLOGFILE is a de facto standard for exporting TLS key material. >> >> >> >> - ETSI CYBER has standardized Middlebox Security Protocol. >> >> >> https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf >> >> >> >> - Proprietary solutions such as >> >> https://www.nubeva.com/pillar/get-session-keys >> <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-5f34a1d271355f52&q=1&e=f3aeeac6-dde5-492c-8992-c755e6a13aca&u=https%3A%2F%2Fwww.nubeva.com%2Fpillar%2Fget-session-keys> >> >> >> >> If IETF cannot say that anything is recommended. Maybe IETF (e.g., UTA) >> could say what organizations should definitely not do (like NULL >> encryption). Seems like a lot of organizations are deploying different >> kinds of solutions right now. They will likely do less secure things than >> necessary... >> >> >> >> Cheers, >> >> John >> >> >> >> *From: *TLS <tls-boun...@ietf.org> on behalf of Christopher Wood < >> c...@heapingbits.net> >> *Date: *Thursday, 19 January 2023 at 15:57 >> *To: *Sean Turner <s...@sn3rd.com> >> *Cc: *TLS@ietf.org <tls@ietf.org> >> *Subject: *Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile >> >> Hi folks, >> >> Apologies for the delay in concluding this adoption call. To close the >> loop here, it doesn’t look like we have sufficient support to adopt the >> document as a WG item. >> >> The chairs would like to recommend AD sponsorship as a viable path >> forward for this document. This should achieve the desired end goal of >> moving change control from the fine folks maintaining NSS to the IETF while >> also nailing down the now widely supported format used in production. >> >> Best, >> Chris, for the chairs >> >> > On Nov 28, 2022, at 1:41 PM, Sean Turner <s...@sn3rd.com> wrote: >> > >> > Hi! >> > >> > At TLS@IETF115, the sense of the room was that there was WG support to >> adopt draft-thomson-tls-keylogfile [1]. This message is to judge consensus >> on whether the WG should adopt draft-thomson-tls-keylogfile. Please >> indicate whether you do or do not support adoption of this I-D by 2359UTC >> on 12 December 2022. If do not support adoption, please indicate why. >> > >> > Cheers, >> > Chris, Joe, and Sean >> > >> > [1] https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/ >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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
