
In Defense of DNSSEC - jocluteseh
http://shorttext.com/63084847
======
tptacek
I read this thing so you don't have to. Here's a summary of what I believe
this person's arguments to be. If I've failed to be charitable enough, please
do call me out for that.

1\. With DNSSEC, SPF, DKIM, and DMARC enabled, email is secure enough to
authenticate requests for TLS certificates. Without DNSSEC, it isn't.

2\. DNSSEC zone owners control their keys, so DNSSEC doesn't imply that the
DNS roots control keys.

3\. There is nothing wrong with older cryptosystems and anyways, DNSSEC
supports elliptic curve now.

4\. The code to make DNSSEC deployable is underway and so it's not valid to
suggest that it's too expensive to support.

5\. All that's required of DNSSEC deployers is to generate a couple of DNS
records, and so it can't be expensive to to deploy.

6\. It's specious to criticize DNSSEC for only securing server-server
transactions and not browser-server DNS lookups.

7\. Nobody ever said DNSSEC would provide end-to-end encryption. DNSSEC
reveals hostnames now, but there's something called NSEC5 that's going to make
that better.

8\. Nobody ever said DNSSEC was going to provide end-to-end security so it's
not valid to criticize DNSSEC for not doing that.

9\. DNSSEC isn't a replacement for the CA system, but rather a security
improvement for DNS, so comparisons to TLS and CA aren't valid.

~~~
marcosdumay
Well, about #2, people are defending the status quo (where any governemnt
anywhere on the world can compromisse a site's key) by arguing that with
DNSSEC there'll always be one government able to compromisse any site's key.
Calling that a falacious argument is too charitable, it's an outright lie (and
I wonder why that piece of propaganda is so pervasive).

About #3 the article simply points that there's nothing wrong with DNSSEC,
unless you choose to use bad crypto algorithms. Guess what, any cryptosystem
works the same way, TLS included.

About #6, yes, it's specious to criticize DNSSEC because browsers choosed to
not support it (unless you are talking from the point of view of a site master
wondering how you'll configure your host today - but even then, that's not a
valid criticism of the algorithm, it's just reason to not deploy it now).

About #8, yes, that's not valid. DANE is the main end-to-end encryption
algorithm that used DNSSEC, so one must either criticize DANE (if able) or
shut-up.

Anyway, what a badly formated page. Points #1, 4, 5 and 7 are flaws. Point #7
is a big flaw, and don't hold your breath waiting for it to be solved. I'd say
about point #9 is that DNSSEC is exactly a less broken CA system. I can't see
where the author is going...

~~~
rakoo
> I'd say about point #9 is that DNSSEC is exactly a less broken CA system.

I'd say DNSSEC is _more_ broken than the current CA system. At least with the
current system you can more or less choose a CA to trust (or, more
interestingly, a bunch of CAs), that you can change anytime you want. The only
thing preventing you to do it is the lack of tools to actually do it, which is
why tools such as TACK/HPKP, or Convergence/Perspectives, are needed.

With DNSSEC, there is only one realistic root ever possible (call it ICANN or
NSA as you want, that's yet another problem)

~~~
marcosdumay
> At least with the current system you can more or less choose a CA to trust

Blind illusion. You must trust all of them. Any of them can attest somebody is
you any time they want.

The good thing about DNSSEC is exactly that it only has one root. And people
can pin second and third level domains, completely escaping it - for some
other org, controlled by some other agency, but one can choose what agency to
submit their identity.

------
joshuafalken
Page seems down; cached version:
[http://webcache.googleusercontent.com/search?q=cache:_q7stvY...](http://webcache.googleusercontent.com/search?q=cache:_q7stvYH64MJ:shorttext.com/63084847+&cd=1&hl=en&ct=clnk&gl=us)

------
jamiesonbecker
_jocluteseh:_ Can DNSSEC be re-directed to incorrect public keys? Sure.

 _jocluteseh:_ DKIM signs the message and provides a body hash which is
validated against the public key in DNS.

 _tptacek:_ SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and
DMARC. It isn't even close. It is unsafe to authenticate CA certificate
requests via email before DNSSEC and remains so after DNSSEC. SMTP is
insecure.

in short: DNSSEC and SMTP hang together by threads. cut one thread and the
whole thing collapses. "It's better than what we have right now" isn't an
argument because we actually don't have it anyway. tptacek is 100% correct.

~~~
danyork
> jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure.

Please explain how. The whole point of DNSSEC is to provide a cryptographic
validation that the material put into DNS by the operator of a zone is the
same information you get out of DNS when you perform DNSSEC validation.

I'm quite tired of seeing the assertion that "DNSSEC can be re-directed"
without people actually walking through HOW that redirection can occur. (Thank
you in advance for doing so.)

~~~
jocluteseh
I'll try to post a comment, but my IP address may be rate limited -- I keep
getting "You are posting too fast" errors.

In any case, you've made my case for me much better than I could have made it
myself. The problem with the 'redirect DNS' argument is that -- it seems --
most people misunderstand that in order to redirect a DNSSEC signed domain,
you need to control the 'root' key AND re-sign every domain under that key.

So, _can_ it be done? Yes.

Is it _likely_ to happen? No.

I would argue that the re-direct DNSSEC argument is nearly vanishingly small.
But it can't be claimed to be zero.

~~~
jocluteseh
> Fair enough.. but if you're talking to a MITM anyway, would you agree that
> it's game over?

Don't think: 1/10,000 chance. Think: 1/1,000,000,000,000,000,000,000 chance.

You are much more likely to die by getting run over by an airplane while
walking down the road while also holding a Dalmatian over your head, than to
have your DNSSEC signed domain redirected.

The edge case that's being argued about NSA taking over DNSSEC is rather over
done.

However, if the argument is denial of requests, so as to block traffic, DNSSEC
or not matters not - so the argument again -- is not about DNSSEC as a
specific service or architecture.

~~~
jocluteseh
> You are assuming that your client OS/browser DNS resolvers have the pre-
> shared trust anchors for whichever root zone. That's kind of a big
> assumption.

First: There are two arguments to be had. One is the server side, and one is
the browser side. The server is going to know about the key problem if it
happens. The client side browser can know, if the client is using plugins like
this one:

[https://www.dnssec-validator.cz/](https://www.dnssec-validator.cz/)

Second: Here is the root key:
[https://www.iana.org/dnssec/files](https://www.iana.org/dnssec/files)

~~~
jamiesonbecker
Yep.. in a typical MITM scenario (say, at a coffeeshop or a hotel in a
firesheep sort of attack), server side checks won't help you at all since the
MITM recursive server could just keep spouting those lying lies :)

------
xorcist
It's a bit pointless to argue for or against DNSSEC. It exists, and if you are
fishing for larger customers in the hosting business, you already have had to
relate to that. It is, for better or for worse, infrastructure.

You can have informed opinions on how to change it, just like you can argue
for changes in the TLS protocol to extend it or modernize the crypographic
primitives. But a fundamentally different protocol would need a clean start,
and would need to offer enough advantages to get people to switch. These
global systems takes a decade to change, at best, and it can be done. While I
would love for both TLS, IPsec and DNSSEC to have been designed differently
from the start (i.e. without X509), that's not where we are today.

As for the basic idea, it is wise to ask yourself: Would it be useful for
registrars to prove domain ownership cryptographically? If you think that
could be put to good use, you will understand the basic premise and what the
protocol was designed for.

------
peterwwillis
Before I pick apart the obvious points, keep this in mind: do you ___need___
DNSSEC right now? Not would it be helpful or nice or make things a bit more
secure, but do you _need it_?

\--

> 1\. DNSSEC is better than no DNSSEC.

You can't use your argument to defend your argument; this is circular
reasoning and therefore illogical.

Also, the commenter has no idea what protocols use crypto in what way as many
of them are proprietary.

> 4\. [...]There may need to be some software adjustments to fully accommodate
> DNSSEC. However, there currently exist several DNSSEC plugins, extensions,
> or modules for several end user browsers. Thus, the code base has already
> been started, making improvements and merging code bases is the next step.

This is like saying "Replacing cars with driverless cars just requires a
software update". Yeah. On every car and road. No biggie. I'll put it all on
my Visa.

> In short, if a devops can type a few characters in a DNS record, a devops
> can deploy DNSSEC within a few hours depending on the domain complexity.

You don't need to be "a devops" to make a DNS record change, but ideally you
would call this person the domain name record owner or DNS administrator. This
shows little understanding of how DNS is deployed in the real world.

> Generally #6 is specious.

If you consider "we have to upgrade our OS on all our systems - which may
range from 1 to 100,000 depending on the organization - to gain a marginal
amount of security we didn't need before" to be specious [assuming Windows
comes with a validating stub resolver now].

> There is a vulnerability in DNSSEC, that is openly listed in the RFCs, that
> indicates subdomains are enumerated. [..] However, for simple domains with a
> few hosts, enumerated architectures should be a minor problem if a problem
> at all.

"Please ignore this information leak."

> This sockpuppet Anti-DNSSEC rant is inaccurate, incomplete, and presents a
> picture of DNSSEC that is unsupported factually, mathematically, and
> architecturally.

"I can't argue the point that we don't need DNSSEC, so let's just throw some
hyperbole around and hope nobody notices I don't even try to prove my claims."

------
gwu78
Ask HN:

I am asked would I prefer 1. to have a pre-generated cryptographic "signature"
of every www page that can be checked against some centralized repository for
"authenticity" or 2. to encrypt every www page before transmission or at least
have it encrypted in transit?

"Both" is not an valid choice. I have no idea why not; as far as I can tell,
they are not mutually exclusive.

Because I mindlessly support SSL (let's encrypt!) I choose option 2 over
option 1.

Now I am asked the same question regarding DNS packets. 1. Sign the packets or
2. encrypt them?

Do I still choose option 2 over option 1?

If I choose 1, those DNS requests will be unencrypted plain text like
unencrypted HTTP.

Maybe DNSSEC has nothing to do with privacy regarding DNS requests?

~~~
danyork
> Maybe DNSSEC has nothing to do with privacy regarding DNS requests?

DNSSEC has _nothing_ to do with privacy.

DNSSEC is entirely about the _integrity_ of DNS requests.

DNSSEC is focused on ensuring that the information you get _OUT_ of DNS in
response to a query is identify to the information that was put _IN_ to DNS by
the operator of the domain you are querying DNS about.

That's it.

DNSSEC is a focused mechanism to ensure the DNS records have not been modified
in transit between the authoritative DNS server for a domain and whatever DNS
client is performing the DNSSEC validation.

~~~
colmmacc
DNSSEC is probably better described as a mechanism to prevent cache poisoning;
which is different from the "modified in transit" case.

DNSSEC isn't very useful for defending against a MITM:

1\. If the MITM goal is to block your domain, they still can by dropping the
queries or replies.

2\. If the MITM goal is to intercept your content, they don't need to rewrite
DNS; they can do it at TCP level. TLS/SSL is the effective mitigation here.

Additionally, if the MITM is between you and your resolver: for example in the
Café wifi case - DNSSEC is no help at all. Since stub resolvers and clients do
not validate.

~~~
danyork
colmmacc - I was thinking more of a case where the attacker is doing a MITM on
your DNS info, i.e. getting between you and the DNS server authoritative for
the domain you want to connect to in order to redirect you to another site. My
use of "modified in transit" was to the DNS query.

Yes, "cache poisoning".

Agree with your last point. DNSSEC only helps provide integrity validation
down to the point of wherever the actual DNSSEC validation occurs. In the most
secure form, that validation would occur on your actual device (i.e. the stub
resolver) or in your application (some now are building DNSSEC validation in,
ex. the Jitsi softphone). I know some folks who run Unbound (or DNSSEC-
Trigger) on their laptops to have the validation occurring there.

If you rely on the DNSSEC validation to occur at your ISP (ex. Comcast in the
US) your zone of attack exposure is then your local network and the connection
to your ISP... so yes, and attacker could potentially inject bogus responses
there.

If you rely on DNSSEC validation out at a public server such as Google's
Public DNS... well... then your zone of exposure is much greater.

This is where the work going on within the DPRIVE working group within the
IETF is so important. They are developing mechanisms to secure the
confidentiality and integrity of the connection between your stub resolver /
client and the recursive resolver you use. With DPRIVE covering your
connection, you _could_ use a DNSSEC-validating resolver that was farther away
from you.

~~~
gwu78
Thank you for the answers.

More questions:

If I run my own DNS cache on 127., 172.16. or 10. then do I have to worry
about "cache poisoning"?

Do I still need to verify authenticity of the answers to my DNS requests?

What if I can verify the authenticity of the authoritative DNS servers?

If we were somehow able to encrypt the DNS packets between my resolver and
authoritative servers on the internet, and I have verified the authenticity of
those authoritative servers, should I still have concerns that the answers I
get could be forged?

------
danyork
jocluteseh - your site seems to be down now (perhaps buried under HN traffic).
Perhaps post it as a gist on Github or something like that?
[https://gist.github.com/](https://gist.github.com/)

~~~
jocluteseh
Done... enjoy... or not, but just make sure the beer is cold.

[https://gist.github.com/anonymous/3f36dfeb3297e184417b#file-...](https://gist.github.com/anonymous/3f36dfeb3297e184417b#file-
poorly_formatted_dnssec_rubuttal)

