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 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
