[dns-wg] What about the last mile, was: getting DNSSEC deployed

I think this will not be too much off-topic.

What does DNSSEC and Techsec-WG people think about recently revealed 
pharming attack technique that is based on the end user DNS altering?

NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS
Millions of high-speed Internet users across the globe are threatened
by a new attack technique called drive-by pharming, Symantec and
Indiana University researchers warned Thursday.
http://go.techtarget.com/r/1004039/1401570

On the practical note, I need to say something definite to my students 
what DNS experts think?

Thanks.

Yuri

Roy Arends wrote:
> Lutz Donnerhacke wrote on 02/16/2007 10:20:09 AM:
> 
>> * Roy Arends wrote:
>>> Lutz Donnerhacke wrote on 02/16/2007 09:24:33 AM:
>>>> You can run a caching validating on your own system.
>>> Isn't that what I was saying ? I just don't want to do all the 
> recursion.
>>> My ISP's resolver can do that.
>> So use it for this.
> 
> I just explained why I don't want to do that.
> 
>>> not really. I can also validate on a stub resolver.
>> I wouldn't call this "stub". A stub resolver is a protocol translator: 
> It
>> offers an well known API to well known protocol. It does nothing more of 
> the
>> protocol itself.
> 
> I'd call this a "security aware stub resolver" (rfc 4033, section 2).
> 
>>>> Following this proposal in the blog, DNSSEC is dead.
>>> Tell me Lutz, how does joe end user run a full featured validating
>>> resolver daemon, when he barely understand the concept of DNS.
>> The end user has a stub resolver pointing to a trustwothy validating 
> one.
>> It's this plain simple. If you want to break this behavior, DNSSEC is 
> dead.
> 
> explain to me how DNSSEC is dead by doing validation on a stub resolver.
>  
>>> If he shouldn't run this, how does he setup "a established link to an
>>> authenticated resolver". You're not really referring to just an bunch 
> of
>>> addresses in some resolv.conf or equivalent, since thats hardly an
>>> established link. The ISP's resolver hardly knows who's talking to it.
>> I'm responsible for DNS at an ISP: The ISP's resolver know who queries 
> it.
> 
> So, what do you offer to your clients? SIG(0), TSIG, DTLS, some VPN method 
> ? How many clients have configured that ?
> And with 'who queries it', you probably mean that you have some list in 
> place somewhere that discriminates on ip. Note that I can simply passive 
> query your resolver box. You wouldn't even know it is me. 
>  
>>> Now, lets assume for a sec we don't run into scaling issues, since the
>>> "authenticated resolver" needs to do some crypto for the "established
>>> link", while doing some crypto to validate messages.
>> DNSSEC validating on a larger resolver does scale well, because - that's 
> the
>> important observation I made - a lot of queries can be answered from 
> cached
>> NSEC records without querying further. The whole bunch of NXDOMAIN 
> dropped by
>> about 70% here. Crypto is cheap compared to networking.
> 
> I find those last two statements highly unlikely, but for argument sake, 
> multiply this by cost(crypto(lastmile))*count(users).
>  
>>> Why should I trust data, validated by my ISP?
>> Because you choose him to do so.
> 
> Eh ? No, I rely on it to bring me the data. I'll validate it myself, thank 
> you very much.
> 
>>> Them ISPs route me to a search page, while I should've received an
>>> NXDOMAIN. but, no fear, the 'ad' bit is set, and I can just blindly 
> trust
>>> my ISP, while they're cashing (no typo) in on my unfortunate
>>> misspellings.
>> If you do not trust your ISP, you need an other one or you won 
> validating
>> protocols i.e. VPN to a trustwothy point.
> 
> "trust" is not a binary concept. You need to relate trust to a service, 
> and then still, it comes in degrees. I trust my bank to process payments. 
> I trust my ISP to keep my link alive and to have proper peering in place. 
> I _could_ trust my ISP to serve me the right data, but that would only be 
> the right data in their perspective, wouldn't it, and that might not match 
> mine.
> 
>> DNSSEC for end users is not a security issue, it's a deployment issue.
> 
> Eh ?
> 
> DNSSEC is security backfitted on a widely deployed protocol. This has 
> deployment issues in general.
> 
> Roy
> 
>