against dnssec: Is DNSSEC a Government-Controlled PKI?

Petr Spacek pspacek at redhat.com
Fri Jan 16 09:47:50 UTC 2015


On 16.1.2015 05:19, Richard W.M. Jones wrote:> On Thu, Jan 15, 2015 at
07:45:00PM -0500, Neal Becker wrote:
>> > I personally know nothing of the subject, but found this article, I
wonder if
>> > there's any truth here?  If so, maybe the push for dnssec on f22 isn't as
>> > wonderful as supposed:
>> >
>> > http://sockpuppet.org/blog/2015/01/15/against-dnssec/
> Considerable amount of commentary on this article here:
>
> https://news.ycombinator.com/item?id=8894902

Wow, it seems that DNSSEC topic joined The Flamewar Club and will have its
place next to "Windows x *nix" flamewars :-)

Tomas Hozza and me will be giving a talk/workshop about DNSSEC in practice at
DevConf 2015 in Brno. Join us and get your hands dirty instead of writing
hateful posts on the Internet! You will have a plenty of time for judging
after the first introduction and hands-on experience :-)
See http://sched.co/2Bet


Here I'm going to limit myself to clarifying the section
"DNSSEC is a Government-Controlled PKI"
from the article.

Disclaimer: I'm intentionally omitting *many* details here to make it concise.
Go ahead and read RFC 4034 and 4035 if you want to understand all the gory
details.


First of all, to some degree "DNSSEC is a Government-Controlled PKI" but you
need to understand few important details before you can draw informed
comparison with "classic" X.509 PKI.

- We can assume that US gov can force organization responsible for signing the
root zone (Verising) to sign fake version of the root zone, of course.

- In practice it would be hugely problematic to do such attack *on large
scale* because the root zone is served from a large number of servers *and
organizations* worldwide so it is very unlikely that a "fake" version of the
root zone would go unnoticed.

- If we limit the the attack to one target (organization/person) it would not
be so easy either. An attacker would have to feed the target with fake data
all the time because DNSSEC validation would fail if the client was confronted
with fake & "genuine" data at the same time.
(Again, go and understand DS/DNSKEY hierarchy described in RFC 4034 and do not
forget to consider which zones contain data 'useful' to an attacker.)


To sum it up - DNSSEC gives you Hierarchical trust model:
“my.example.net.” can be spoofed *only* by its parents:
- example.net.
- net.
- DNS root “.”

Now you are in position to compare DNSSEC+DANE with X.509 PKI: There were
1,482 CA Certificates trustable by Windows or Firefox in 2010 and any of them
could spoof TLS cert. (This list of CAs include surprises like a
state-controlled CA which never issued public facing certificate etc.)

More importantly, this spoofed cert is easily usable for very targeted attacks
(e.g. to a single TLS connection) and is extremely hard to detect by
unsuspecting client.

See https://www.eff.org/observatory for details about a TLS survey done by EFF.

I hope to see you at our DNSSEC workshop! http://sched.co/2Bet

-- 
Petr Spacek  @  Red Hat


More information about the devel mailing list