[I suspect you may know much of this, but just in case...]
On Sep 24, 2010, at 5:16 PM, John Levine wrote:
Plan A: few consumers will use DNSSEC between their PCs and the ISP's
resolver, so they won't notice.
In general, consumers won't be using DNSSEC between their PCs and ISPs. PCs
typically use stub resolvers and while there are ways to secure the
communication between the stub resolver and the ISP's (perhaps validating)
resolver, namely SIG(0) or TSIG, I don't know of any implementations that make
this easy enough for your average end user to use and in the case of TSIG,
(symmetric) key management will be a bear.
Given existing prevalent technology, you either trust your ISP and the
communication path between yourself and that ISP or you run your own validating
resolver. Note that if you take the latter route, you'll often find yourself
frustrated when you try to roam on services like T-Mobile Hotspot (you _must_
use their resolver for initial validation).
Plan B: consumers will observe that malicious impersonation of far away
DNS servers is rare and exotic, but malware spam arrives hourly, so they
will make a rational tradeoff, take their ISP's advice, and turn off
DNSSEC.
Not sure I see the relationship between malware spam and DNSSEC.
Given most validation occurs at the ISP, in the case of an actual
DNSSEC-preventable attack the end user will most likely get a friendly message
from their web browser saying "can't find the server" or perhaps bounced mail
because the destination email address didn't resolve. The end user will then
call the ISP and say "Internet's broke. Fix it!". In the cases where an
actual cache poisoning attack is taking place (which, I'm told, is actually
occurring thanks to scripts that implement the "Kaminsky Method"), the ISP end
user support staff can say "Hah! We protected you from Evil!". In the (likely
more frequent) cases where a signature has expired or there is some other
misconfiguration, the ISP end user support staff can say "try this IP address".
If the domain is popular enough, the ISP could even pre-populate their cache
with the correct IP address so they stop getting support calls. However, I
suspect if enough of the misconfiguration-variety of validation failures oc
cur, the ISP will get tired of the additional support cost and turn off DNSSEC.
Something else occurs to me:
Plan C: Sophisticated ISPs might configure their own DNSSEC key into
customer resolvers, and sign replacement records with that.
Given current technology, I suspect this would be rather unlikely since it
implies the customer is bright enough to set up their own validating resolver.
In such cases, I'd think the customer would question why their ISP is asking
them to use an ISP-specific trust anchor.
The threat model for DNSSEC has always been, approximately, that the
authoritative server at the far end is friendly, and the middleboxes
are hostile.
It's more that the authoritative server is ... well, authoritative and that
anything in between can't really be trusted.
But we have real situtations where the opposite is true,
quite possibly more often than the other way around.
Hmm. Are you talking about SiteFinder-like services?
If we want people deploying DNSSEC widely, we need to make sure it
handles the actual threats they face.
As I mentioned, I have been told by reputable sources that folks are actually
experiencing the Kaminsky method cache poisoning attacks, so that threat is
real.
The problem is that some folks have been trumpeting DNSSEC as a solution to
many problems when in fact, it solves a relatively rare (albeit real) attack.
All DNSSEC really does is ensure a DNS response hasn't been mucked with in
transit from the authoritative server to the validating resolver. DNSSEC can't
help you between the validating resolver and the originating requester if you
can't trust that path and it can't help you if you can't trust the
authoritative server.
DNSSEC may be used as a trustable infrastructure to allow folks to do other
things (see the keyassure proto-wg), but that's in the future...
PS: If I plug my random Windows PC or Mac into a cable modem, and I tell
it to use DNSSEC, where does it get the top level validation keys?
In order to use DNSSEC (at least today), you have to run a validating resolver
on your PC or Mac and you have to specify the trust anchor(s) in the name
server configuration file. The trust anchor you'd most likely want to
configure is available from http://data.iana.org/root-anchors/. Presumably, if
you're ambitious enough to figure out how to run your own validating resolver,
you'll be able to figure out how to add the trust anchor to your config file.
Or at least that's the theory...
Regards,
-drc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf