3 ms·

> 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 oth

> 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.

superkuh 3y ago
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.
- brlewis 3y ago
  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.
  - superkuh 3y ago
    >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.

superkuh 3y ago

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.

brlewis 3y ago
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.
- superkuh 3y ago
  >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.