Public response to a private message On 03/11/14 16:35, (..xxx..) wrote: > On Tue, 2014-03-11 at 13:30 +0100, Guido Witmond wrote: >> With DNSSEC and DANE, we have that missing link. DANE allows site >> operators to specify what CA they use for their site. It could be >> allows to set up your own CA and specify that. > > Hey Guido, I think this idea is interesting, but I thought that > DNSSEC was just as centralized as the CA infrastructure. What > prevents the DNS authorities from acting in the same manner as the CA > cartel? Hi, (xxx) DNSSEC and DANE change the landscape. 1. With DNSSEC and DANE you don't need one of the global CA certificates anymore; You can run your own CA. If that proves too difficult , you might outsource it to one. This puts the global CA in a position where they have to provide value for service, instead of just rent-collecting for a green url-bar. If these global CA's are smart they would offer services where they will guard your own Root CA key. But I can dream... 2. DNSSEC itself is quite a hassle to set up and run correctly too. It's best to outsource that to a DNS-registrar. Although this is still a niche market for DANE records in DNSSEC, the same market forces apply. If not satisfied with one registrar, take your domain name and shop for another registrar. 3. The registrars in the DNS-hierarchy can still be persuaded to delete your certain domain name. (censorship.) Or point it towards a different server (hijacking). I'll show later how to protect against that. When everyone can run their own Root CA, all sorts of new avenues open up. With their own Root CA, companies can provide certificates for their spokespeople. Or they can sign certificates for clients (at a slightly different domain name). This way, banks can send out encrypted statements directly to customers. No more emails asking you to log in with a username and password. This reduces MitM attacks drastically. It increases privacy, I would have a certificate for each of my banks, one for my pension fund. Another at this mailing list and yet another at another mailing list. My browser would keep them apart. With a small addition to the browser, it can make sure that it only offers me client certificates to log in at the server whose server certificate has been signed by the same Root CA. This makes logging in even easier for the end user. And it really eliminates MitM-attacks. While crooks can create a pixel-perfect copy of a banks' site, the crooks cannot impersonate the Root certificate of the bank, so the browser will correctly identify the crooks' site as a different site and not offer my banks' client certificate to log in. My browser protects me against phishing. We can go one step further. It is the Root CA of a site that is used to select the client certificates that the browser offers the user to log with. The domain name is not used in the selection. It means that the site owners (who own their own Root CA) can create a new domain name, sign a server certificate using their root CA and point these new DNS-records to their server. The site has changed domain name but the client certificates stay valid. How's that for censorship resistance? But that is the realm of what I call Eccentric Authentication. With regards, Guido Witmond.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk