Re: [Pearg] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

[John Mattsson <[e-mail]>]

Happy new year Christopher!

>Can you sharpen this a bit? Do you have examples of how >functional requirements for solutions in the zero trust space align >with end-user privacy?

In the past enterprise networks and mobile core networks were
considered "trusted" and only protected with perimeter security.
Essential zero trust principles are to assume that breach is
inevitable or has likely already occurred [NSA-ZT], and to minimize
impact when breach occur [NIST-ZT]. In fact, I think basically everything
in zero trust can be derived from these two principles. With zero trust
you are suddenly requireed to assume that your supply chain might be
compromised, that all the network parths are compromised, that nodes
are compromised, and that keys are compromised. Minimizing impact
from these kind of compromises means that you are required to do things like
- Always use encryption inside the network
- Use frequent Ephemeral Diffie-Hellman (e.g., every hour and 100 GB)
- Nodes should only share data on a need-to-know basis
- Decentralize storage so that breach of one node only gives part of the data
- Hide metadata like identities so that an attacker cannot se how is talking to who.
- etc.

I think all of the above are also things that should be done for end-user privacy

   [NIST-ZT]  National Institute of Standards and Technology,
              "Implementing a Zero Trust Architecture", December 2022,
             <https://www.nccoe.nist.gov/sites/default/files/2022-12/
              zta-nist-sp-1800-35b-preliminary-draft-2.pdf>.

   [NSA-ZT]   National Security Agency, "Embracing a Zero Trust Security
              Model", February 2021, <https://media.defense.gov/2021/
              Feb/25/2002588479/-1/-1/0/
              CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF>.




From: Christopher Wood <[e-mail]>
Date: Tuesday, 3 January 2023 at 17:14
To: John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Pearg] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
(-other lists except PEARG)

Happy new year, John! Thanks for this message. I have one question inline below.

> On Jan 3, 2023, at 5:27 AM, John Mattsson <john.mattsson=[e-mail]> wrote:
>
> After Snowden, IETF certainly did talk the talk , but I think it does not always walk the walk. The average amount of privacy in new RFCs has certainly gone up and there are many great new mechanisms like QUIC, Privacy Pass, and OPAQUE. The minimum level in IETF is however still too low. IETF is e.g., still producing new standards without forward secrecy and identity protection and are not changing the status of old standards track RFCs that are no longer aligning with best practice security and privacy practices.
>
> - Forward secrecy: To always use ephemeral Diffie-Hellman got a lot of discussion after Snowden, but unfortunately the IETF is still producing standards track documents without forward secrecy, e.g., using PSK key exchange, or storing session keys. IETF seems to also mostly have forgotten additional properties that has often been included in the term PFS (RFC 2828). Assuming breach like key compromise is an essential zero trust principle.
>
> - Identity protection: IETF is still producing standards track documents without identity protection. E.g., reusing PSK identifiers or sending unencrypted signatures. Why is IETF adopting bad PSK practices from old mobile generations when 3GPP is working hard to mitigate its PSK vulnerabilities with ECIES and ECDHE?
>
> - NULL algorithms: NULL encryption should have no place in two party protocols at all. AES-GCM is as fast as integrity only or even non-cryptographic CRC.
>
> - IP layer: While the transport layer and application layer has seen significant improvements such as QUIC and HTTP/3 and the link layer has seen improvements with MAC randomization, not much has happened at the Internet layer. IP addresses are still not only long-lived trackable identifiers, but they also reveal your location.
>
> - Threat Model: The IETF has failed to update the Internet Threat Model to include compromised endpoints, misbehaving endpoints, and large centralized information sources. This is very disappointing as these things were, and still are major enablers for pervasive monitoring. Assuming compromise is an essential zero trust principle. The excellent IAB document RFC 7624 that talks about compromise and exfiltration deserve much more citations.
>
> - Old RFCs: How should we handle old security- and privacy-related standard track RFCs? I think being standards track signal that IETF thinks the mechanism still provides best practice security and privacy. Most 10-year-old standard track documents are no longer living up to best practice. The current system makes it very hard to change the status of RFCs. Should RFCs automatically be downgraded to informational unless there is consensus that they still provide best practice security and privacy?
>
> Now when ten years have passed, I think the IETF should analyze how we did. Where did we succeed, where did we fail, and what can we do better in the future? An interesting development is that requirements for privacy and zero trust often aligns.

Can you sharpen this a bit? Do you have examples of how functional requirements for solutions in the zero trust space align with end-user privacy?

Best,
Chris, no hat