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

[Andrei Popov <[e-mail]>]

  *   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 <[e-mail]> On Behalf Of John Mattsson
Sent: Friday, April 7, 2023 8:25 AM
To: Andrei Popov <Andrei.Popov=[e-mail]>; John Mattsson <john.mattsson=[e-mail]>; Christopher Wood <[e-mail]>; Sean Turner <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> on behalf of Andrei Popov <Andrei.Popov=[e-mail]<mailto:Andrei.Popov=[e-mail]>>
Date: Thursday, 6 April 2023 at 20:08
To: John Mattsson <john.mattsson=[e-mail]<mailto:john.mattsson=[e-mail]>>, Christopher Wood <[e-mail]<mailto:[e-mail]>>, Sean Turner <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of John Mattsson
Sent: Thursday, April 6, 2023 7:41 AM
To: Christopher Wood <[e-mail]<mailto:[e-mail]>>; Sean Turner <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> on behalf of Christopher Wood <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 19 January 2023 at 15:57
To: Sean Turner <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls