I know there's a big barrier to entry for being a CA (as there should be), but it shouldn't be impossible.
> While TLS 1.3 can still run independently on top of TCP, QUIC instead sort of encapsulates TLS 1.3. Put differently, there is no way to use QUIC without TLS; QUIC (and, by extension, HTTP/3) is always fully encrypted.
Basically there is no HTTP/3 without a TLS certificate.
I'm not sure what "problems that might arise from centralization" might be. There are many different TLS certificate providers from different CA roots.
Is your gripe that you don't like TLS? Judging by how long the migration from TLS 1.1 to 1.2 took, I assume we're at least 10-15 years away from a world where everything is encrypted by default without backwards compatibility (if we ever get there at all).
I'm flabberghasted that that's what you took away from my comments. I thought I was very clear. My issue is the lack of HTTP support in HTTP/3 implementations shipped by the mega-corps (CA HTTPS only). CA TLS is definitely the least worst solution we have and I am not against it. I am saying major browsers' HTTP/3 implementations lack of bare HTTP support in HTTP/3, combined with short TLS cert lifetimes these days, is effectively attestation and that's bad. "Basically there is no HTTP/3 without a TLS certificate." is bad.
It could be slightly mitigated by the mega-corp implementations of HTTP/3 they ship accepting non-CA root based self-signed certs with a scaremongering click-through. But that's also no longer an option. If no company running a CA will give you a cert you'll simply be unvisitable (on HTTP/3). It makes the web something only for commercially approved sites.
This isn't technically correct. I believe on the security warning page you can type "thisisunsafe" (just blindly do it) and it'll let you through.
At the very least this works for bypassing HSTS.
I agree with you on the necessity of maintaining support for bare HTTP in the Web ecosystem. But I think you’re not likely to get as much support on this, simply because far fewer people run servers than clients.
I kind of doubt that clients will ever connect exclusively via HTTP/3. I think browsers keep bare HTTP support. Maybe at some point it may be hidden behind a client config flag.
1. The only things that WebPKI CAs are required to attest to is that domain validation was properly completed and that the private key is not compromised. The system is designed (in both intent and practice) for any website to be able to easily get a certificate, and even the most untrustworthy, undesirable websites can and do get certificates on the regular. In contrast, Google's remote attestation proposal is clearly intended to assess the trustworthiness/desirability of the client.
2. The TLS requirement imposes a burden on website operators but provides a clear benefit for end users, which is totally in line with the Internet's Priority of Constituencies[1]. In contrast, Google's attestation proposal places a burden on end uses for the benefit of website operators, which violates the Priority of Constituencies.
Additionally, I must note that Firefox also requires a TLS certificate for HTTP/3 (as they did for HTTP/2). Not sure why you'd omit Mozilla from your list of browser makers doing this, but it's a misrepresentation to imply that this is something only "mega-corp browsers" do, when there is actually broad agreement that this is a good thing.
This seems like a such a wrong headed approach. LetsEncrypt favors constantly changing magic handshakes over long term good social behavior.
Imagine a network where machines that misbehaved were ostracised instead of being able to register certificates frequently.
I see the promise in the Fediverse as it's ability to develop reputations.
You don't based on your threat model. Other people have other threat models. I don't want potentially tampered/malicious content/JavaScript hitting my browser, I can also simply not visit your site. Such a simplification can not be made on the wide (and hostile) web. TLS is trivial enough to be the norm.
We can also draw parallels with food safety. Feel free to cook whatever you wish however you wish at your own home. If you want to offer it to people passing by on the street you have to follow food safety rules.
Attestation is at best a transient side effect of proving your ownership/control of a domain name...
There's perhaps better ways for you to articulate this point I think you are trying to make of "closed club" of Certificate Authorities.
That said a basic google search demolishes that point with there being alternatives to LE.
Also bemoaning the 90 day period seems really weird.
That's a pretty good set of organisations when considering the general status of the internet, and a set that doesn't overlap with the major players in consumer technology (Apple, Microsoft and Google).
But this only becomes a serious problem when HTTP/1.1 support is removed. Mozilla will never remove HTTP/1.1 support from Firefox. Google/Microsoft/Apple are chomping at the bit to remove HTTP/1.1 from their products.
[1] https://blog.mozilla.org/security/2015/04/30/deprecating-non...
re: HTTP/2, yes, everyone is well aware it didn't allow HTTP connections from the start. But there was no risk of HTTP/1.1 going away at that time. And you can technically still use a non-CA self signed cert for the implementations of HTTP/2 in major browsers. But it is also a bad protocol like HTTP/3.
I have no idea what conspiracy theory stuff you're going on about. People just haven't thought through the consequences of these design decisions outside of their work headspace bubble. Much like with WEI.