

Why not DANE in browsers - tptacek
https://www.imperialviolet.org/2015/01/17/notdane.html

======
tptacek
The meatiest bit of this article, which is great:

Attackers control connectivity. Connectivity is expensive. Connectivity is
also unreliable: captive portals, proxies, and firewalls break it. These
factors make OCSP certificate revocation unworkable. For similar reasons, they
make DANE's ostensible safeguard against malicious CAs unworkable. In
practice, DANE would probably only be usable as an _additional_ CA; it would
not be able to effectively overrule any of the 1482 existing CAs.

~~~
Nimi
Slightly off-topic: Could you please add RSS support to your "blog"? I'm sure
others, besides me, would love to me notified of new entries. Thanks!

------
tlb
The fact that TXT records don't work for some people shouldn't stop us.
Anything that isn't currently widely used is broken for lots of people,
because that's how networks are administered. Once it gets deployed and people
start complaining, any specific network problem will get fixed.

Delaying proper network security because it won't currently work for a few
percent of people seems like a recipe for never getting there.

~~~
tptacek
It's a cost-benefit issue. Do you believe DNSSEC is so valuable that it's
worth (a) breaking connectivity for a significant number of people and (b)
incurring the expense of replacing/upgrading the middleboxes that are breaking
connectivity? If so, why?

~~~
tlb
I don't have a strong opinion on DNSSEC itself. It seems like it might be a
good idea for email, at least.

I don't have much sympathy for network admins who block TXT records because it
doesn't currently seem to break anything. TXT records are part of the spec,
and if some of them have configured something to block them, that's not a good
reason for everyone to not have secure systems.

------
101914
I'm reading these blogged opinions on DNSSEC and DANE and I notice that they
never state the problem(s) that these "solutions" are meant to address. At
least not explicitly.

Somehow I doubt it, but if by chance there is only one true problem being
addressed and that problem is simply how do we authenticate another computer
as being who we believe her to be, then my second question is: what is wrong
with SSH authentication?

~~~
gsnedders
> what is wrong with SSH authentication?

You need some secure, out-of-band, communication means to transfer the key
fingerprint to be able to verify it. The whole aim of the CA structure is so I
don't need to somehow find a secure means to contact Amazon to verify their
key fingerprint prior to first connecting to their website.

~~~
101914
What if I do not want to transfer the key over an insecure network of computer
networks that are trivial to tamper with?

What if I would prefer to look up or obtain the key via some other means (that
I deem more trustworthy that the internet)?

~~~
cpach
What key are you referring to here? The CA’s root certificate?

------
tobias2014
I'm using the browser plugin available at [https://www.dnssec-
validator.cz/](https://www.dnssec-validator.cz/) to validate dnssec/dane.

------
sarciszewski
Thomas: Would you agree that DNSSEC is a solution looking for a problem?

~~~
msturgill
There are a lot of real problems that DNSSEC can help solve.

However, it is important to note that DNSSEC and DANE are two different
things. Much of the recent discussion here has lumped them together.

~~~
tptacek
What would those problems be?

~~~
msturgill
Broadly? General MITM, Kaminsky, etc.

DANE as an application of DNSSEC is interesting (and based on the recent
string of editorials, contentious as well). Using DANE to constrain CAs could
add an additional layer of protection against a rogue CA. Using it as an
additional CA could help facilitate moving towards "HTTPS-everywhere".

The takeaway of course in implementing it in any manner is that it is just
another layer, not a panacea.

Outside of DANE, there are other applications such as IPSECKEY and SSHFP that
have utility.

~~~
tptacek
How does securing DNS lookups solve the MITM problem if the underlying traffic
remains unencrypted? If you encrypt the traffic, you don't need secure DNS
anymore.

~~~
derf_
That depends on what your trust model is. Somebody is resolving the DNS query,
and then the result gets transmitted to you. If all you're worried about the
result being MITM'd during transit, then encryption is sufficient. You can set
up DNSCrypt to deal with this today [1].

But often the provider resolving the query is itself untrustworthy. Most
providers these days (including OpenDNS) redirect invalid queries to their own
landing pages (which poisons caches and has other bad effects). Providers may
"censor" certain domains. Or be subverted by state-level actors (see:
Belgacom). In DNSSEC, the root of trust is the administrator of the DNS root
zone (e.g., Verisign, whom you're probably already trusting anyway).

[1] But encryption is not a panacea. As soon as you visit the address(es)
returned, someone will get a pretty good idea what you looked up.

~~~
Panino
> Most providers these days (including OpenDNS) redirect invalid queries to
> their own landing pages

OpenDNS stopped doing this on June 6 2014:

[http://blog.opendns.com/2014/05/29/no-more-
ads/](http://blog.opendns.com/2014/05/29/no-more-ads/)

~~~
teddyh
OpenDNS could still turn ads on again at any time. And the censorship and
subversion arguments are still valid.

