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

[Lloyd W <lloyd.wood=40yahoo.co.uk@xxxxxxxxxxxxxx>]

On "- 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"

I'm going to politely ignore the rest of your email, and dig into this point.

we went through this in DTNRG at some length over some years[*], since one of  DTN's many boil-the-ocean goals was to be Completely Secure From The Start.

This took us into what reliable delivery of content means; there are good reasons for forwarding nodes to easily check that what they are expending effort on relaying is reliable and error-free , even if they are never privy to the content that they are helping deliver. And a non-crypto hash is very very suitable for that role, wrapping inner security protocols. Which is just how a MAC-layer CRC works layered outside an IPSec packet, oddly enough. (I do like MD5 as  a CRC equivalent just for checking reliability of Really Big Data in transit, where no security properties can or should be assumed or  expressed; security integrity becomes an inner-content problem. And like CRC code, MD5 code is not complex, and Just Works.)

Sure, we could use a Proper Fashionable Security Protocol instead, but if all nodes need to use that protocol just to check integrity for error-free reliability, they'll all have the key to that outer security layer, and then there's much added complexity for little obvious benefit.

If we want to replace a tuned CRC with something more complex and error-prone in implementation that, because it's a security protocol, will soon be considered to be out of fashion and will need to be replaced everywhere with something with e.g. longer key lengths that is following all the modern ways, with all the interop challenges that await... well, good luck with that. And I have another meeting to go to about TLS 1.3 supplanting TLS 1.2...

My naive thought is that if we want to build a lasting standard (like, um, TCP) we leave security out of it as much as possible, and then that standard avoids being constantly dinged by the security fashion police or having to be changed to be incompatible with its former self. And I can't see eg. TCP STD 7 being downgraded to informational simply because it's not expressing best security practices, which are moving targets.

If security RFCs are constantly refreshed more quickly to stay in line with security fashion, great -- as long as that's a self-contained bubble not breaking anything outside it, or causing more work in standards or implementations for anyone else.

QUIC and HTTP/3 are improvements? Not through all eyes; there's much complexity, and compatibility only at a point in time for ever-more-intricate state machines.

There's much talk of forward secrecy, but little of forward compatibility. And there is much so more to engineering and its tradeoffs than just security.

best

Lloyd Wood

lloyd.wood@xxxxxxxxxxx

[*] our 'Bundle of Problems' paper captures some of those arguments

On 3 Jan 2023, at 21:29, John Mattsson <john.mattsson=40ericsson.com@xxxxxxxxxxxxxx> 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. The only reasonable assumption is that breach everywhere is inevitable or has likely already occurred and try to minimize the impact when breach occur. What IETF does is very important. A lot of other SDOs and organizations look at IETF for inspiration.

 

Cheers,

John