Why We Love QUIC and HTTP/3

If they don't have a valid cookie Fast Open costs the same as regular TCP in the face of adversaries trying to DOS you. You examine the packet, it doesn't have a valid cookie, you discard it. No further work, just like ordinary TCP.

The specification says: YOU must choose RANDOM numbers otherwise bad things could happen.

[ TLS 1.3 final hides a downgrade signal in those random numbers if you appear to only speak TLS 1.2. The TLS 1.2 specification says nothing about a downgrade signal, so if you recognise the signal that means you wanted TLS 1.3 but the server has been told you wanted TLS 1.2, a downgrade attack is being attempted. Abort! ]

These famous brand middleboxes were too lazy to make random numbers, they'd just take the exact numbers the real server picked and use those. Those are random right? What could go wrong?

The result was that the TLS 1.2 Downgrade signal would get copied into supposedly "fresh" TLS 1.2 connections and trip the abort mechanism.

Just an incompatibility right? Nope. For the years that this idiocy was in those products they weren't actually delivering security, the requirement that you pick RANDOM numbers is there for a good reason - if sophisticated bad guys knew this "bug" was present in the famous brand middleboxes they could definitely have exploited this to snoop connections.

In any case, it's hard for a client to determine if a TXT record is not present, or unavailable because the authoritative server has no such record, or because something in the middle has blocked it (due to network incompetence or active malice), so if you want that to work, you're going to need to specify dns over https to a trusted third party, and de-decentralize DNS.

That said, from a brief look at the spec, the ESNI extension includes a digest of the key record, so while an observer can't directly read the SNI, given a sufficient effort to find the keys, they could correlate the digests with matching hostnames.

Reaching key agreement to exchange identity information without disclosing the identities in the clear is somewhere between really hard and impossible.

If I understand it correctly, I think that countries might start to block ESNI altogether. If it is not widely implemented, websites/apps using it will standout which sadly could limit its adoption. For instance, if Signal decided to use ESNI, it will probably get blocked in those countries, but this can change if big companies wanted to use it. However, I still don't know how it will work exactly.

The important design distinction about the layers is what element has access to what data. (e.g. routers need to see IP addresses to do their job, port numbers help kernels segment permission models, etc..) The rest of it is just about logical models, real-world workarounds, and luck...

HTTP/3 will be able to get high bandwidth, buttery responsive restarts to connections far too long idle to keep "open" because it integrates security, application, and transport. That's thoughtful design, not a workaround.

I'm going to paraphrase (and maybe bungle, because I don't have it at hand) from my favorite networking book of all time - the underappreciated _Network Algorithmics_ by George Varghese. He describes layers as a lovely way to model and think about a protocol or design, but often a terrible way to build one. I've spent a lot of time thinking about that, and I think QUIC gets it right - the layers are clear in how they inter-relate but they do so without being independent.