[e12e]

I think the author is a little disingenuous with the term "security theatre". Basically he argues that OCSP doesn't work because hard fail might cause DOS -- but fails to conclude that without OCSP SSL/TLS is useless. It's a long argument for saying that the CA system is broken (you can only trust the white-list chrome provides) -- and the sensible conclusion is that you cannot trust any other certificate chains (without OCSP) is left out.

Without certificates, SSL/TLS falls apart.

Perhaps a better use of CAs would be to always delegate authority to the domain owner -- we'd only need OCSP for the CAs, and domain owners could issue hour/day-valid certs via a cert infrastructure. That would push a lot of complexity down to domain owners, it would probably lead to a lot of errors in implementation -- but those errors would only affect the domains -- not the main CA trust chain as such.

I'm not sure if that would be an improvement or not -- but at least you could know that if a domain was run correctly, a valid certificate could actually be trusted...

[dvanduzer]

The "better use of CAs" you describe is essentially DNSSEC.

[tptacek]

Sure, if "making the DNS totally unreliable", "baking 1990s crypto into the core of the Internet", and "conceding the CA PKI to world governments" is your idea of "better use of CAs".

[dfc]

  > "conceding the CA PKI to world governments" is your idea of "better use of CAs".

How much different is this than the current CA situation? Just recently a subordinate CA of ANSSI (the French Network and Information Security Agency) issued a wildcard cert that could MITM just about anything.[^1] Firefox's list of trusted CAs includes:[^2]

  China Internet Network Information Center (CNNIC)
  Government of France
  Government of Hong Kong (SAR), Hongkong Post
  Government of Japan, Ministry of Internal Affairs and Communications
  Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
  Government of Spain (CAV), Izenpe S.A.
  Government of The Netherlands, PKIoverheid
  Government of Taiwan, Government Root Certification Authority (GRCA)
  Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)    
  Hong Kong

Firefox's list of pending CAs includes additional government CAs.[^3] Things are no different in Redmond. There are at least 56 government CAs (56 of the certs start with government probably others with less obvious names) in Microsoft's Root Certificate Program.[^4]

[^1]: https://blog.mozilla.org/security/2013/12/09/revoking-trust-...

[^2]: https://www.mozilla.org/en-US/about/governance/policies/secu...

[^3]: https://www.mozilla.org/en-US/about/governance/policies/secu...

[^4]: https://social.technet.microsoft.com/wiki/contents/articles/...

[tptacek]

It's not different from the current CA situation. That's my point.

[dvanduzer]

That was my point, too: the theorized system already exists. I'm definitely not advocating its use.

Ultimately, the URL bar needs to go away. More fundamentally, the asymmetric relationship between very large organizations that authenticate their identity with browser CA certs, and individuals who authenticate their identity with passwords needs to change.

Cryptographically generated addressing schemes like Telehash can do the automate-able stuff better than the current CA situation. The problem (and solution) I'm struggling to articulate involves the fact that granular authorization systems and trust databases need better UI before we can really fix this.

I suspect cheaper hardware tokens will play a significant role.

[e12e]

No, not really. DNSSEC secures DNS, allowing it to be used (among other things) as a secure transport for delivering other certificates.

CAs already provide the same trust infrastructure, but due to incentives do not sign delegating certs by default, but typically charge extra for certs that allow the owner of a domain to set up their own internal CA.

DNSSEC only works (reasonably) for TLDs where DNSSEC is implemented, and when DNS resolvers implement checking -- many ISPs don't. Delegating CAs are already part of SSL/TLS.

DNSSEC requires fidling with the DNS information -- delegating CAs, while requiring issuing certs, only require configuration of the various services (web, imap, smtp etc) -- as per usual.

For delegating CAs to improve the security of any given domain -- some infrastructure would be needed to set up an intermediate CA. I guess for small organizations, OCSP wouldn't really be needed, as the CRLs would be small (assuming different CA for public facing services and stuff like personal certs for users). Another option would be to simply roll certificates frequently.

[jackalope]

From the article:

Certificates bind a public key and an identity (commonly a DNS name) together.

...when issuing certificates a CA validates ownership of a domain by sending an email, or looking for a specially formed page on the site.

So, if "DNSSEC secures DNS," as you say, why do we need certificates at all? Considering that the CA already depends on DNS to issue (many) certificates, why not cut out the middle man and simply publish the domain's public key in a DNS record? What actual value does a certificate offer other than that? I'm genuinely asking, because I'm curious if DNSSEC provides a way for a domain owner to establish trust in the domain's DNS records, that cannot be tampered with by the domain's registrar.

[einhverfr]

I think the fundamental problem with DNSSEC is it doesn't go far enough. DNS really is the original directory service of the internet. If we could generalize it a bit, and allow TCP queries secured by Kerberos, with far better row-level security, there's no reason we couldn't replace LDAP with something a lot simpler.

If we could replace LDAP with something a lot simpler, we could as replace X.509 with something a lot simpler (LDAP is a mildly simplified version of X.500, of which X.509 is a very closely related OSI legacy standard).

So DNSSEC doesn't go far enough. IMO, we should be working on ensuring that it can be extended to allow for certification of hosts, etc. However, at present it doesn't do this very well.

[dvanduzer]

This sounds very much like the directory system I want to build on top of Telehash.

The problem I still see is creating a global directory of Kerberos realms. There still needs to be a sneakernet component for private key distribution. (Maybe that would be a better use of the armored cars I see making regular stops at the banks around town.)

[einhverfr]

Ok, so suppose registering a domain also required registering a public key for the domain name. This would require a change for the root realm. Suppose we were to extend the DNS protocol so that when you do an NS lookup, you get the keys of the NS's as well (might require SRV records or the like in the root tree). You'd need a mechanism to revoke or rotate keys, but that could be done.

From there it should be quite possible to tie public keys to hosts all the way down since you now have a chain of trust. Should be trivial, but the problem is that I don't see how to get the root zone to publish domain keys.

Yes, that replaces CA's with domain registrars, but that is a healthy trade. Since you would get keys (all allowed keys!) all the way down with your query, you wouldn't need to check revocation because you'd know the keys before making the connection.

[e12e]

>> Certificates bind a public key and an identity (commonly a DNS name) together.

>

> So, if "DNSSEC secures DNS," as you say, why do we need certificates at all?

Yes and no. Note that a cert binds an identity, not just a DNS name (but that is what is needed for web servers).

DNSSEC doesn't work without resolvers checking for the DNS keys, and it's not immediately clear (to me at least) if the various higher level clients can transparently detect if a DNS name is secure or not (similar to how a web browser can't tell if it's accessing a resource over a secure IP based VPN and can therefore safely transmit credentials via plain auth).

For trust to work, there needs to be integration of the chain of trust all the way from the user to the server. TLS/SSL already provides this -- and with delegation the infrastructure is in place for owners to manage trust for their own domain (and it is already possible, but typically expensive).

In it's barest form DNSSEC only makes DNS secure, which prevents DNS spoofing. If you also place a cert (could be self-signed) in DNS, then you have a "full" solution to securing communications. You would be able to download the cert without DNSSEC, but unless the chain of trust of the cert could be verified some other way, you wouldn't be able to use that cert for secure communications.

It is true that current CAs bind a cert to a domain name, but it's not really the domain name part that is interesting, it's the entity identifed by that name. So your browser can say, I don't care where this authenticated (and encrypted) data stream is comming from, I just care that it is backed by example.com (that is backed by example-ca.com) -- and if the user thinks that Example corp. owns the example.com domain, one can then infer that the browser is really talking to a web site set up by Example corp -- regardless of which IPs and DNS records are involved.

Keep in mind that the same CA infrastructure allows a user to indenify to a server as [e-mail] -- from any ip or doman name -- just as securely, via mutal trust in "Example CA". I think it's somewhat unfortunate that DNS is so tightly integrated into the user interfaces for the web -- asserting things about IP adresses and DNS names isn't really all that interesting -- it's asserting things about entities that is interesting.

While I'm no fan of the current CA system, I'm not convinced DNSSEC is securing the right things at the right protocol level(s).