[techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed
Yuri Demchenko demch at chello.nl
Fri Feb 16 12:07:45 CET 2007
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 > >