Hacker News Reader

Comment by tptacek | Hacker News Reader

Look at the code in Firefox that handles certificate failures, presents user interface to end users to resolve the ambiguity, and then completes the operation once that happens. Then look at the sample code I linked to. The code I have there is a decent approximation of "idiomatic". The code I'm referring to in browsers is larger by a factor of, what, 100? 1000?

Browsers and operating systems aren't going to add full DNSSEC resolving caches. They're going to use stub resolvers and delegate this problem to "DNS servers" (caches), like they always did. DNSSEC does not protect the last mile. You can dodge this point by redefining the concept of "last mile", but that's not a persuasive argument.

The US NSA controls both the CA hierarchy and .COM. It is amusing to see people try to rescue DANE from criticism by evoking the CA system to protect it.

View on HN

I have a question. Your article's reference for "governments control the DNS" just describes public in rem legal actions by the Justice Department to Verisign to seize domains. How does that imply control? By that logic, wouldn't it be a valid statement to say "Matasano is controlled by the US Government (i.e., the NSA)" because it's only one in rem legal action away from injunction?

I'm just asking for clarification for the statement; I'm in agreement with the crux of your argument. I just don't understand how the Government(s) control DNS more or less than any other aspect of the internet that is vulnerable to meatspace attacks like injunctions and arrests.

EDIT: I think I understand the distinction now. Your argument is saying "the CAs are bad but we mustn't allow DNSSEC to replace them." And a domain's TLS certificate is safe from an individual government's subversion if the CA resides outside of that government's jurisdiction.

Am I understanding this correctly?

> Browsers and operating systems aren't going to add full DNSSEC resolving caches.

Fedora 22 feature change request: https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Res...

> Look at the code in Firefox that handles certificate failures, presents user interface to end users to resolve the ambiguity, and then completes the operation once that happens. Then look at the sample code I linked to. The code I have there is a decent approximation of "idiomatic". The code I'm referring to in browsers is larger by a factor of, what, 100? 1000?

(The link tptacek is referring to is https://gist.github.com/tqbf/e8d82d614d1fea03476b btw.)

If I had my say, the code you link to would not have to be changed at all, because the `gethostbyname` interface would stay the same and return a lookup failure on unsuccessful DNSSEC verifications, if the parent zone reports the domain to be DNSSEC enabled.

> Browsers and operating systems aren't going to add full DNSSEC resolving caches. They're going to use stub resolvers and delegate this problem to "DNS servers" (caches), like they always did. DNSSEC does not protect the last mile.

You've said so in your blog post, but you don't say why. Everyone that is seriously considering using DANE as a replacement to the existing CA hierarchy assumes they do include a DNSSEC enhanced resolver (I don't see why it has to be a "full" and caching resolver, though).

> DNSSEC does not protect the last mile. You can dodge this point by redefining the concept of "last mile", but that's not a persuasive argument.

When the "last mile" is on my PC (i.e. when my local resolver checks the DNSSEC signatures) then it is as protected as my OS.

> The US NSA controls both the CA hierarchy and .COM. It is amusing to see people try to rescue DANE from criticism by evoking the CA system to protect it.

While I find your enthusiasm to protect against the NSA encouraging and important, my point actually was that DANE improves upon the security of the existing CA system against attacks by non state-sponsored attackers and foreign state-sponsored attackers beside the NSA.

Let me state it differently: At the moment, example.de has to worry about attackers controlling the .de zone (, the root zone) and attackers controlling any of the >100 CAs (including many nation states). With DANE, example.de only has to worry about attackers controlling the .de zone and the root zone. As a more graphic example consider how at the moment the "Deutscher Sparkassen Verlag GmbH", the CA of a german umbrella organization of local banks, can issue certificates for amazon.com, wikipedia.org or any other domain world wide. This kind of nonsense is solved by DANE, not NSA spying.

(My apologies to German readers for not inflecting "Deutscher" in the above sentence. I keep the identifier verbatim to allow readers to look it up via non-fuzzy search.)

> Browsers and operating systems aren't going to add full DNSSEC resolving caches.

You phrase it like a fact. In practice we're seeing quite the opposite. Firefox clearly sees a fully validating client as the only reliable way to implement TLSA.

No. Firefox has no current plans to implement DANE. The plans on the wiki date from 2011, at roughly the same time Chrome played with DANE. The Chromium team subsequently removed the code for DNSSEC validation, and has since then declared that they're not moving forward with DNSSEC. The Bugzilla ticket for DANE support in Firefox features a member of the Mozilla team declaring that DANE support is no longer an active project there.

That's not what I said. If you look at said ticket, you will see that in fact plans were to make it fully validating.

What's your point? One dude on the Mozilla team played with the idea of implementing DANE. Then they gave up on it. Now that idea is a rebuttal to my point that browsers won't benefit from DNSSEC?

Is the point that it's possible to implement DNSSEC on end systems? Of course it's possible; everything is possible. But that's not what's going to happen, in large part because the DNSSEC operational community doesn't believe it should happen, and designed the protocol to make it easier not to.

No. That is not what I responded to.

You wrote that browsers, if they implemented DNSSEC, would choose to implement stub resolvers without full validation. In fact, both browsers who looked at implementing it clearly did so with the intention of doing full validation.

I did not say that they implemented it, or even that they will. I did say that the claim that there were plans to only implement a non-validating stub resolver in common browsers is not true.

You write as if what I said about browsers and DNSSEC wasn't right there in the thread above your comment. An odd rhetorical strategy.

> Browsers and operating systems aren't going to add full DNSSEC resolving caches.

Actually they already did. OS X for instance has this baked into mDNSResponder.

Fire up a terminal, run "tcpdump -s0 -i en0 udp", open Safari, resolve "www.enteract.com", and tell me if you see a full recursive DNS lookup happening, or if instead you see Safari's stub resolver asking the DHCP-configured DNS cache server for help over the insecure Internet.

mDNSResponder supports DNSSEC validation, please look at the source code:

http://opensource.apple.com/source/mDNSResponder/mDNSRespond...

This is like saying "everyone can just run their own DNS server". Of course, as I said, they won't. The fact that Apple has a DNSSEC-resolving recursive lookup server and Safari doesn't use it strengthens my point instead of weakening it.

That doesn't really respond to the point. Does Safari use DNSSEC or not?

Of course it does, Safari uses the resolver provided by OS X, which is mDNSResponder. (It superseded the stub resolver in libSystem.dylib starting with 10.6.)

You are mistaken. https://news.ycombinator.com/item?id=8896092

How's that saying go about only proving the code correct, but not testing it? I think there's a reason tptacek specifically asked about tcpdump of on wire traffic.

> Actually they already did. OS X for instance has this baked into mDNSResponder.

That's not altogether true and now also irrelevant.

mDNSResponder has DNSSEC support that isn't quite baked and was not enabled by default. The only way to use the support it did provide was by passing specific flags to a relatively low-level API. (You'd have to configure the system to use a DNSSEC enabled resolver as well of course.)

mDNSResponder has been replaced by discoveryd which does not have any DNSSEC support (other than silently accepting the validate flags). Perhaps it'll gain further support in the future. If it does I'd not bet on it being enabled by default any time soon.

Reply on news.ycombinator.com