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

[John Mattsson <[e-mail]>]

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

I agree, what I think IETF should do is to say what NOT to do. It is great that UTA already says MUST NOT negotiate NULL encryption. NULL encryption has no legitimate use cases. I think IETF should also take a strong stand against reuse of key shares. Reuse of key shares is a minor optimization that has a large number of problems:
- It is a very bad way to do visibility as you lose “Forward secret with respect to long-term keys”. I don’t think it is acceptable at all.
- It enables identification and tracking of clients and servers.
- To enable resuse you need random numbers which significantly increases the size of cTLS. Without reuse you don’t need separate randoms. Except for psk_ke which should not be used anyway.
- random numbers can be used by attackers as shown by draft-rescorla-tls-extended-random.

Cheers,
John

From: Rob Sayre <[e-mail]>
Date: Saturday, 8 April 2023 at 00:03
To: Andrei Popov <[e-mail]>
Cc: John Mattsson <[e-mail]>, Christopher Wood <[e-mail]>, Sean Turner <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile
On Fri, Apr 7, 2023 at 2:19 PM Rob Sayre <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of John Mattsson
Sent: Friday, April 7, 2023 8:25 AM
To: Andrei Popov <Andrei.Popov=[e-mail]<mailto:[e-mail]>>; John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>>; 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


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