[0xbadcafebee]

Yes this is to be expected. I've mentioned multiple times over the years that TLS CA issuance & validation's many security holes (>=14 at last count) could be solved by changing how certificates are issued. I've never had the kind of clout to get that message wide enough that anyone would take it serious.

One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.

The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.

Maybe if this keeps happening, people will realize it's worth working on? But I doubt it, as a lot of money is at stake, and nobody wants to risk that just to stop governments and cybercriminals from spying on the occasional connection. If it was blatant and obvious then they might have to act; as long as it's kept covert and hard to prove, things stay the same.

[cyphar]

> One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.

In case you were not aware, Moxie Marlinspike spoke about this at length back in the early 2010s[1]. His view was that the problem is that certificate authority trust is controlled by the wrong people (web hosts, not users -- or browsers, as a proxy for user wishes) and is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.

> The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.

Unfortunately, this is problematic for a bunch of other reasons. Yes, this means that a classic Comodo or DigiNotar attack might be blocked (though it is also just as likely they would've been included on the allow-list for American websites), but it also means that registrars could force you to use VeriSign and you would have no choice in the matter -- that is what originally happened with TLS and was what originally happened with DNSSEC too. It seems prudent to me to avoid creating schemes that allow that kind of institutional capture.

There is also in my view a mistake to assume that anyone with a ".com" or ".us" address would want to have the US government decide who they can get certificates from, ditto for any national TLD (let's not forget all of the Rust projects with ".rs" which is controlled by Serbia, tech websites with ".io" that is controlled by the UK, and so on).

If you really wanted to do this, DANE would allow website owners to do this by pinning the CA root and intermediate certificates hashes via DNSSEC -- basically acting as a client-side (and more strict) version of CAA (which I'm guessing is what you were referring to in your comment). Unfortunately it's not supported by Chrome and Firefox, and it would be quite fragile. It would be nice to have this as an option, and I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.

[1]: https://youtu.be/UawS3_iuHoA?t=292

[masfuerte]

You seem to be talking about registries (who manage tlds, so you have no choice for a particular tld). OP talked about registrars (who sell domains, and there's a wide choice). Though I'm not sure how that's supposed to work.

[leonidasrup]

Who should decide that the assignment domain name -> public key is valid?

Certificate authorities?

Domain registrars?

Both of them are subject to government control and regulation and as such Web PKI provides normal commercial level of security, it doesn't protect from government agencies.

To protect from government agencies we would need to move from addressing web pages using domain names to addressing web pages using public keys. This is hard because of Zooko's triangle.

https://en.wikipedia.org/wiki/Zookos_triangle

[0xbadcafebee]

> once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.

If you switched CAs you would only need to trust the old one until the previous cert expired, or when you get a newer cert. Once the cert expires there's no point in trusting the old CA - for that domain. (In my solution you still keep all the CAs in your cert store, but they can't validate a cert that wasn't also signed by the domain owner's and registrar's keys)

> it also means that registrars could force you to use VeriSign

The check on that is the combination of the CA/Browser Forum and ICANN. The CA/Browser Forum is a proxy for Google, Apple and Microsoft, who control the browser market, and ICANN who controls the accreditation of domain registrars. A single registrar has a lot less money and influence today than back in the day.

> would want to have the US government decide who they can get certificates from

Because of the aforementioned bodies I don't believe registrars would be allowed to enforce specific CAs (architecturally they would just be signing requests on a REST API based on the CA keys the domain owner authorized, so there's no need to integrate into specific CAs). I also think CA/Browser Forum would want to enable Let's Encrypt to be used everywhere (LE usage is in the interest of the CA/Browser Forum) so that would mean they need rules to allow CAs independent of registrars.

DANE and DNSSEC are not a good solution architecturally or security-wise. DANE is duct tape; duct tape is a temporary fix, not a permanent one.

[tptacek]

I think a lot of people who work on the root programs would push back on the idea that the CAB Forum is a proxy for Google, Apple, and Microsoft.

[0xbadcafebee]

They control the OS and the Browser, the two things that specify what CA certs can be validated and how. CAs can disagree all they want, but they can't do anything about it. The big 3 don't want to be in the CA business, so they haggle over rules, but it's not a level playing field

[tptacek]

Oh, I agree about their market power, just saying CAB is complicated.

[tialaramex]

> is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever

So, the fun thing about historical claims is that you can do Science (insert sound effect) by assuming they're right to make a prediction from that baseline and comparing what actually happened against that prediction.

Moxie gave that talk in August 2010, hence the "DEF CON 19" background. So almost 16 years ago. Over that time of course there have been numerous incidents that would give you good cause to distrust companies such as DigiNotar, StartCom and Symantec. Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.

> I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.

This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.

[cyphar]

> Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.

Yes, he did say "forever" and (to borrow a phrase) nothing lasts forever so you do have a point there. But the original point still does stand, even in the modern world with a very active CAB, do you honestly think they would blacklist Lets Encrypt if they had some hack or violated some CAB policy that would normally result in expulsion? The fact that trust decisions are very hard to revoke (even though it is possible in practice) is still a problem with the design of PKI.

(It's also a little funny you didn't mention Comodo -- they are still kicking around, despite their history.)

> This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.

Yes, because that usage was the intended usage that is how the scheme must be interpreted. But that doesn't mean that it couldn't have been made to be interpreted differently -- in our modern world of short-lived certificates it would've been very easy to tweak it so that it would've allowed you to specify historical CAs during the (short) transition period.

The issue with CAA is that (as formulated) it is an incredibly weak protection mechanism -- it relies on CAs to obey it and if a CA gets hacked (or forced via legal threats) there is no mechanism for users to be protected from them issuing certificates for sites that did not wish for that. Google is well aware of this issue, which is why Chrome has proper CA certificate pinning but only for Google-owned domains. Non-Google website owners have no access to a similar mechanism, and even if CAA was not as good as some theoretical alternative, for the vast majority of websites it would be a strict improvement if clients validated against CAA -- which is why I'm disappointed that it is explicitly not permitted with MUST NOT (not even a SHOULD NOT -- which is a stance I would understand).

[tialaramex]

I'm not sure you could consider Let's Encrypt "too big to fail" but if you can it seems like Moxie's position doesn't help? The "too big to fail" afflicts basically everybody in that case.

Comodo / Sectigo is actually useful to illustrate how these decisions are made because we actually care whether you can stop having problems. Think like air safety or medical safety. Things go wrong, our job is to avoid scenarios where they keep going wrong for the same reasons. The first guy who trips and plummets off a bridge into the river below is enough, OK, yeah, barriers, we need to prevent you accidentally falling off the bridge. When you build the next bridge and somebody falls off because you didn't add barriers now that's a failure to learn and do better.

Outfits like StartCom and Symantec the problem wasn't "A thing went wrong" it was "Things kept going wrong and either you lied to us about preventing them, or you're incompetent and your attempts failed utterly". There are a lot of boring "Brown M&M" record keeping steps, and for WoSign and Symantec the evidence available strongly suggested they were deliberately lying to us, but even if they weren't lying they were spectacularly incompetent, and that's not OK. As I've explained previously I strongly prefer to not care whether you're incompetent or lying, I want either explanation to have the same consequences.

If we thought there was a problem with Let's Encrypt and it must be distrusted I think a transition plan like for Symantec is a lot more plausible than the sort of "Everybody makes their own correct decisions" fantasy Moxie promoted which, frankly, I think sounds like Libertarian claptrap. Such an approach requires that almost everybody cares and that's just not true about anything at all.

> But that doesn't mean that it couldn't have been made to be interpreted differently

But now you're talking about a different protocol. Feel free to go design your own protocol, like Moxie's. I doubt yours will fare better than his did, but "Why didn't everybody else focus on my preferences?" is silly.

[account42]

If you're using the DNS as the root of trust then you can just skip CAs entirely and have the DNS system authenticate certificates directly. Turns out we already built system.

[mtucker502]

How would clients receive the trusted CA data from the registrar? DNS?

This would very easily be susceptible to MITM attacks. Any DNS security to prevent MITM attacks is going to have the same CA issue we currently have.

[account42]

DNSSEC is a thing you know. And not it doesn't allow a random Chinese agency sign records for my .de domain.

[tptacek]

You mean until major DNS providers turn DNSSEC off for .DE to work around misconfigurations, which literally just happened.

[account42]

Operators making reckless choices like that, especially when DNSSEC is barely being used, does not invalidate the technology. And it would also not have impacted DNSSEC used for DANE as the client would be verifying the DNSSEC chain in that case and not just the recursive resolver. But don't let that stop your eternal butthurt about DNSSEC. Whatever issues DNSSEC might have, at least its not broken by design like the current web PKI where we have hundreds single point of failures.

[tptacek]

The "operators" you're referring to are the .DE TLD operators, right?

[skybrian]

If the wrong CA issued a certificate then wouldn’t that show up in the transparency logs? It seems like by monitoring them, you could see if a security bug is being exploited.