NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Enrique Chaparro <[log in to unmask]>
Reply To:
Enrique Chaparro <[log in to unmask]>
Date:
Sun, 29 May 2016 13:38:53 -0300
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
As Paul Vixie says, “we've now spent more calendar- and person-
years on DNSSEC than was spent on the entire IPv4 protocol suite
(including DNS itself) as of 1996 when the DNSSEC effort began.
ugly, ugly, ugly.“[1]

DNSsec, a 20+ year old protocol[2] which causes more problems
than those it solves, has a low rate of adoption for many good
reasons. Two of them have been pointed out here: (a) the protocol
itself and its implemementations are brittle to say the least, and (b)
it's hard to deploy. Were it not by the stubborn posture of ICANN and
“the powers that be” in IETF, it shouldn't be deployed against the
advice of the infosec community.

I wouldn't bore you with the technicalities (there are many excellent
sources if you want to go into detail), but please let me write down
a little recab of the most serious objections against DNSsec:
* It is unnecesary
* It allows monopolistic/governmental control through a controlled
  PKI[3]
* It is cryptographically obsolete (and weak)
* It is expensive to adopt and deploy
* It is incomplete
* It goes against fundamental architectural principles.
We could also add, as somewhat less important drawbacks, that it
makes reflection attacks worse, and degrades server performance.

DNSsec is a nightmare, and since it has architectural failures, can't
be fixed to work properly. Should I recall the catastrophic APNIC
outage of 2016-03-15, which affected no less than 7381 autonomous
systems? Or the numer of TLD outages of the last six months,
incluidng inter alia .is, .mm, .bw, .az, .kia, .epson, .nec, ...? If you are
thinking about deploying DNSsec, my best advice would be “don't do it”.
Instead, make your best to convince the ignoramus at ICANN to review
their posture about mandatory DNSsec implementation for registrars.
Central authorities can’t solve the Internet trust problem. Central
authorities ARE the Internet trust problem.

Since I started with a quote, it seems adequate to finish with another
one, from Alex Stamos [4]: “DNSSEC is dead. It's over. I'm just telling
you now it's over. Don't put any of your future stock on DANE or any
security solutions that are based on DNSSEC. It's done.”

Regards from the Far South,

Enrique

[1] https://www.ietf.org/mail-archive/web/dnsop/current/msg13711.html

[2] And not well engineered even for those ‘romantic’ times

[3] DNSSEC’s  job is to replace the TLS CA system by DANE. No
meaningful security feature can rely on the trustworthiness of the CA
system, and the recent BlueCoat ‘incident’ shows how broken it is.
There's no doubt the X.509 TLS CA's infrastructure does need to be
replaced, but I can't imagine a worse replacement than DANE.

[4] https://youtu.be/-1kZMn1RueI

ATOM RSS1 RSS2