
Despite proposed solutions, DNS security issues remain - ohjeez
https://www.hpe.com/us/en/insights/articles/dns-security-still-an-issue-1810.html
======
tptacek
I don't think the author of this article is really familiar with its subject.
It's certainly _not_ the case that "any security expert you ask will recognize
the value of DNSSEC", or that we can all agree that it's a good thing. I'm far
from the only security person saying DNSSEC is a very _bad_ thing.

[https://sockpuppet.org/blog/2015/01/15/against-
dnssec/](https://sockpuppet.org/blog/2015/01/15/against-dnssec/)

The roundup of implementation hurdles is gratifying to see (I missed the LWN
article about it), since I think it's an under-appreciated cost of getting
DNSSEC deployed.

As always, the biggest obstacle to DNSSEC is that it solves a problem nobody
really cares about.

~~~
auslander
> solves a problem nobody really cares about

DNSSEC was designed to protect from using forged or manipulated DNS data.
Including all other records, like TXT, MX, CERT records, SSH fingerprints,
IPSec public keys and TLS Trust Anchors.

I care that I can verify all this.

~~~
tptacek
You're one of the few. And I can't imagine why anyone would want to enroll
their personal keys --- SSH, IPSEC, whatever --- into a global PKI. Your VPNs
and SSH connections are _more secure_ , objectively, outside of DNSSEC.

~~~
phicoh
Only if you have an out-of-band way of verifying SSH keys. In my experience, 9
out of 10 times that doesn't happen and people just accept a changed SSH key.

~~~
tptacek
So fuck it, let's let the United States Government cast the tiebreaking votes
when we're not sure?

------
skywhopper
> an attacker between you and your DNS server could determine which sites you
> are attempting to communicate with just by reading packets on the network.

This buys the attacker very little. If they can see the packets on your
network to read your DNS traffic, then they _already_ know what servers you
are communicating with.

~~~
vbezhenar
If you can see that I'm communicating with cloudflare IP, it doesn't tell you
very much. There are thousands of websites behind that IP. If you can see that
I resolved some specific domain to that IP just before I started to send
packets to that IP, you know probably I'm communicating with that specific
domain.

~~~
detaro
Currently, I can also just look at the packets you are sending to that
Cloudflare IP and read the domain you're asking for.

~~~
zamadatix
"you should fix that front right flat on your car" "yeah but there is a flat
on the front left so what does it matter"

This style response is what I keep seeing whenever a new security enhancement
to DNS and TLS is announced. Yes, today 2 things are broken... but that means
two things need to be fixed not that this new fix is foolish/useless/shouldn't
be implemented.

Now if you have particular takes against the way the problem was solved that'd
be a more serious conversation.

~~~
detaro
Fair enough, I probably deserve that response, especially since the TLS fix is
apparently closer than I thought.

DNSSEC brings quite a bit of complexity and potential to break things while in
a way further centralizing control (with CAs, at least there's multiple to
choose from), so without the second half it seemed like a small gain at high
cost.

------
poiu345
As long as DNS is insecure, Security Services can intercept and reroute IP
addresses to send people to the security services version of the internet for
brain washing. Installing a fake Certificate Authority on a computer through a
zero day remote exploit or domain server hijack from a compromised router
lulls users into thinking they are looking at genuine websites, but who knows
what secure websites are signed by Digicert or some other CA? Just because its
secure doesn't mean its not fake. IEEE standards are woefully inadequate and
not joined up, but then one of the largest companies in the world namely
Microsoft took 17years to roll out Address Space Layout Randomisation in
Windows 10, coupled with Intel pursuing speed over security something which is
mutually exclusive due to their chip designs, something ARM recognised a long
time ago, so is it any surprise that the IEEE standards are where they are
today? If you want to get a headups about what exploits are a problem get
involved with the IEEE to find out what standards they are trying to improve
to solve some hacking problem. The window of opportunity is open as long as
the IEEE takes to finalize a standard.

In the mean time Happy Hardware Hacking because you know your existing
security methods cant detect it, but your CPU fan may be the only indicator
you have that some malware is running alongside your OS, in a
QubesOS/Hypervisor style manner with a coreboot/libreboot bios gone rogue.

Prove me wrong!

~~~
Leace
> As long as DNS is insecure, Security Services can intercept and reroute IP
> addresses (...)

> (...) but who knows what secure websites are signed by Digicert or some
> other CA?

Well, what would be that "secure DNS" in your opinion?

If you assume someone can subvert Digicert would they be able to subvert that
"secure DNS" too?

~~~
skywhopper
FWIW, this is the attack that DNSSEC is meant to prevent.

~~~
Leace
Not if "someone [who] can subvert Digicert" is government/state. In this case
they have an easier task as governments directly control DNSSEC signing keys,
and subverting Digicert and issuing rogue certs would be visible in
Certificate Transparency logs.

~~~
dane-pgp
Governments directly control the DNSSEC signing keys for their ccTLDs, but at
best indirectly control DNSSEC signing keys for some gTLDs. The US government
could, for example, use some legal instrument to compel a US-based CA to issue
a certificate for an arbitrary domain, and similarly compel a US company like
Verisign (who manage the .com gTLD) to change the DNSSEC records for a .com
address.

The big differences are 1) you can choose a domain under a gTLD that isn't run
by an American company (or other country that is part of your threat model),
2) you can choose to run your own gTLD (at a certain cost), 3) admittedly
Certificate Transparency for CAs is much further along than CT for DNSSEC,
you're right.

[https://tools.ietf.org/html/draft-zhang-trans-ct-
dnssec-03](https://tools.ietf.org/html/draft-zhang-trans-ct-dnssec-03)

~~~
tptacek
I don't understand how people make this argument with a straight face. Google
cannot simply abandon .COM. The most commercially important domains in the
western world are all controlled by Five Eyes governments.

~~~
dane-pgp
Google already do abandon .com for localised search in individual countries,
and most people aren't actually typing "google.com" to find the search engine
(it's probably a browser setting).

Also, I don't understand how you can pick Google as an example with a straight
face. The most commercially important websites in the western world are all
run by companies that are controlled by Five Eyes governments.

~~~
tptacek
If you think "give up on .COM, .NET, .ORG, .UK, .IO, .CA, .AU, and .NZ" is a
reasonable response to this problem, why stop there? Virtually everyone agrees
DNSSEC isn't a great protocol; had it been designed in 2010 rather than in
1994, it would for instance take advantage of online-signing, like every
modern cryptosystem does. Why not just go all the way to something like
NameCoin? You've already given up on, basically, "the Internet" as people know
it.

I'm not even opposed to that! (I'm not a fan of NameCoin, or any-coin at all,
but whatever). I just think, be coherent about things.

~~~
dane-pgp
If your threat model includes the threat that Five Eyes governments will try
to (legally, or otherwise) commandeer the DNSSEC infrastructure (and, more
easily, the CA system) to actively attack users accessing your server, then it
is perfectly reasonable to "give up on .COM, .NET, .ORG, .UK, .IO, .CA, .AU,
and .NZ". Under such a threat model it would also be prudent to never visit a
Five Eyes country, or hold any assets there.

Depending on your use case, a better approach might be to host your server in
the Tor network, in which case NameCoin would indeed make some sense:

[https://www.namecoin.org/2017/06/22/tor-
prop279-release.html](https://www.namecoin.org/2017/06/22/tor-
prop279-release.html)

