On Thu, 23 Oct 2014, Watson Ladd wrote:
With a modern browser, these two are pretty much the same thing due to
in-application caching. So for the discussion on feasability of
infrastructure, the argument is moot.
Decentralising caches could actually be worse for dns privacy, as
your query no longer stops in the big ISP pool to gain some anonymity,
but instead links straight to you with specific TTLs on your personal
cache expiry/re-fetch timers.
What's the threat model here? Is it that someone could be watching the
network above the ISP but not the link to the ISP from the local
machine?
That your query pattern when you open your laptop is not a unique
fingerprint on the net, because it stops and merges with other people's
queries in the ISP dns cache pool.
Of course, you can get the best of both worlds by using "centralised"
(read ISP) caches for your own caching (validating) server on
localhost. Thanks to DNSSEC, we can rely on untrusted "centralised"
caches. Of course that doesn't work for DNScurve because DNScurve only
solves one little aspect of DNS security (transport encryption) and at the
cost of not being able to use any non-local caches and pushing the crypto
load of transport security completely onto the authoritative servers
opening those up to CPU DOS attacks easier then quertying for ANY isc.org.
So the DNS server is now revealing queries to an attacker, and the ISP
cache is not? I fail to see why one is more trusted then the other.
This was not about trust, but about caching and not doing a DOS.
Furthermore, every person connecting to vanguard.com is forcing the
vanguard.com web servers to carry out an RSA 2048 decryption. Forcing
the vanguard.com DNS server to do a single Curve25519 operation per
visitor doesn't increase the potential for a CPU DOS attack: they
already have to solve that problem on their webservers, and in fact
are vastly more vulnerable.
Blowing a webserver offline and blowing an entire domain offline are
different emergencies. Losing your webserver doesn't lose your email.
Losing your nameservers, you lose everything.
(One could ask about root nameservers. But there isn't really a
difference between root nameservers and other DNS servers: they both
need to be adequately sized to deal with hoards of malicious traffic)
There couldn't be a greater difference between thousands of anycasted
root servers and my poor 3 nameservers.
I'm also surprised at how little common-sense perspective appears in
most discussions of DNS
I was surprised similarly, listening remotely to a CCC talk a few years
ago :)
I validated DJB's claims about the amplification potential of DNSSEC:
he gave a dig command, and sure enough, the response is many times
bigger than the query. The claims about performance are misleadingly
slow: at the cost of a 48 byte key, performance can be doubled on
commodity hardware. By contrast, claims that CPU load on DNS servers
will increase prohibitively with DNSCurve performance have been made
consistently over 8 years, with no evidence that they have been
updated or marked to market with increasingly fast CPU speeds.
unless CPU's became a million times more powerful in the last year,
I think the botnet still easilly wins.
There is a reason we tend to put defense measures into our protocols
before we have confirmed the source addres is not spoofed, such as
IKEv2 DCOOKIEs.
Claiming we need more numbers to "proof" that forcing crypto operations on
a handful of auth servers instead of that crypto load being decentralised
over millions of caching servers is just silly.
There is a very good reason we are looking at stub-recursve and
recursive-auth privacy relationships differently.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
