It is a layering violation though. Not all HTTP usage is through a browser, and not all routes go over the plaintext Internet. Browsers or clients can still require HTTPS at the application layer, but it shouldn't be part of the protocol spec.

Suppose I have an app within an intranet that's secured with, say, Wireguard or an application-layer tunnel (eg, SSH or Openziti).

Bringing HTTP/3 into the picture means dealing with CAs and certs on top of the provisioning I've already done for my lower layers, possibly leaking information via Certificate Transparency logs. Then the cost of double-encryption, etc.

I agree that sending cleartext over the internet in this day and age is a bad idea. But "encrypt all communication at the application layer" doesn't have to be the only solution. There's also "encrypt communication at the <i>network</i> layer," as discussed here for example: https://tailscale.com/blog/remembering-the-lan/

I have a suspicion that this will prove to be a better abstraction than application-level encryption for everything. If I'm right, I would expect things to naturally start migrating in that direction over time. We'll see!

Thinking that social issues can't and should not shape technical discussions, even more when talking about one of the most important technological platforms for society is rather limited and short sighted.

> If free issuance of certificates falters, the internet as we know it is in serious trouble. Deal with it. Social factors. This might conceivably happen, and if it does, HTTP/1 will not save you.

This (HTTP/1 won't save us) doesn't seem entirely accurate to me.

I can run free, untrusted HTTPS easily using self-issued certificates. It's relatively simple to think of mechanisms where trust can be layered on top of that outside the traditional CA mechanisms (think Keybase derivatives like DID-systems). It's a small patch to allow that alternative trust framework to be used for HTTPS.

I don't know HTTP/3 at all, but if it is more tightly tied to CA infrastructure that is a problem.

>Look, be real: the entire web is now built heavily on the CA model.

No. You've just got your commercial blinders on. The entire *commercial web* is built on the CA model. But the commercial web is hardly all there is. There is a giant web of actual websites run by human persons out there that do not depend on CA TLS and who's use cases do not require dropping clear text connections. That's only a need for for-profit businesses and institutions.

I agree that the mega-corp browsers will drop support for any protocol that does not generate them profit. The consequences of this action will be dire for everyone. But you can't convince people of this. You just have to let it happen and let people learn from the pain. Just like with the social networks.

As others said, is a layering violation. What that commandment means in practice? Essentially, you can't just udp your way around the protocol, and do frame comparison to test robustness of the protocol, you have to care how it looks like when encrypted. And you now need to use a subset of the TLS spec which most widely used implementations in the wild consider private API. So most QUIC implementations are built on some broken fork of openssl. This leads to fewer implementations, which means concentration of power (spec is not king, the implementations rule the protocol) and narrower attack surface for exploiters. And we all lose.