ietf
[Top] [All Lists]

Re: [ietf] DNS spoofing at captive portals

2010-09-25 19:25:31
[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