How is this going to work when a lot of sites/apps start to use QUIC? It's like blocking HTTPS because "the limitations upon network management are massive"

It's going to make things work slightly less well from the corporate office than they do at home on your cheap setup.

That's a continuing trend, and you might recognise it from other aspects of life. Paying more while deliberately choosing a worse service is pretty much life-as-usual for corporations.

One of my previous employers had a deal to get train tickets. In my country train tickets for actual consumers, even ordered online, don't have a service fee. After all in choosing to order online you're actually saving them money, why would it cost extra? But the corporation paid about 5% fees to get train tickets from a company which also provides those zero fee services to individuals.

Or think about all the companies where Windows XP desktops were still being used years after they were obviously the wrong choice.

Monday to Friday the world IPv6 utilisation goes down, but every weekend it's back up. Because at home people have IPv6 (even if they've never thought about it) while at work somebody explicitly turned that off.

One of the nice things about working from home is that my network works very well, whereas whether I worked for a startup or a billion dollar corporation it was always one problem or another when I was in the office. Which reminds me, I should really look for a new job as this pandemic begins to slacken off.

> Or think about all the companies where Windows XP desktops were still being used years after they were obviously the wrong choice.

I like that you used past tense there, but I'm pretty sure XP is not dead yet. Unfortunately :/

Many sites will support QUIC soon, but they won't strictly require it for a long time, it's negotiated and backward compatibility isn't irrelevant quite yet.

They will always have to support a fallback (HTTP/1.1 or HTTP/2), because not all users are guaranteed to have success with QUIC. Blocked UDP traffic and ports can be some reasons why it won't work, too small supported MTUs can be other reasons.

HTTPS is necessary. QUIC is not.

It’s going to be a long time before any site requires QUIC in order to work.

curious why you think there are no benefits to QUIC?

QUIC is purpose-built to circumvent middleboxes. Enterprise networking benefits greatly from providing security and accountability via such middleboxes. The effort required to properly secure a network trying to circumvent your network security is costly and more complex.

Some say "security and accountability" others say launch a MITM attack to spy on employees.

Depends on the company, obviously. I don't care if employees do whatever on work computers, I care about protecting my network and my users.

In practice, all of this attempt to bypass middleboxes does not help my users browse securely. It makes it harder to block ads, it makes it harder to detect phishing sites and other threats, and that's about it.

I mean, that's a trend that's been ongoing in both the HTTP and TLS world for a while now, independent of QUIC. Similar complaints arose with the announcement of HTTP/2 being TLS only, if I recall, and TLS 1.3 would probably already be widely deployed right now if not for some complications with deployed middleboxes causing connection failures in the wild (which I don't entirely blame on them; after all, bugs happen...)

If you simply obey the standard, everything works perfectly well. For example, the only standard way to build HTTPS middleboxes is to fasten a standards compliant client and server together, when a corporate user tries to visit google.com the server presents them with its Certificate for google.com from your corporate CA, and the client connects to the real google.com, now the flow is naturally plaintext inside your middlebox and you can do whatever you want.

If you did that, when TLS 1.3 comes along, your middlebox client connects to google.com, the client says it only knows TLS 1.2, google.com are OK with that, everything works fine. When the corporate user runs Chrome, they connect to the middlebox server, it says it only knows TLS 1.2, that's fine with Chrome, everything works fine. The middlebox continues to work exactly as before, unchanged.

So what happened in the real world? Well of course it's cheaper to just sidestep the standards. Sure, doing so means you fatally compromise security, but who cares? So you don't actually have a separate client and server wired together, you wire pieces of the two connections together so that you can scrimp on hardware overhead and reduce your BOM while still charging full price for the product.

The nice shiny Chrome says "Hi, google.com I'm just continuing that earlier connection with a TLS 1.2 conversation we had, you remember, also I know about Fly Casual This is Really TLS 1.3 and here are some random numbers I am mentioning"

The middlebox pretends to be hip to teen slang, sure, pass this along and we'll pretend we know what "Fly Casual This Is Really TLS 1.3" means, maybe we can ask another parent later and it sends that to the real google.com

Google.com says "Hi there, I remember your previous connection wink wink and I know Fly Casual This Is Really TLS 1.3 too" and then everything goes dark, because it's encrypted.

The middlebox figures, well, I guess this was a previous connection. I must definitely have decided previously whether connecting to Google was OK, so no need to worry about the fact it mysteriously went dark before I could make a decision and it takes itself out of the loop.

Or worse, the middlebox now tries to join in on both conversations, even though it passed along these "Fly Casual This Is Really TLS 1.3" messages yet it doesn't actually know TLS 1.3, so nothing works.

Doesn't Google sponsor Starbucks' WiFi?