
Looking for What’s Not There - fanf2
https://www.potaroo.net/ispcol/2019-06/nsec-cache.html
======
Abekkus
I keep seeing this argument that dnssec/dane puts more power in the hands of
registrars, which are not as trustworthy as CAs.

Aren't most TLS certs domain validated anyways? The current TLS practice
already puts full trust in registrars AND CAs.

Also, complaints that registrars can quietly change out sites without anyone
noticing, is pretending that we cannot watch the state of the DNS over time.
Don't we have certificate transparency already to solve a similar problem in
the WebPKI?

~~~
marcosdumay
Yes, on DNSSEC the people that can impersonate your site is a strict subset of
the people that can do so on TLS.

But I'm not sure certificate transparency will work as well for DNS as it does
for TLS. At least not without some changes (that are a good idea for many
other reasons) like permitting SRV for HTTP.

------
tptacek
Huston here concedes that the intended benefits of DNSSEC haven't panned out
--- TLS provides all the name authentication people want, browsers won't adopt
DANE to move CAs into the DNS (also, certificates are now free), mail
providers are doing STS instead of DNSSEC. It's hard to see an impetus for
deploying DNSSEC, and, of course, virtually none of the most important names
on the Internet are signed.

Huston suggests a new reason to deploy DNSSEC: it might stop a specific DNS
denial of service attack.

(The attack is trivial: you can just have a botnet make up random DNS names
and query them, saturating the authority servers.)

DNSSEC is designed around "offline signers", meaning that as originally
designed, it can't synthesize new DNS responses for queries. But it also wants
"authenticated denial", which just means you can cryptographically trust "no
such record" responses. That's problematic, because you can't predict the
nonexistent names people will ask you about, and you can't sign responses on
demand.

The way DNSSEC originally solved this problem was with "NSEC", which is a
record that states that no valid name exists between a lexicographically
ordered pair of names. You pre-generate the covering NSEC ranges for your
zone, and your servers can now authenticate the non-existence of any record.

(This addresses Huston's DOS attack by allowing DNS caches to NXDOMAIN queries
they've never seen before, because they've cached NSEC responses from
authority servers that state that there's no point in forwarding the queries).

There's an obvious problem here: attackers can also now enumerate precisely
all the hosts in your zone, which is an old feature of DNS (AXFR) that network
security teams have been frantically disabling for 2 decades. There's a whole
line of DNSSEC revisions that try to account for this fact, most notably
NSEC3, which uses a weak password hash to scramble the ranges (pretty
unsuccessfully). But the best-known mode of deployment for DNSSEC now involves
something called "whitelies", in which the DNSSEC server now simply becomes an
online signer and generates new ranges on the fly.

Which breaks Huston's proposal.

Mostly I think it's funny that anyone would try to motivate DNSSEC deployment
as a mitigation to a single species of DOS attack, especially when DNSSEC
itself is (fairly or not) itself notorious as a DOS amplifier (DNSSEC
responses are huge, so there's a pretty big packet magnification effect in its
deployment).

~~~
heavenlyblue
>>

Why doesn't DNS simply accept the fact that either:

1) your hosts are public

2) DNS is a stateful protocol and different clients _may_ see different
responses by server? (e.g. return false denials for unauthorized clients)

~~~
firethief
> 2) DNS is a stateful protocol and different clients _may_ see different
> responses by server? (e.g. return false denials for unauthorized clients)

Caching is what makes DNS usable. If you do this in a way that doesn't break
caching, it's not so simple.

------
rdiddly
I'm looking for what's not there: An informative title! Heh heh. Seriously
though, this might've been one of those rare occasions when improving on the
original title might've been warranted. Something like "The Value Proposition
of DNSSEC" or "Is DNSSEC Worth It?" (though the latter starts to sound like
clickbait)

For the record, the HN submission guidelines encourage changing the title if
it's misleading, but not if it's vague.

~~~
Abekkus
There was an informative title. Can't think of a good reason why it was
changed here on HN.

