
ICANN Calls for DNSSEC for All Domains Following Domain Hijacking Attempts - teddyh
https://www.icann.org/news/announcement-2019-02-22-en
======
geofft
This is nonsense, and possibly crossing the border from ignorant nonsense to
malicious nonsense.

DNSSEC ensures that received DNS records are signed by an entity authorized to
publish changes to the domain. It does not ensure, in any way, that this
entity is publishing the right changes. It protects you against man-in-the-
middle attacks, but not "hijacking" as usually envisioned. The linked article
[https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-
recen...](https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-
widespread-dns-hijacking-attacks/) identifies multiple cases of registrars
saying that someone broke into their web interface (either by determining
valid account credentials, or finding a flaw in the web interface). DNSSEC is
not designed to protect against these attacks. As that article points out,
_some of the victims did in fact have DNSSEC set up_.

As 'tptacek pointed out a few days ago, many .gov and .mil domains _have_
DNSSEC and were nonetheless victims of DNS hijacking attacks.
[https://news.ycombinator.com/item?id=19180817](https://news.ycombinator.com/item?id=19180817)
The US government is correctly _not_ insisting on additional rollout of
DNSSEC.

I myself have been a victim of DNS hijacking: in January 2013, someone
hijacked mit.edu and (among other things) redirected the MX records to non-MIT
servers.
[https://thetech.com/2013/01/23/hack-v132-n63](https://thetech.com/2013/01/23/hack-v132-n63)
I lost email to my mit.edu address as a result, and if the attacker were
interested in targeting me (or targeting MIT account holders in general) they
could have triggered password resets by email, etc. They got in because they
apparently knew the password for MIT's account at EDUCAUSE, domain registrar
or guessed it on the first try. DNSSEC would not have prevented this. The
attacker would have simply instructed EDUCAUSE to sign the records, or
instructed EDUCAUSE to update the public key to one under the attacker's
control.

And, for bonus points, had they done so, they likely would have been able to
lock out MIT of regaining control of the domain for longer than it actually
took.

~~~
rocqua
As long as domain validation is the standard for getting certs, the security
of the DNS system will be part of the security of DNS.

At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We
need that authentication between the DNS servers and the Certificate
Authorities. DNSSEC between the DNS server and hosts doesn't matter much.
There are other ways to MitM, and insecure fallback is inevitable.

In the end, the DNS system is what we use for identity management, so it
should be authenticated. As the recent attacks have shown, the actual
administration of the DNS servers (Registrars) also needs to be secured. That
is not DNSSEC's role.

But in our current system, if a registrar is compromised, the system is
compromised anyway. I'd love to hear an idea that obviates the need to trust
Registrars. Without such an option, I don't think 'this doesn't defend against
DNS account hijacking' counts, because nothing defends against DNS account
hijacking.

Once someone has that account, you are fucked. HPKP is essentially the only
thing that could save you, and that has (rightly) been deprecated.

~~~
tptacek
There is in fact very little evidence that we "need" the authentication
provided by DNSSEC. Here we have an illustration of a phenomenon we've seen
repeatedly: an attack for which DNSSEC has absolutely no utility, used
deceptively as an argument for the necessity of DNSSEC. The same was true of
claims that DNSSEC was a necessary response to BGP hijacking a few months ago.

If there were actual routine attacks that DNSSEC was seriously defending
against, you don't think its advocates would be sounding their trumpets about
them incessantly? Occam's Razor argues emphatically that the attacks DNSSEC
deals with aren't occurring.

Meanwhile: if the reason we need DNS security is for certificate issuance,
_DNSSEC is a stupid way to get that_. We can and will create a secure channel
directly between CAs and registrars (one such system is RDAP, the upcoming
replacement for WHOIS). We also have systems in place that have demonstrably
defeated misissuance, most notably certificate transparency, which does not in
any way depend on DNSSEC. CAs can and will do multi-perspective DNS lookups,
which are valuable (though imperfect) even against the BGP attacks that
completely bypass DNSSEC.

The history of Internet network security is largely the history of higher-
layer systems routing around the insecurity of DNS; an insecure DNS is
practically the premise of Internet security. And throughout that entire
history, going all the way back to when I was in high school in the early-mid
1990s, DNSSEC advocates have been trying to foist this boondoggle of a
protocol onto us. It was annoying when it was just a bad cryptosystem that was
impossible to configure. But now it's a key escrow system as well. Fuck that.
DNSSEC is still failing. Let it fail all the way away.

~~~
dcow
I get it, it’s cool to shit on DNSSEC. But let’s talk about defense in depth.
The way you solve account hijacking is two fold. First: authenticate records.
Second: don’t trust registrars to produce the contents of records. Reduce
registrars to a simple ledger indicating which key to trust for a domain along
with the length of the lease. Make people take care of their keys. If a
registrar does offer to sign records on an owner’s behalf, maybe don’t use it
for security critical services like email.

I don’t think the desire to authenticate data coming from the internet’s
global public key-value store is ludicrous.

~~~
tptacek
Every useless security product ever pitched has justified its existence with
"defense in depth".

~~~
dcow
Let's just secure the perimeter and live in a world of VPNs and negligently
open hosts. I'm not strictly arguing that _DNSSEC_ is a good thing. But I do
think it makes sense to authenticate data flowing across general networks, no?
You're saying the problem isn't a problem because part of the solution is
stupid today. I guess it's job security for security professionals to have
insecure things floating around that need additional security? At least some
people want to solve the problem. The internet as it exists today being
engineered around insecure DNS is _not_ a feature. Name one other scenario
where there's a preference for no security.

People used to say the same thing about the boot process. Now we have secure
boot. Maybe that's just stupid too but I feel a lot better knowing that my
hardware is booting verified images than whatever happens to be sitting at
some address in unprotected memory (as long as I remain the owner of the key).

~~~
tptacek
Let's not have negligently open hosts _or_ DNSSEC. In fact: that's pretty much
what competent operators do today. See! No changes needed.

------
jaas
DNSSEC doesn't help when the attacker controls your DNS control panel, just
like DNSSEC doesn't help in almost every other practical attack scenario.

Let's kill it off and focus on efforts that solve real problems. It's worse
than pointless, the added complexity is a huge liability.

~~~
kadendogthing
>Let's kill it off and focus on efforts that solve real problems

Like what? It's pointless to distract from constructive proposals with no
supporting material for what the problems are with the proposed solution, and
then claim there are other things that need our attention and then not even
pay lip service to them.

~~~
jcranmer
DNSSEC is quite famously a solution in search of a problem. It's pretty
explicitly designed to secure the requests from the resolver to the
nameservers, not from the actual end-users--and the number of _actual_ attacks
that would be prevented as a result are pretty damn minuscule.

~~~
kadendogthing
>DNSSEC is quite famously a solution in search of a problem.

I've only seen this sentiment every now and then in very particular circles.
It's not really that famous.

~~~
tptacek
Here's a fun exercise: find the most reputable security or cryptography person
you can that has publicly said nice things about DNSSEC. For extra fun, try to
find one that isn't in some way affiliated with the IETF (most security and
cryptography people aren't, so that shouldn't be too hard).

~~~
kadendogthing
Well I don't know about people but I do know that a lot of big names in
networking support and enable DNSSEC by default. So again, the sentiment isn't
that famous because it's a widely used security feature. named has it on by
default.

Here's a fun exercise: You could just say what you need to say to make a point
and educate the people reading this thread. Otherwise your comment is kind of
detracting from constructive conversation.

~~~
nothrabannosir
It was the first thing he said: there are very few real attacks that DNSSEC
protects against. In other words: the benefit does not outweigh the cost.

That is a damning argument and there is nothing else to say, until someone
(e.g. you, but don't feel pressured) comes forward with a good counter
example.

~~~
kadendogthing
> there are very few real attacks that DNSSEC protects against.

That's not a very good argument when you're talking about securing systems. We
don't actively mitigate attacks based on the prevalence of known instances of
that attack. You do so beforehand. Attack vectors, before they are ever or
even actively used, are considered. The most relevant, recent, and well known
example of this is heartbleed.

~~~
tptacek
Your best example of an attack mitigating by deploying a languishing IETF
standard is Heartbleed, which was caused by the adoption of a languishing IETF
standard extension to TLS.

~~~
kadendogthing
Heartbleed was caused by a class of code error prevalent in the toolchain used
to write that code. It was not caused by the specification itself.

Here is the exact change if you're able to read the code:
[https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h...](https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902)
\-- if that is not within your skillset to read that change, the patch is
essentially doing a bounds check on a set area of memory. The language being
used is notorious for allowing this type of code error and is the source of
many exploits and bugs. It has nothing to do with the specification.

For some reading material see this wikipedia article on the subject:
[https://en.wikipedia.org/wiki/Buffer_over-
read](https://en.wikipedia.org/wiki/Buffer_over-read)

>Programming languages commonly associated with buffer over-reads include C
and C++, which provide no built-in protection against using pointers to access
data in any part of virtual memory, and which do not automatically check that
reading data from a block of memory is safe; respective examples are
attempting to read more elements than contained in an array, or failing to
append a trailing terminator to a null-terminated string. Bounds checking can
prevent buffer over-reads

We mitigate against attack vectors before there are known instances of
software using those attack vectors. I'm not sure why you want to argue
against that, or even how because we do it all the time. Take Spectre/Meltdown
as another example. Preemptive measures were taken before any known usage of
that attack vector had been discovered.

~~~
jcranmer
You're missing the point. The TLS heatbeat feature is a feature that is wanted
by essentially nobody. Adding support for it means you're adding code--which
naturally has the potential for bugs--to a server install, which increases the
scope for vectors. Furthermore, as an underused feature, it's not going to get
the same amount of code review as more heavily trafficked portions of the
codebase.

Sure, the actual _bug_ is a coding 101 bug, but the social process that caused
a coding 101 bug to potentially compromise the vast majority of server
installations is why Heartbleed is important. One of the lessons is that you
need more reason to implement a feature than "it's a feature that can be
implemented."

~~~
kadendogthing
> You're missing the point.

I don't think I am. You're focusing on one particular thing and invoking
platitudes that are completely irrelevant. You're actively attempting to
change the conversation topic to fit your viewpoint. That's not okay. No one
is talking about the philosophy of feature development and adoption. I gave
another example of where we preemptively mitigate issues that has nothing to
do with philosophical waxing on "did we really need to do this" or "nobody
really wanted that feature": Specter/Meltdown.

So two things, to get this conversation back on track:

1) The idea that DNNSEC is worthless/useless/bad is not "famous" by any
reasonable use of that term. I explicitly stated it was only something you see
in particular circles. The fact that the actual most popular piece of software
used to manage DNS enables DNNSEC by default, and one of the biggest 3rd party
public providers for DNS has it opt-out only is a testament to this fact. It's
myopic to think that other people are aware of these things when the entire
ecosystem is signaling quite the opposite.

2) DNSSEC might be useless, but in abstract terms arguing against systems
designed to mitigate attacks simply because those attacks haven't been seen in
the wild is a bankrupt idea in the world of security. So if you want to say
DNSSEC is a bad idea then stick with that, but don't say it's a bad idea
because we haven't seen an actual attack with what DNSSEC is trying to
prevent. The claim again, is bankrupt when you're talking about securing
systems.

>but the social process that caused a coding 101 bug to potentially compromise
the vast majority of server installations is why Heartbleed is important.

I actually want to speak to this, because it's kind of a popular thing to say
in the world of software development, but it fundamentally misunderstands
what's actually happening.

You're right that a social process allowed the coding 101 bug to happen and
exist for so long, but you're wrong about which social process. People's
motivations for a feature have no bearing on how exploitable code gets
written. Because features that people _do want_ are victim to the same kind of
errors in code. If you immediately falsify your perspective about which social
process is in play you see it becomes irrelevant. You can completely take
people's motivations out of the equation and the same process and class of
error exists that allows the exploits and bugs to happen.

I am _not_ saying that increases in LOC does not correlate with an increase in
bugs. That's a fairly standard fact. I am saying that people's motivations for
features have no bearing on how open source projects fall victim to shoddy
code.

The social process that IS to blame is the fact that people don't invest in
open source software, yet depend on it for their entire ecosystem. A student
wrote some code, submitted it, and it was reviewed by one person. That code
was never really looked at again, not really tested, but allowed to exist in
the software for years. If the social ecosystem around open source software
was one where more eyes had been laid on the code created it might not have
happened all together, and relying on a student to write the code is a
travesty in its own right all together.

But people's motivations for writing code? Not really relevant in terms of
LOC, exploits, and code quality.

~~~
pvg
_is not "famous" by any reasonable use of that term._

You're getting really hung up on "famously" which doesn't even literally mean
"is famous". If that's your #1 point, you might as well drop it and move on to
something else.

~~~
kadendogthing
You need to read the thread.

~~~
pvg
Sadly, I have.

------
hodo
Nominet, the UK's domain registry, has a solution called "Domain Lock".

Whilst predominantly offered to registrars it is also available directly to
registrants for the equivalent of $120 per year.

Assume a user has a domain name registered with their preferred registrar,
e.g. Gandi, GoDaddy etc., then to change the DNS settings the user has to
login to his Nominet portal (using mandatory 2SV) and unlock the DNS for up to
20 minutes (it can be manually re-locked earlier). The user then has to log
into his registrar (preferably with 2SV set-up) and configure the relevant
changes.

The additional steps involved are sufficient to prevent almost all
unauthorized DNS changes except DNS poisoning.

Nominet say that their separate "DNSSEC signing service was withdrawn from
service in January 2016 due to low uptake".

------
tptacek
The best part of this is that ICANN has misconfigured DNSSEC.

[https://twitter.com/__agwa/status/1099782458046705669](https://twitter.com/__agwa/status/1099782458046705669)

~~~
Abekkus
The tweet you linked to is making false claims about dnssec. It doesn't "blow
up the sizes of dns requests" If you aren't explicitly looking up dnssec
signatures, a signed zone's responses will be the same length as an unsigned
zone's responses.

Also, dnssec for their real website, icann.org, is properly configured.

~~~
agwa
> The tweet you linked to is making false claims about dnssec. It doesn't
> "blow up the sizes of dns requests" If you aren't explicitly looking up
> dnssec signatures, a signed zone's responses will be the same length as an
> unsigned zone's responses.

Unbound 1.6.0, BIND 9.9.5, and Google Public DNS all set the DO bit in their
queries even when there's no DS record in the parent zone, so the DSSEC
records will indeed be included in responses.

And that's not even addressing the amplification risk.

> Also, dnssec for their real website, icann.org, is properly configured.

Are you disputing that ICANN owns and operates icann.com?

------
move-on-by
As much as I want DNSSEC to be a thing, it just doesn’t seem like it ever
will. Checkout this name-and-shame site and you’ll see how hopeless it looks
[https://dnssec-name-and-shame.com](https://dnssec-name-and-shame.com)

~~~
jaas
Why do you want it to be a thing? Have you ever been exposed to an attack that
would have been prevented by DNSSEC?

I feel like most people who want DNSSEC just have very theoretical warm
feelings about the idea of it. When they actually implement it it does nothing
but consume time and energy while adding liability.

~~~
move-on-by
I don’t think I’ve ever been exposed to an attack that the HSTS preload list
has protected me from, but that does not negate its value. Assurance is an
important aspect of InfoSec. Without a doubt DNSSEC has some major
shortcomings and the lack of implementation makes it useless, but that does
not mean it would not provide value if it were more widespread

~~~
Quekid5
You're ignoring the possibility of _negative_ value. People ITT have been
saying repeatedly that DNSSEC provides negative value, i.e. that the effort is
vastly out of proportion with any benefit that could be derived from it. They
aren't necessarily saying that there is (absolutely) no benefit.

------
tynes
Handshake (handshake.org) provides an SPV Proof that the DNS records held in
it's zone are authentic. This means if an attacker wanted to spoof records,
they would have to:

1) Eclipse attack the client, meaning that the client is on a partitioned
network with an alternative chain tip. This grows more expensive as the
records were written further in the past

or

2) Steal the top level domain owners private key and update the database

~~~
geofft
If a major brand is bad at managing private keys and is in the middle of an
ownership transition (speaking _entirely hypothetically_ , of course), is
there a chance that they'd just lose access to symantec.com permanently and
have to pick a new brand, instead of having recourse to humans to say "Hey
please get us our domain"? If there is no recourse, is this generally
considered a desirable thing by domain customers?

Is there a process for trademark dispute resolution? If not, is this generally
considered a desirable thing by domain customers?

If the answer is yes, who holds the override keys?

~~~
tynes
User experience around key management is poor. I agree that it needs to be
improved, Handshake supports the industry standard HD Key Derivation following
bip44 and has Ledger Nano support. The keys can be derived deterministically
from a mnemonic, so it's up to the org to not lose that mnemonic. Eventually
(if blockchain actually works) there will be an easy to use protocol for
breaking the mnemonic up into shares and allowing recovery of the mnemonic
using m of n shares.

In the case where keys are lost, there are 2 options

1) Let the domain expire after 1 year, there is a protocol rule in which the
domain must be updated and without the private key it would be impossible to
update it, and then rebuy it

or

2) Gain support from the community and fork the protocol such that the domain
is reassigned to a different private key

There is a process for trademark dispute resolution, it's been going on for
awhile now. The Alexa Top 100k domains are reserved and can be claimed using a
DNSSEC Proof, so dot google on Handshake can be claimed by the owner of google
dot com

~~~
lokedhs
I have to say that that sounds like a solution no user would actually want.
You effectively did answer all of GP's questions with no.

------
markwakeford
While AWS supports DNSSEC for domain registration they don't support it for
DNS. While it does appear that most of these attacks would not have been
prevented by DNSSEC isn't it about time AWS supported DNSSEC ?

~~~
throwawaymath
If these attacks wouldn't have been prevented by DNSSEC, why do you want AWS
to support it?

------
ryanlol
None of these domain hijacking attempts would’ve been prevented by DNSSEC,
right?

(Also kinda curious as to why pointing this out seems to be somewhat
controversial? :)

~~~
bluejekyll
As I understand the attacks being against the login admin accounts for
managing the domain itself, no DNSSEC would not have prevented changing the
records in the zone. In addition, if the DNS provider hosting that domain
automatically resigned the zone for the hacked account, then the hosting
company would even have resigned the zone, thus making valid DNSSEC entries
anyway.

What would be better is to require 2FA for all zone hosting companies.

~~~
regecks
> What would be better is to require 2FA for all zone hosting companies.

Even with this, many registrars and DNS hosts are too fast and loose with
disabling 2FA when you call them up and tell them you lost your second factor.
Alternatively, requesting changes over the phone without going through web
authentication. My confidence in 2FA dipped quite a bit after going through
the experience myself.

------
firekvz
I just submitted a link for a recent DNS attack on .com and .ve ccTLD domains,
any chances that this:

> On 15 February 2019, in response to reports of attacks against key parts of
> the DNS infrastructure..

Is related to said attack ?

heres the link for the dns attack by venezuelan gov

[https://news.ycombinator.com/item?id=19240685](https://news.ycombinator.com/item?id=19240685)

it's worth a read

------
acdha
Does anyone know the story behind this quote:

> This particular type of attack, which targets the DNS, only works when
> DNSSEC is not in use.

That doesn’t match any description I’ve seen of these attacks where the
attacker had the same access to the management infrastructure as legitimate
users. Is there some other incident being discussed or is this just
fundamentally incorrect?

------
gist
Although ICANN has dns sec implemented correctly on icann.org they don't have
it done correctly on icann.com which redirects to icann.org

Also most FAANG companies do not have dns sec implemented at all (or
correction).

There are various ways to check this but the easiest is to simply pull a
whois.

~~~
tptacek
No FAANG company implements DNSSEC.

------
wav-part
Call it DNSSEC or whatever, DNS needs more crypto. At present security of DNS
rely on manual intervention, 2FA, "multi-perspective DNS lookups" and other
rituals. That does not scale to 250M domains. Expect more hijacks until then.

------
ngcc_hk
DNSSEC use another chain of “ca”, not the root ca like those in browser. It is
another complexity. Not sure it help in general and as said here not even dns
hijicking. What is its point is still not sure.

~~~
tptacek
Worse, those "additional CAs" are de facto and in many cases de jure
controlled by world governments, many of whom (including my own) have
demonstrated repeatedly their willingness to tamper with the DNS to achieve
policy goals.

------
godzillabrennus
This is not a new problem.

There was a somewhat high profile theft a few years back where the owner
published how they recovered their domain:

[https://www.forbes.com/sites/theyec/2015/02/28/how-to-
recove...](https://www.forbes.com/sites/theyec/2015/02/28/how-to-recover-from-
a-domain-name-hijacking/)

------
hannob
So erh a bunch of accounts get hacked, likely due to password reuse, weak
passwords or phishing. But hey, it's about DNS and security, so let's push the
dead horse DNSSEC, which would've done nothing to prevent this, because...
whatever.

------
badrabbit
Even if your account is compromised,do they store the DNSSEC private keys for
your domain? That maybe the issue here,requiring domain owners to generate the
signature on their local computers seems to be a solution. What am I missing
here?

------
basicplus2
Who benefits from forcing DNSSEC?

~~~
throwawaymath
If you mean this question in the cynical sense, then basically anyone who will
be selling DNSSEC services to large enterprises benefits. And those services
will probably be expensive.

------
ietf-dane
[https://blog.aurynn.com/2015/12/16-contempt-
culture](https://blog.aurynn.com/2015/12/16-contempt-culture)

------
philip1209
Would wifi portals work in a world where DNSSEC was enforced?

~~~
pas
sure, they would just hijack the outgoing TCP port 80 connection when you try
to open a non HSTS domain. (and of course it could try to a port 443 with a
fake cert thing too.)

also, there can be standardized portal lookup/discovery methods (this RFC has
already expired, but it's likely that the effort will continue:
[https://tools.ietf.org/html/draft-pfister-capport-
pvd-00](https://tools.ietf.org/html/draft-pfister-capport-pvd-00) this seems
to work with IPv6 only, as it builds on ICMPv6 Router Advertisement, but
"provisioning domains" could simply be a DHCP data type too)

~~~
phicoh
See RFC 7710 for DHCP, DHCPv6 and RA options:
[https://tools.ietf.org/html/rfc7710](https://tools.ietf.org/html/rfc7710)

------
acd
It works if you require DNS sec on servers and clients. If you allow fall back
to non dnssec it does not work.

------
sprash
Apparently ICANN seems to be a rather corrupt organization:
[https://freebeacon.com/issues/internet-group-icann-
boosted-m...](https://freebeacon.com/issues/internet-group-icann-boosted-
member-transfer-u-s-tech-iran/)

What happened to namecoin?

~~~
realusername
I would personally also prefer a solution like namecoin going forward, having
one organisation centralising the whole name system is starting to show it's
limits (that and the fact that DNS wasn't a great design from the start).

------
avip
What are _unsecured domain names_ in this context?

~~~
swinglock
I presume it means domains names without DNSSEC.

~~~
avip
My impression was DNSSEC is something you apply to participants of DNS
resolution (DNS server and resolvers), not to "domain names".

~~~
swinglock
It won't do much if the domains are not signed.

------
mrmondo
Mods: this is the direct link to the article at ICCAN:
[https://www.icann.org/news/announcement-2019-02-22-en](https://www.icann.org/news/announcement-2019-02-22-en)

(Also the current third party link doesn’t seem to load (for me) ‘Resource
Limit Exceeded’)

~~~
dang
Ok, we changed the url to that from
[http://www.domainpulse.com/2019/02/23/icann-dnssec-
unsecured...](http://www.domainpulse.com/2019/02/23/icann-dnssec-unsecured-
domains-hijacking-attempts/).

~~~
mrmondo
Thanks Dang

------
nhumrich
Maybe this will get route53 to finally add DNSSEC

