So there is already stapling options for OCSP Responses and Certificate Transparency data (although I expect CT to be embedded in most certs by now rather than being stapled to the TLS response), so couldnt it be possible to also staple the entire TLSA path to a TLS response in order to maybe get an alternative to the absolutely crazy CA System?
I mean for real do we really need to trust more than 150 entities for every connection? I personally think that in a space where clearly DV certificates are the most abundant because OV certificates dont show any difference at all for HTTPS in browsers and EV certificates are on their way to hopefully, finally die in a few years after browsers decided to not give EV certs any favored treatment on the main UI anymore, and EVs have been proven time and time and time again to have sloppy verification practices, arbitrary revocation policies as well as enough technical issues and the reliance on the user to even notice them.
And that's aside from the ads throwing things that are objectively false, like making EV certs about lookinh more trustworthy and whatnot despite those LITERALLY being an excluded purpose for EVs.
The only purpose EVs really have that there has been a REALLY deep validation that you are REALLY comnunicating with a certain legal entity, even if that's some real scammer, in the same manner HTTPS on its own makes sure you have a private communication with a given website. One of the most important things to know on HTTPS is this awesome quote:
So if EV is practically dead, OV is irrelevant, what reason is there to keep DV on CAs, which can easily betray one as all CAs are trusted all the time. with TLSA you already are demonstrating control over the domain well enough, so there really is no long term need for most CAs to exist, the biggest annoyance tho is having to get more data from DNS to verify the assertions TLSA makes. and having a way to just bring that data along as part of the TLS Response from the server would simplify that a LOT.
With DNSSec you only have 3 primary points of trust.
- The Root (the IANA/ICANN, who have their Root Key Ceremonies HEAVILY audited and on public record)
- The actual domain (the site owner, for example me for this blog)
Sure the TLDs registry (like denic for .de domains or the Google Registry for .dev) registrar (in my case domainname.shop), hoster (in my case netcup) etc also need to be trusted but that's more a secondary thing and something the site owner has to worry about as the owner has full control over that. On the other hand the "primary" trust elements dont get their trust from the owner but the user or implicitly via their browser/DNS Server, etc. and having over 150 CAs the site owner cannot really have any control about in relation to trust.
I mean when DNSSec became a bit more well-known out some haters were raving about Gaddafi being able to control bit.ly including a response saying that with the CAs there wouldnt have been the possibility to get certificates for it. however quite the contrary, when you control the TLD already, you can easily take over control of the domain, demonstrate that you do have that control and get a DV cert no problem.
In the end this just shows to choose your TLD wisely and not just because it looks cool but to also take a look at some of the details for it. many "cool sounding" domains are from interesting places which also have interesting history regarding the TLDs, despite being used for more general purpose, like .io being from the British Indian Ocean Territory, or .tv being Tuvalu, which could be in fact be removed if Tuvalu would end to exist, e.g. due to the island
sinking and becoming another Atlantis, getting below sea level due to the rise of it.