* 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
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<mailto:tls-boun...@ietf.org>> on behalf of
Christopher Wood <c...@heapingbits.net<mailto:c...@heapingbits.net>>
Date: Thursday, 19 January 2023 at 15:57
To: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org> <tls@ietf.org<mailto: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<mailto: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<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
