[techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed
Max Tulyev president at ukraine.su
Mon Feb 19 00:33:16 CET 2007
Seems interesting, but DNSSEC won't help in this case. Yuri Demchenko wrote: > 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 >> >> >