User: Password:
|
|
Subscribe / Log in / New account

argument for DANE

argument for DANE

Posted Mar 19, 2014 8:14 UTC (Wed) by tialaramex (subscriber, #21167)
Parent article: Debian and CAcert

The argument that Debian should work as much like, say, Windows, in this respect as possible is hopeless. Windows delayed SNI support by many years, was that a reason why Debian software should disable SNI ?

IMO Debian should push hard for DANE, enabling it in software that currently has code but chooses not to enable by default, applying patches that are stuck in limbo, that sort of thing.

For the commercial heavy weights there is no incentive to move on DANE unless/ until we get another batch of popular press stories about the SSL CAs being crooked that make them look complicit. My assumption would be that new item #1 on the budget at Verisign after its last problems was not "internal audits" or "beefed up processes" but "Hire PR consultants to do damage control".

So the impetus has to come from Free Software.


(Log in to post comments)

argument for DANE

Posted Mar 19, 2014 14:50 UTC (Wed) by jhoblitt (subscriber, #77733) [Link]

Does anyone know why Mozilla has not enabled DANE? https://wiki.mozilla.org/Security/DNSSEC-TLS-details#Code

argument for DANE

Posted Mar 19, 2014 17:39 UTC (Wed) by yokem_55 (subscriber, #10498) [Link]

From what I understand DANE is still in the Draft RFC stage, so any implementation would still be going after a moving target. On top of that DANE requires a working DNSSEC validation chain to be present - either through the user's DNS servers or entirely in the client and neither are particularly prevalent in the real world.

Then, you run into the problem that DANE simply moves the roots of the trust chain away from CA's to registrars and TLD zone operators. I'm not sure that we would really make any gains.

argument for DANE

Posted Mar 19, 2014 18:10 UTC (Wed) by anselm (subscriber, #2796) [Link]

Then, you run into the problem that DANE simply moves the roots of the trust chain away from CA's to registrars and TLD zone operators. I'm not sure that we would really make any gains.

The main benefit would be that today any CA whatsoever gets to sign certificates for any domain name whatsoever. Under DANE, though, the trust chain goes from only your TLD zone operator to your zone. There is no way for the operator of the .xyz zone (or somebody with influence on that operator) to interfere with your certificates unless your domain is within the .xyz zone, too.

argument for DANE

Posted Mar 20, 2014 0:34 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Exactly. Today you have the situation where .example can be as well run as any domain anywhere, and yet a company you've never heard of (or a state acting through that company), based in a country you've no plans to ever visit, issues a CA cert that says some unrelated third party "is" your whatever.example domain, and the average person's web browser trusts them silently.

Under DANE the responsibility for securing domains in .example falls to the .example operators, the very same people _getting paid_ by whatever.example. This is a much more satisfying arrangement. Most likely .com will continue to be run very poorly but other domains can choose to do better, which today is futile at least in respect of security.

And as a bonus you get the thing CAcert wanted most of all, which is that everybody can have working PKI at potentially zero cost. That can never happen (as CAcert's experience illustrates) under the current regime.

DANE TLSA RFC

Posted Mar 20, 2014 2:24 UTC (Thu) by draco (subscriber, #1792) [Link]

The RFC can be found here: https://tools.ietf.org/html/rfc6698

argument for DANE

Posted Mar 20, 2014 9:14 UTC (Thu) by gerv (subscriber, #3376) [Link]

A little searching of Bugzilla reveals:

https://bugzilla.mozilla.org/show_bug.cgi?id=672600

"I would say that this is something we're still interested in, but it has been put on hold due to other higher-priority projects. For more information, you can take a look at https://wiki.mozilla.org/Security/Roadmap (when the DNSSEC-TLS item goes from "Unprioritized" to P1 or P2, it probably means we're actively working on it)."

That Roadmap page shows all the other things Mozilla engineers want to do first.

Gerv

argument for DANE

Posted Mar 31, 2014 14:47 UTC (Mon) by Lennie (guest, #49641) [Link]

I've recently seen a talk by someone working on Chrome/Chromium on these kinds of security features.

Basically they seem to have given up on DNSSEC/DANE and gonna keep working on Certificate Transparency.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds