Comment by superkuh | Hacker News Reader

Comment by superkuh | Hacker News Reader

TCP also supports allowing people you've never met to connect to your IP without you getting the permission of a third party first and regularly. QUIC requires continued permission being allowed by some third party corporation. Baking the requirement for CA TLS into the protocol is fine for corporate uses but the internet is far more than just corporate uses.

Sure QUIC may be faster, but only as long as you keep getting permission from your TLS CA. Once that stops it's very, very, slow. QUIC is fragile and like other CA TLS things: anything built with it will have a lifetime of only a few years without being updated.

Do we really want to base our web protocol (and other things) on a system that will only allow machines updated in the last $fewyears to participate?

Additionally, the claims of the use rate for the various HTTP versions is flawed in that it is not going per webserver or domain, but instead just counting traffic and of course the megacorp flows it knows about will dominate (they're not checking every webserver). Looking where the light is fallacy.

> Sure QUIC may be faster, but only as long as you keep getting permission from your TLS CA. Once that stops it's very, very, slow. QUIC is fragile and like other CA TLS things: anything built with it will have a lifetime of only a few years without being updated.

For me, letsencrypt has been set-and-forget for at least 5 years. I use it with nginx, which is in front of several servers including a Jetty 5 server. Jetty 6 was released in 2006. You can configure which CAs you trust as well, so TLS isn't really any more of a centralization problem than DNS is.

What did you do when acme1 was deprecated (for acme2) and stopped working with LetsEncrypt? That certainly required changes in your setup that would break otherwise. How did you handle the expiration of the LE root cert? Maybe can still access your TLS wrapped site but people using an RSS reader who's cert store was set up in 2019 can't. All these things, both on your side and the client side apply very, very broadly. It may work for you from your setup but I can assure you that isn't universal or even normal.

I love LE and I think it's the least worst solution. But mandating CA TLS into a protocol is very bad for human use cases. HTTP+HTTPS prevents this fragility. HTTP/3 with it baked in is fragile.

Also, you don't need DNS to communicate with an IP.

I didn't even know about the acme1 deprecation until you just now told me. Apparently certbot 0.31.0 handled it fine.

You're right that DNS isn't architecturally analogous to TLS. The way it's analogous is that if the central infrastructure goes away, then people have to do something more technical than usual to get things working again. Yes, using an IP address string in place of a hostname is simpler than setting up an alternate CA, but broadly it's the same idea, a centralized dependency with an inconvenient workaround.

>certbot

I'm not surprised the flagship certbot automagically handled the deprecation since you apparently consistently update it. But many setups, especially those without auto-updates and other moving parts, just stopped working. And certbot would've too if you hadn't have made sure it was up to date. And some acme clients never supported 2 and just died. It will happen again.

>a centralized dependency with an inconvenient workaround.

Except there's no workaround with QUIC based HTTP/3 because all the libs people use come without the flags to allow self signed certs. So 99% of browsers/HTTP using software released is stuck with CA TLS or no communication at all.

It doesn't matter if you set up a custom CA for internal use or if you enable it in your custom http/3 lib build of your custom build of $browser. People still won't be able to visit your hosted HTTP/3 site with your custom CA. Not without you installing your root cert in the browser or system cert store of most people on Earth. That seems unlikely to happen.

Reply on news.ycombinator.com