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

[Christopher Wood <[e-mail]>]

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