Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

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.com@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-bounces@ietf.org> *On Behalf Of *John Mattsson
> *Sent:* Friday, April 7, 2023 8:25 AM
> *To:* Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>; John
> Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>; Christopher Wood <
> caw@heapingbits.net>; Sean Turner <sean@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-bounces@ietf.org> on behalf of Andrei Popov <
> Andrei.Popov=40microsoft.com@dmarc.ietf.org>
> *Date: *Thursday, 6 April 2023 at 20:08
> *To: *John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>,
> Christopher Wood <caw@heapingbits.net>, Sean Turner <sean@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-bounces@ietf.org> *On Behalf Of *John Mattsson
> *Sent:* Thursday, April 6, 2023 7:41 AM
> *To:* Christopher Wood <caw@heapingbits.net>; Sean Turner <sean@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-bounces@ietf.org> on behalf of Christopher Wood <
> caw@heapingbits.net>
> *Date: *Thursday, 19 January 2023 at 15:57
> *To: *Sean Turner <sean@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 <sean@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
>