I wish there was an alternative to the CA system we have now. I'm part of a private forum with a self-signed cert and while initially there was some hesitation to it, most members have added it to their browser exceptions.
Moxie Marlinspike created an alternative to the CA system called Convergence[1]. His DEFCON video[2] does a good job describing the problem and his proposed solution. There's a Firefox plugin for it, but Chrome has come out and said they will likely never support it[3].
The university I work for uses Self-signed certs for everything but ssl. Apparently setting up properly signed certs is too expensive. And it's more effective to have the IT staff spend an inordinate amount of time convincing end-users that the warnings about invalid certs from various applications are nothing to worry about (I'm looking at you Andoid and OSX).
No, DNSSEC has nothing to do with CAs. Each DNS authority defines its own keys used to sign its records.
> They were just renamed to "Trust Anchors".
You are thinking about DANE [1], which is what the a protocol on top of DNSSEC. Using DANE you authorize X.509 certificates and/or CAs for certain domains. This allows you to restrict your domain to a specific well-known CA (such as Verisign), but it also allows you to authorize your own CA or even a specific certificate directly. It even works per-service, so you do not need to use the same CA/certificates for all your services.
If you were suggesting that DANE does not solve the traditional CA issue you are wrong.
You're interpreting "CA" too literally. DNSSEC doesn't rely on X509 certificate authorities but in effect it relies on an equivalent, in that Verisign is a central authority certifying ownership of all .com domains.
A single trusted root is better than the hundreds of roots in the CA system. I don't trust Verisign very far, but I certainly trust them more than Verisign AND Diginotar AND honest achmed's used cars and certificates AND ...
And shouldn't it be possible to implement certificate pinning for whole tlds? Then we'd only have to trust root for unknown tlds.
First, you don't get "a single trusted root". If DNSSEC/DANE had been deployed 3 years ago, Qhadaffi's Libyan government would have effectively been the CA for BIT.LY.
Second, and more importantly: the smaller number of trust anchors you end up with in DNSSEC are controlled by world governments.
It seems absurd to me that the Internet's response to the "global passive adversary" of NSA would be to hand the entire PKI system over to the USG formally. That's what DNSSEC does.
> ...Qhadaffi's Libyan government would have effectively been the CA for BIT.LY.
They already are, in practice. Many reputable CAs will issue certificates to anyone who can forge an MX record for a domain. With or without DNSSEC, TLD operators are capable of forging those records.
>It seems absurd to me that the Internet's response to the "global passive adversary" of NSA would be to hand the entire PKI system over to the USG formally. That's what DNSSEC does.
No, DNSSEC builds authentication into a system that is and has always been centrally controlled. And just like with the X.509 CA system, you can use pinning or Convergence or anything else you want to supplement that.
> No, DNSSEC has nothing to do with CAs. Each DNS authority defines its own keys used to sign its records.
which in turn must be signed by the zone operator (e.g.: Verisign for .com) who publishes them in DNS. So we still have Central Authorities - in the sense that there is still some overlord controlling everything.
They only have to admin the DNSSEC stuff (publish your domain name keys along with your nameservers, as you set them up through your regular domain provider).
The DANE part needs no further support than you being able to use DNSSEC for your domain's DNS. Obviously there is always some entity controling each TLD, and that entity can screw up your domain if it acts improperly.
You're not following. DNSSEC is secured by a chain of keys leading to a root; the entity that controls the root controls the chain. If you use DNSSEC to authenticate your certificate, you're giving control over your certificate to whoever runs the roots.
Nobody is suggesting that the naive X.509 scenario we had a year ago is secure. They are, however, skeptical of the idea that we should invest millions of dollars into an architectural change to the core of the Internet to land... right back where we are now.
If you're using a resolver which supports DNSSEC, and you're using Firefox with the DNSSEC-Validator addon from https://www.dnssec-validator.cz/ (which supports DANE) and you visit https://grepular.com/, you will see a nice little green icon in the address bar to show you that DNSSEC was used, and another green icon to show you that the SSL cert was validated using DANE.
That's interesting. I hope it sees more widespread adoption by browser vendors and the recent security disclosures will hopefully help to tip implementation in that direction.
I'm surprised no one here is talking about Namecoin [1]. It has become obvious that the PKI system is failing, and the main issue is centralization.
I don't know if Namecoin itself will be the solution, or some other blockchain-based method that achieves decentralization such as the more generic Ethereum [2], but as engineers we should be supportive of such systems, as they provide better security and true -not just delegated- domain name ownership.
>It has become obvious that the PKI system is failing, and the main issue is centralization.
Actually, the problem is exactly the opposite. Any CA can sign a certificate for any domain.
What compounds the problem with the CA system is that CA trust is sticky. When a new CA gets added to trust stores, they are effectively trusted for life. That's not how trust actually works.
What we need is a system that is distributed and that allows for trust to be granted and - most importantly - revoked at will without causing collateral damage (i.e. for innocent sites that end up using a bad CA).
Moxie Marlinspike's convergence[0] was a great idea, but it's never really taken off. TACK[1], also by Marlinspike, looks like nice feature to help transition away from the CA system when we come up with something better.
I'm confused on the implementation of something like this. HSTS is an HTTP header, so it is up to the HTTP server, not the DNS server. How is HSTS enforced at the domain layer?
Right but site owners need to request inclusion on that list only after they've enabled HSTS on the server. I've done this myself and I must say I'd be pretty angry if browsers forced an entire TLD to require HSTS. The result would be SSL warnings everywhere.
"Only if a host responds with a valid HSTS header with an appropriately large max-age value (currently greater than or equal to 10886400, which is eighteen weeks) do we include it in our list. ... We limit the list to hosts that send a large max-age under the assumption that these sites will not revert to non-HSTS status."
but you obviously can't check every domain in the TLD. A preload will still function, that's the whole point: make sure a MITM can't cut off the HSTS header.
One, he is the person in charge of adding sites to the HSTS store. Two, he's asking TLD owners to talk to him, not saying "we're going to make this TLD require SSL".
It is a bit confusing, but I'm not sure that this is actually an error. It sounds like he may be in a position to directly make that change to Chrome, but is trying to clarify that his thoughts on Firefox and Safari are his, and he can't speak on their behalf. When you read it that way, it makes sense.
What's more, Firefox previously adopted a related thing that agl invented (HSTS preloads in general), so he has personal experience of their being amenable to this sort of thing.
[1] https://www.nccgroupdomainservices.com/