See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation.
I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar. It would eliminate the frankly unnecessary trust we put in all root CAs and their sub-CAs to behave. (Well, at least CT logs are becoming a thing now)
It would also eliminate today's more or less awkward validation routines that depend on third parties querying DNS/HTTP/whois-email addresses. The registry has the definite database, mapping the domain to your account at your registrar, anyways. They should simply have a public key upload button next to your domain name in your registrar's domain name control panel that immediately returns an appropriate certificate, no further validation needed :)
> See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation.
I think the CAB rules require respecting CAA records? If a CA gets caught on that, they'll have some amount of hell to pay.
Client software can't go back in time to verify what the CAA records were at the time the certificate was issued. CAA records are not intended as a means to revoke previously issued certificates, only an indication of which CAs are _currently_ allowed to issue new certificates.
That said, I agree with you, but the general consensus doesn't seem to, that we de facto trust registries/registrars as stewards of domain ownership, so we may as well de jure make them CAs, since they already have an account relationship.
I found your last paragraph especially well phrased!
You're also on point regarding the CAA records. But to me the current system still feels too reactionary. I'd love to see a system where we need to put less trust in all third parties playing by the rules pinkie-promise. Diginotar, StartSSL and Symantec are all examples of CAs gone wild, and I think we've just seen the tip of the iceberg yet.
The CA/B mailing list can't do much about shady behaviour they don't know anything about.
I do trust in Mozilla to ensure that the game rules for CAs are strict enough that my trust in the green lock isn't 0. It's not 100% either but it's above 50%. When I connect to a website and it has SSL, I'm fairly certain it's the right place.
Most likely there will never be a replacement for it, any PKI requires some third party to vouch for an endpoint otherwise you get easy MitM (I believe there is a proof floating around somewhere from the area of Signal Theory).
"They should have a public key upload button next to your domain name in your registrars domain name control panel..."
What about putting the public key in a subdomain.
DNSCurve uses this approach to encrypt DNS packets.
If an authoritative nameserver for a domain can manage encryption of DNS packets without SSL/TLS, x509 and a CA system, is there any reason why an httpd could not do the same?
Management is handled by a "forwarder" daemon that is placed between the nameserver or httpd and the internet.
IMO, much less complex than SSL/TLS, x509 and commercial CAs and control over encryption does not require third parties.
Can you trust that the other end of the DNSCurve system is not operated by Mr. Evil? Can you do that automatically, ie, without human intervention at all?
The CA-based PKI system allows one to trust that the endpoint of a website is who they say they are and not a middlebox manipulating traffic. Additionally guarantees are available through EV certificates which also tell you who is operating the endpoint.
DNSCurvse is most likely not able to assure you that the response you got is really from the authorative nameserver. It can only tell you that it was encrypted but there is no identity assurance.
"Can you do that automatically, ie, without human intervention at all?"
Why not use something like SSH authentication keys to verify the endpoint? (e.g. ed25519 which can be generated very fast)
Consider the vast number of endpoints that are now currently being verified using authentication keys.
For something like encryption, I believe some human intervention will always be required. Only a human can answer the question: "Do you trust this?"
The issue is which humans are intervening: (a) the humans at each endpoint, or (b) the humans at each endpoint plus third parties.
Letting the www commercial CA vendors and commercial ad-supported www browser authors answer the question "Do you trust this?" on behalf of users is still human intervention.
Unfortunately for users, this is delegating the intervention to humans that have no "skin in the game". The third parties are not the ones with the need to encrypt. They stand nothing to lose if the encryption is defeated.
Common sense suggests this is the wrong approach. (And that's ignoring the ever-increasing number of exposed flaws and "incidents" regarding www commercial CAs, like the one being discussed in this thread.)
SSH authentication is TOFU, trust on first use. The user will be asked to confirm if the endpoint is legit.
But the average user has no idea if the website saying it's paypal really is paypal. Could be payscam instead, operated by Mr. Untrustworthy, AZ.
SSH works because the servers and endpoints you connect to are usually endpoints the user has setup themselves and are in the local area network.
>Unfortunately for users, this is delegating the intervention to humans that have no "skin in the game".
CA's do have skin in the game. If they fuck it up too often nobody will trust them anymore to verify trust. See: StartSSL, Symantec and soon Trustico.
If the encryption is defeated then the CA's entire business model collapses. The CA's have strong incentives to not fuck it up or not get caught doing so.
With Certificate Transparency we have tools to catch anyone trying to not get caught cheating.
>Common sense suggests this is the wrong approach. (And that's ignoring the ever-increasing number of exposed flaws and "incidents" regarding www commercial CAs, like the one being discussed in this thread.)
To verify the key of a endpoint you either have to decide yourself if it is trustworthy or rely on a third party.
If you don't verify with a third party and you don't ask the user if the connection is okay, MitM is trivial.
If you ask the user, social engineering can make MitM trivial.
A third party will be required in some way, be it a CA or the Web of Trust or something else. However, the CA model has been the only one that successfully operated at this scale. The WoT has largely degraded to TOFU for 90% of users.
> I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar
Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.
Maybe, but today's DV PKI is already trusting DNS 100%, since certificates are issued based on using DNS responses to validate the certificate request. If you don't trust the governing body of a specific ccTLD, for example, you are already worse off today - a hostile ccTLD DNS operator could very well arrange to fake DNS responses for the duration of a certificate request?
Maybe it's not so bad to make it more obvious what a fancy .ly or .lol TLD really stands for?
Even non DV PKI uses a lot of trust of the DNS. Where I work, I got our first non-DV certificate issued, and while the CA verified our organization exists (and made our certs show the city listed in our corporation filing instead of the city I wanted to show), the only reason they issued certificates to me is because I did essentially Domain Validation for the domain.
Yep, it's a race to the bottom for CAs to perform the absolute minimum work necessary, because otherwise competitors come in and make things easier for customers. Paying a premium for the services of a stricter CA currently has no benefits, since end-users have no way to evaluate whether a certificate is legitimate vs sloppily or maliciously issued by a different CA.
Funny thing about ccTLDs are that end-users might actually have some sort of opinion one way or the other about their trustworthyness, foreign or not. At least a tld is somewhat more visible and relatable in URLs compared to unfamiliar CA company names.
"it's a race to the bottom for CAs to perform the absolute minimum work necessary"
I can assure you that we, Let's Encrypt, are not doing the minimum. We are headed in quite the opposite direction. It's not easy to keep things simple while improving security but it can be done.
Sorry, I was mostly having the various commercial EV services in mind for that comment. Thanks for all the great work your team seems to be consistently doing!
