Working Group Last Call: QUIC protocol drafts
mailarchive.ietf.org
mailarchive.ietf.org
Now all those ISPs, IT departments, and cloud providers that de-prioritize or outright block UDP will get "bug reports" about things being "slow" or not working.
Now all those traffic shaping middle-boxes are worthless, and your ISP can no longer spy on your requests to gather marketing data about you.
The Internet is an IP network, not a TCP/80 and TCP/443 network.
Or as last resort they'll legislate either to end or weaken it.
I hope I'm mistaken, though.
That assertion will require lots of hard evidence because the vast majority of indicators indicate otherwise.
* free or less than 20$/mo
Giant centralized troves of personal data are a huge risk to everyone. Civilization pivots and mutates rapidly, and it's clear to nobody at any particular time which way it may lean next, or whether it will lean toward them or on top of them. If anyone had told you there'd be global mass beheadings of century-old statues 3 weeks ago, I suppose you'd have been laughing then too.
Then, in a few years, when you notice that most of the traffic is done over QUIC, you still won't do anything as it has no significant cost anyway and helps the few % of people who haven't upgraded their network. And customers who can use it won't notice much as your website still works anyway, but your latency metrics should be better for those users.
No reasonable implementation of encrypted SNI has been proposed or standardized. Those middleboxes are still more than useful
AFAIK in QUIC there is some light obfuscation of the ClientHello, but it is not intended to be an anti-filtering measure, middleboxes can still fish out any presented name with a little bit of new code
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
... do you feel is unreasonable?
In practical terms I guess it is reasonable, but viewed from the angle of how the Internet was originally intended to work, it is obviously abhorrent and self-serving.
If cat-videos.example and elect-bob.example are just names for the same IP 10.20.30.40 then we can use eSNI to prevent eavesdroppers discovering which you visited and that's all.
But if you've got 10.20.30.40 assigned by your ISP for your personal web server then eSNI can't hide that, you can use eSNI to prevent eavesdroppers learning whether visitors were looking at snakes-control-nasa.example or soup-does-not-exist.example but if all you host are crazy conspiracy theory sites then they don't need to know which one is which to block all of them, that's just how IP works.
The configuration for eSNI is delivered over DNS, so it's up to you to choose how you want get secure DNS.
That's just because QUIC is a new, not yet specified protocol, isn't it?
Kernels will get support eventually. Microsoft is actually already shipping some code. [1]
Browsers will probably switch to OS facilities once they are mature enough and provide a performance benefit.
[1] https://www.windowslatest.com/2018/04/03/microsoft-to-add-su...
The end-to-end argument in IP networking evolved in a time (the 1970s and 1980s) when a host could reasonably be considered the endpoint. Now hosts are so big and powerful that it's no longer reasonable to draw the boundary around them. The individual process running on the host is the true endpoint, and having the application in charge of its own network flow control is the natural evolution of things.
But a userspace network stack only make sense in single purpose devices/servers, because they have to take over the hardware, right?
On a consumer device many applications can use the network concurrently.
QUIC runs on top of UDP anyway, so userspace libraries use OS UDP facilities, but lose the ability to do better cross-application balancing. Hardware TCP offloading also plays a role of course.
For example, many network cards support creating multiple virtual network devices, and you could hand a whole such device to a userspace process, but only let it see traffic intended for that device.
Or, finer-grained, you could use a filter to steer certain packet flows to a process, while handling others in the kernel.
I do absolutely think there's value in having native QUIC in the kernel, but then, I also think there's value in having native TLS in the kernel; doesn't mean you always want to use it.
It's not clear that this is a good thing. You generally want things like network-provided congestion notification+control, and plain vanilla UDP won't be enough for this.
https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...
The primary benefactor of your end-to-end argument is ad networks that also own web browsers.
Hence why this is political, it's about shifting network traffic outside of places users have control.
Doubt it. I suspect that browsers have some sort of happy eyeballs algorithm for determining whether to use http/3 specifically because some networks don't handle it well. In those cases it'll fall back to http 1.1.
>Now all those traffic shaping middle-boxes are worthless
How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone?
> and your ISP can no longer spy on your requests to gather marketing data about you.
That's more encryption (ie. https) than switching to http/3. Also, encryption is already mandatory for http/2 (for most browsers).
Modern TLS agrees the sub-protocol to use (in this case h2 = HTTP/2) early with ALPN. If that ALPN sub-protocol isn't available that same connection just becomes HTTP/1.1 (over TLS) instead.
So there's no reason to fall all the way to HTTP/1.1 without asking if HTTP/2 is available.
On day zero? Sure. But then good networks will slowly enable UDP/443 anyway, and have good cover because it's The Web, and eventually it'll be enabled on more than 90% of networks.
Then a few non-browser applications that use QUIC/HTTPS will decide that 90% is good enough and start to not support TCP anymore, causing trouble for the holdouts and getting it enabled on 95% of networks. Then even more applications will do that.
At some point the browsers can put up a warning when fallback happens, telling the user that their network is degrading performance.
Eventually the number of networks that don't support it is small enough that nobody supports fallback anymore.
> How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone?
They can't mess with window sizes and such because they're inside the encrypted payload.
Reasons for this:
* No upstream incentive due to little or no competition and not enough "killer apps."
* Security FUD: if it's new then it might allow something currently not understood.
* ISP desire to control traffic and prohibit anything new.
* First thing IT will do if there's a problem is "turn the new thing off." (This happens a lot with IPv6 even if IPv6 is not a cause.)
* Vendors with a vested interest in treating the disease (supporting technical debt) rather than curing the patient (actually fixing the problem, reducing the need for complex solutions).
My point in the original comment was that QUIC might help stop further ossification by making UDP actually necessary. Otherwise we face the potential for removal of UDP and even removal of non-standard TCP ports, eventually leading to "http only" networks. ISPs and IT departments would like that since less capability equals less support queries and less to monitor.
If IP were re-designed today I would suggest at least non-cryptographic but difficult to efficiently modify authentication of all fields (e.g. keyed or nonced checksums), and obfuscation (fast minimal encryption?) of everything under the IP header. No NAT, and nothing useful to filter on. If it's visible and mutable it will become ossified since people will MITM it.
That way there would be no choice but to fix endpoint security instead of deploying firewalls and no choice but to adopt IPv6 instead of NAT. You couldn't temporarily work around fundamental problems by nerfing the net.
I think there's a general principle here. If easy short term fixes that incur long term technical debt are allowed, they will be deployed. If such a hack is deployed in a federated or decentralized system, it becomes permanent unless extra-systemic means (e.g. legislation or financial incentives) are used to force it to be removed. Therefore federated and decentralized systems should not permit such hacks. Front load the pain by forcing the problem to actually be fixed.
This is one thing block chains kind of get right. Everything is cryptographically hashed and authenticated. You can't modify state unilaterally. You either have a compliant node or you don't, and changes must be adopted globally either as soft or hard forks.
Companies have a legal and moral imperative to see what content is leaving their network, and until some combination of host/network governance is developed to only allow pre-authorized traffic to egress, MITM boxes will need to be supported.
"a legal and moral imperative"? No. Such networks are security threats and should be repeatedly broken until they give up. It will become increasingly expensive to even try. And an increasing number of security researchers will find ways to make maintaining MITM technologies more difficult and less transparent.
You can block spam and outbound attacks without MITMing traffic. MITMing traffic is not about protecting the outside world in any way. It's technology sold to companies out of fear (or misguided regulatory requirements). One day it will go the way of the virus scanner: dead, worse than useless, and only existing to satisfy a decreasing number of corporate checkboxes.
Let me be clear: If you do not think private companies and businesses have a right, and sometimes an obligation, to secure and monitor the traffic on their networks, then you are flat out incorrect, and this conversation can end.
If you agree they need to monitor data, but that MITM technologies are a societal risk more than a benefit, I am all ears. Host-based data scanning at an OS level; signed traffic that the network can trust has been scanned by authorized hosts (so rogue hosts don't send traffic out); and so on.
edit: I don't think your message is consistent, but I think that is not a sign of malice. You say "Companies have no legal or moral need to see what content is leaving their network" then say "You can block spam and outbound attacks without MITMing traffic."
You seem to be equating "See the content leaving their network" with "MITM", but then say later that companies can "prevent outbound attacks" without MITM. The #1 threat for many companies is data loss. How do you propose DLP gets accomplished with zero access to the network?
Does your employer have a right and obligation to see that you're searching for a cancer doctor?
Go to a large company's IT department and find the person there you dislike the most. Do you want that person monitoring the traffic and seeing that you searched for a cancer doctor?
Now you know why so very many of us believe you are completely wrong about this.
Now you see why so many of us believe you are completely wrong about this.
To your point:
If it is their network, it's their network and their computer. Access the website from home, or from your phone, which isn't MITM'ed on the corporate network.
If it is a resource only available on the corporate network, but it is not a "company resource" such as find-a-doctor, then you can (a) accept that the company may see it, (b) contact information security and ask if they can, or (c) find another way to get the information/complain to HR/ombudsman/whatever.
It is up to the company to do the right thing when possible, which means (in our case) we don't intercept websites categorized banking, health, and a handful of others.
Information security obfuscates/blocks the showing of personally identifiable logs to the rest of IT, as well.
Again, banks (in my example) have an obligation to their millions of customers to protect their data, more than you have a right to browse a doctor tool or upload sensitive spreadsheets to your personal Google Drive to work on over the weekend.
Do you have the right to prioritize your personal activities over your employers protection of its' data?
Creating blindspots on enterprise networks won't get far - especially not given today's realities of breaches.
It is absolutely fine in many countries to use a work computer for light and occasional personal use or on breaks. And no, employers don't always have the right to monitor all traffic that isn't relevant to the business, or even files on your machine marked as personal. Really depends on the local laws though.
I don't have to provide a "proposed solution" to MITM; the proposed solution is "stop that". To the extent MITM is getting harder, that means network protocols and software is getting better.
This is like asking the makers of adblockers what their "proposed solution" is for ads, or asking the makers of spam filters what their "proposed solution" is for sending spam.
Most critically, in a standards body, the right answer to people trying to MITM is a polite and diplomatic version of "go away, your use case is invalid".
> If you do not think private companies and businesses have a right, and sometimes an obligation, to secure and monitor the traffic on their networks
They can certainly try (currently), and one of the jobs of security researchers is to ensure they fail enough that they stop trying. I also hope one day that there's enough collective bargaining power among engineers that such companies cannot successfully hire people, and that nobody ever has to be desperate enough to accept such a draconian network. I'm glad I'm in a position to be able to say I'll never work for a company that requires MITM; everyone should be able to avoid that. And the only time I'm aware of a company having an obligation is due to misguided regulations on certain narrow classes of businesses.
> MITM technologies are a societal risk more than a benefit
The company is the only one who could possibly benefit, and that's leaving aside the likely possibility of doing more harm than good; security measures work better when your users want to help you rather than thwart you. Meanwhile, the societal harm of ever allowing MITM is massive.
Right now, the biggest step I'd love to see happen is browsers (in concert) having a persistent banner for "your traffic is being MITMed" any time they're getting the wrong certificate for sites, and browsers making that impossible to remove without rebuilding the browser from source (which is a substantial barrier). Next, we can make it easy for sites to detect access from MITMed networks, and make policy decisions on that basis. Then, coalitions of sites can collectively make it expensive to MITM.
Put that together with new protocols that are increasingly desirable, and increasingly unavoidable, and which users will want, and you have a recipe for substantially reducing the number of companies willing to even try to MITM.
> then say "You can block spam and outbound attacks without MITMing traffic."
"We block outbound email ports" is not an unreasonable policy, as an example. And if someone tunnels around that, now they're spamming from their network, not yours, so it's not your fault.
> How do you propose DLP gets accomplished with zero access to the network?
"DLP" has become equated with "MITM". But you could, instead, focus on access to the data rather than interception of exfiltration. If people are trying to exfiltrate your data, they will find a way, very very easily. And there are much better ways to catch accidents. Also, most companies are still at the level of avoiding headlines like "laptop stolen with our whole database on it", which has nothing to do with MITM.
Yes, access to sensitive data is one layer of defense in depth for data exfil - absolutely on point there. But then you throw up your hands and say "oh well" if they do get data, or if they have legitimate need to see it, and try to get it out. I don't buy that.
I agree with some of your thoughts in principle: Just like I don't agree with backdoors in crypto, I applaud TLS getting stronger toward PFS and eliminating MITM. But you're naive if you think companies don't have a right or desire to monitor the systems that hold their intellectual property, and their customers' personal data.
Your bio says you work at Intel. I'd bet a month's rent that there is a MITM proxy on your corporate network.
On the contrary. I think it's critical for businesses to protect customer data. Many customer data breaches are "someone left the S3 bucket open" or "someone had the database on an unencrypted laptop in their car" or "someone broke into the production database using a security hole we failed to patch". How many customer data breaches are "one of our employees intentionally leaked the customer database"?
The sign of a good security policy is that your employees are actively trying to help you. The sign of a bad "security" policy is pervasive word-of-mouth knowledge on how to bypass that "security" policy to get work done. Which network is more likely to experience a breach?
(I should also clarify that there's a difference between "policies for the corporate network" and "policies for direct access to the production datacenter network", as one of many examples. Lock that down to the point that you can't easily access it, and nobody can do so without oversight.)
> if you think companies don't have a right or desire to monitor the systems
Companies have a right and a desire to run ads, and yet adblockers exist, and generally speaking the adblockers win for anyone who installs one.
I see this isn't going anywhere - you didn't acknowledge that if you work at Intel, you 100% have a web proxy on your campus despite saying otherwise, and now you're comparing adblocking by a private user on their computer on their time, and someone accessing the internet from their company's network on their company's time when and uploading arbitrary data across the Internet.
Again, you make some good points interlaced with bad ones: Yes, limit desktop access to corporate servers. Have strong IAM and auditing. But you think there is some right to have all the privacy in the world on their machine on their time. I fundamentally disagree.
And would you, or whoever is doing it, stop downvoting me? Despite our disagreements, this has been a substantive argument.
> And would you, or whoever is doing it, stop downvoting me?
1) You can't downvote people who reply to you. 2) Discussions about downvotes are off-topic. 3) Downvoting to express disagreement is explicitly allowed.
No, my experience says you do.
The enterprise needs to prevent data breaches and data exfiltration. If you want them to move away from MITMing, then I believe you would fare better if you provided an alternative solution.
Further, unless you have some voodoo magic, preventing breaches and exfil, would still require inspecting something - whether it's at the OS, client, or data level. IOW: you are simply moving the inspection around from network to somewhere else - but it's still inspection - and invasion of the employee activities.
Exactly zero companies care about "protecting the outside world", MITM Boxes are required to have a record and scan all traffic going through your network. If PHI is exfiltrated we can't just tell the auditor "sorry ma'am we have no visibility into our network by design. Could have been from anywhere. shrug"
Why the hostility towards entities that have determined their best course of action to protect THEIR networks is by focusing on the network egress pipe? Simple and efficient to focus on one chokepoint vs patching a myriad of devices + client software + client versions + OS versions + future versions etc.
> It will become increasingly expensive to even try.
Go ahead, but you're increasingly unlikely to win that battle. There's bound to be some software or version that the enterprise cannot control (e.g. prevent data exfiltration) at which point, enterprises will have no solution but turn to SSL MITM again.
Remember, it's the enterprises' network and data - not yours.
Among many other reasons, because such entities repeatedly try to weaken Internet security standards and software to accommodate their expectations. That's an attack, and deserves an appropriate response.
Also, because today, everyone doesn't always have enough choices of potential employers that they can avoid such policies.
Also, because nobody should ever get used to the idea that their network is MITMing their traffic, not least of which because that normalizes such technologies on other networks and in other contexts.
Also, surveillance technologies like this will be abused by people with power over others; there's a long history of such abuse.
And those are just the reasons off the top of my head.
> Go ahead, you're increasingly unlikely to win that battle.
What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack? What happens when, even before that, companies that MITM have to replace cheap MITM infrastructure with incredibly expensive MITM infrastructure? What happens when software and services start treating the resulting decreasing percentage of companies that try to MITM the way they treat companies still running IE6, and tell them "you'll have to upgrade your network"? What happens when people trying to MITM find they can't run modern software stacks, and their auditors complain that they're not upgrading? What happens when they're spending huge amounts of money maintaining forks and patches? What happens when the engineers who would have to maintain those patches don't want to work on a hostile network, and the ones that remain are more expensive? There are many things people can do to make life difficult for anyone trying to MITM.
> nobody should ever get used to the idea that their network is MITMing their traffic
and:
> surveillance technologies like this will be abused by people with power over others
Then simply do not add a CA or self-signed cert to your cert store. IOW: the default is secure against SSL MITM. Nothing to "get used to" or "abused".
> What happens when libraries and software starts dropping support for old, insecure protocols, and the new protocols are designed to treat MITM as an attack?
Much simpler than you think. In an Enterprise, they block what they cannot inspect. Clients do not own+run the networks, the enterprise does.
> What happens when they're spending huge amounts of money maintaining forks and patches?
This runs counter to your earlier argument: "You can block spam and outbound attacks without MITMing traffic."
How do you control a myriad of versions of client software on a myriad of versions of devices across a myriad number of applications? There are bound to be some software the Enterprise cannot control (e.g. proprietary, or simply does not have the resources to fix+recompile).
Once upon a time, there were public CAs who would sell you a sub-CA certificate for use on a hardware MITM box, so that you could "transparently" MITM systems on a network without adding a CA. That is now considered unacceptable, and grounds for terminating a CA. What "security" practices in use today will we be saying "once upon a time" about years from now?
Can an industry not mature?
Previous behavior is not an indicator of the future - and anyone worried about it can contribute to scrutinizing CA's and their guidelines today.
Not sure pre-judging current actors based on past actions during a relative nascent industry gets us anywhere - especially since you still haven't provided an alternative solution for enterprises to prevent data breaches or data exfiltration WITHOUT inspection happening somewhere else other than the egress chokepoint.
There are SO many ways to exfiltrate data. The only way to control exfiltration with a chance of success greater than zero is to lock down all work devices (at the OS level, centrally managed) and prohibit outside devices including USB keys. Anything less is a joke.
Generally high loss is not well tolerated by internet protocols, so high loss networking technologies tend to handle forward error correction and retransmissions in protocol layers below IP.
How is it possible to be 1000x faster? Is it?
TCP works by slowing the data rate when data loss happens. On purpose, to be fair!
I think it's not that hard to write a program/protocl that blasts out a big file over UDP and just sends all the parts as packets, then waits for the receiver to assemble a big list of missing packets, send them back and have the sender blast out everything again at a high rate.
But this would be at the expense of all the other TCP connections.
Wasn't QUIC changed to be so called "TCP friendly", that means that it has the same back off behaviour as TCP so that if you are in a crowded hot spot every tcp stream has a fair chance?
(On the other site, google and some other companies have a huge initial TCP window size and try (or tried?) to send e.g. the whole google homepage with like 8 1500 byte packets at once, also trying to get a better ux than other, again on the expense of other TCP streams)
Looks like using Aspera is unfair and only works if a few people do it.
Since QUIC is also over UDP, perhaps we now have more flexibility on ACK windows etc.
Btw. there are open protocols like Tsunami UDP (https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol) that try to fill the same niche
> other than a masters thesis which suggests FASP outperforms on transferring large files over long distances
I found that one too. I would take it with a grain of salt since it uses scp for data transfer (which has its own flow control and may be the limiting factor here) and doesn't list the values of some important tcp settings, e.g. tcp_wmem, which can be essential for transoceanic connections.
¹ ignoring the case where a single CPU core can't move bytes fast enough to saturate a link.
I'm hopeful that the hard _requirement_ to have encryption will force better management and security.
†The correct way to proxy HTTPS is wire a client and server with your meddling code in between, your client negotiates a TLS connection to say https://news.ycombinator.com/ and it decides exactly what is sent and can see in plaintext exactly what's received. Users make TLS connections to your server and it presents them with a certificate it made, maybe claiming to be news.ycombinator.com and signed by My Corp Monkey Proxy then passes through some requests to the client we described.
But it's much cheaper not to do this, and all of the other things you might do to achieve the same goal are insecure or break the protocol or both. So there's a big financial incentive to destroy security, while often ironically claiming to be improving security e.g. anti-phishing. For example choosing random number is hard yet at the same time essential for security - so several major vendors sold products that just didn't. When they turned A->B into A->M->B with their product as M, they'd just re-use the random numbers from the other conversation in the pair. This had been destroying security for all their customers for years, but we only found out they were doing it because it broke with TLS 1.3 final.
Specifically when a TLS 1.3 server (but not draft versions for important compatibility reasons) talks to a client that doesn't agree to TLS 1.3 it scribbles the letters "DOWNGRD" over part of the random number field. Since the client supposedly doesn't know TLS 1.3 it shouldn't care, DOWNGRD is a ludicrously unlikely "random" choice but so is "FCKTRMP" or "KICKASS" and those don't mean anything in older TLS versions either. But if the client really does speak TLS 1.3 and has somehow been tricked into negotiating an old version, this weird choice of "random" number signals it's a trick and it will disconnect.
The affected "proxies" would tell a nice shiny new Chrome or Firefox (which can speak TLS 1.3 and thus are looking out for DOWNGRD) that they only knew TLS 1.2, fair enough. And they'd tell servers, say www.google.com, the same thing. But the TLS 1.3 capable servers would scribble DOWNGRD into their random number field, and then because these "proxies" weren't actually assembled from a separate client and server but just re-used all the numbers, the DOWNGRD gets copied into data received in Chrome, and it disconnects because it has seemingly detected an active attack.
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs... actually compares them!
If you don't care about initial startup time and FEC you might see zero difference.
Is it possible to only encrypt the QUIC headers but leave the data unmodified? That idea just popped into my head and I'm not sure it makes any sense, but maybe that would provide the best of both worlds.
Also TLS was selected because of regulations. Which is damning to say the least.
I would like to read more about this. Link?
FWIW though, TLS 1.3 (the only currently supported TLS in QUIC, AFAIK) is a lot less hairy than TLS 1.2 and earlier; and most of the primitives are the same as you would use for noise (i.e. standard AEADs like ChaCha20-Poly1305).
Sure support is good but so is PGP’s
Of course such proofs come with caveats - in particular the proofs assume your cryptographic primitives work as intended (e.g. that AES isn't broken) and that you've implemented the specification and not something else - but our experience has been that it's valuable to get those proofs, and where proof turns out to be difficult it's a valuable pointer to weaknesses in your design.
As far as I know nobody has done such a proof for the Noise design, and so we only have our intuition that it looks safe.
Also I may be wrong again, but it is for TLS, that even with all the simplifications and major changes on TLS 1.3, that we only have proofs of correctness for certain subsets of the spec, and specific modes of operation (theres a version of the protocol targeting IoT for which this work has been done, but I can't remember the name)
There are legitimate use cases for "running naked", but now we're doomed to jerry-rigging some BS ephemeral self-signed certificates in order to use any QUIC client that follows the official spec.
The problem is similar to the IPv6 transition, except thanks to the browser monopolies, it's possible at least for network providers to quickly feel significant pressure to fix their networks. But there will always be some networks that will never be fixed
edit: for those inexplicably downvoting this, please pay attention to the parent comment's question, and the Internet's long chequered history of adopting new protocols in any setting. TCP port 443 isn't going to magically disappear overnight, or indeed any time soon. This is evidently true because it has been true for all prior transitions. Mail still flows to many places unencrypted despite the standardization of STARTTLS 21 years ago. The long tail has only gotten much longer in those intervening 21 years.
I thought the primary appeal of HTTP/3 is for mobile clients, and bad connections in general, because it circumvents TCP head of line blocking and connections can persist across networks.
That doesn't feel terribly relevant in corporate networks.
(not disputing that it's not comparable to the v6 transition)
Enterprises largely won't give two shits about HTTP/3.
Just last week I took ownership of another department's decade old app written in VB.NET WinForms. The former dev team was putting the finishing touches on the C# WebForms refactor. It's been interesting taking a step back in time to Dev practices from 2008.
More availability of HTTP version gateways in load balancers and other reverse proxies is all that's needed, and that's coming along.
Increasingly "corporations" out-source this problem to specialists who are only too pleased to use newer technologies with better performance and collect the same money.
The application servers running the site do not accept HTTP/2 and most likely can't support it at all (we're a python shop and none of the web frameworks we use could do HTTP/2 when we looked into it).
But for companies like CloudFlare or Googl HTTP/2 means less traffic overhead (multiplexing+header compression) and can save them a lot of bandwidth (aka. money) with that.
As a motivational example, it is possible to encode a colon in a header name in http2 but not in http1.1, and this does not violate the RFC which only blacklists "\0\r\n".
HTTP/3 and QUIC are based on UDP. This is very different to the IPv6 transition.
Some broadband ISPs struggle with the fact that their customers get compromised and join botnets. Over the last few years UDP has become the ddos attack of choice. Broadband access networks struggle with how to mitigate this. Some try to block the command and control (C2) and some try to go the customer outreach angle. For example, notifying them that they have a compromised machine or putting them in a walled garden with a website that pops up telling them they've been impacted. The problem is that outreach is costly and not super effective. So they found another option: apply throttles on UDP. A few have done this and it's led to big problems because from a user experience QUIC works enough - and then falls apart.
Some of the access providers have changed the throttles to be less aggressive while others have resorted to being aggressive on the topic ("you should have made a new protocol and consulted with us!").
Maybe similar but much smaller then IpV6 with much less problems, because most web frameworks will transparently support HTTP/1, HTTP/2 and HTTP/3 for the large majority of use-cases.
> Mail still flows to many places unencrypted
Mainly because getting a TLS certificate wasn't that easier for a lot of people in the world until recent years and the standard being written in a way which can be easily (mis-) understood as you having to have support unencrypted sending/receiving of mails. (It requires it for sending for local, i.e. implicitly by OS user account authenticated same machine mail.).
There won't be a pure HTTP/3 service anyway. HTTP/3 requires negotiation. It is announced from a previous HTTP/1.1 or /2 request using a "Alt-Svc" header. Typical clients will not try to connect using HTTP/3 directly
Iirc it introduces use of UDP and thus will be unusable on a million corporate networks where near all UDP-traffic is filtered.
That is: any network that is capable of handling traditional HTTP is capable of handling HTTP/3, but many are explicitly configured to not do so.
But really the idea of the protocol being transparent to the network is completely backwards in relation to the main idea of the Internet, namely the end-to-end principle, which says that the network is dumb and is not allowed to look inside the IP packets into the higher level protocols.
In a parallel universe: https://tools.ietf.org/html/draft-natarajan-http-over-sctp-0... It might be that http 4 experiment this
IMO, it's a "good thing" for applications (or types of application) to have control over the Transmission Layer since the characteristics that each type of application might desire is different. Want your app to use raw UDP sockets? Easy. Want to use QUIC? Use a QUIC library. HTTP/3? Use and HTTP/3 library.
If it all used SCTP, you are locked in to its feature set and are likely to end up with new problems similar to what we see with TCP.
I could possibly UDP/QUIC taking over TCP in a long, long while, but SCTP is not likely to ever be usefully supported because there isn't a compelling reason to do it.