Re: [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
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 This method is variation on the team to users equipment as a coprocessor. In this case, a java applet tries to guess the passwd of the users adsl router and then reconfigures the dns server in the box. Most users have not chnged the original passwd (if an) or use an easy tp gues one. More details got dicussed on nanog. On the practical note, I need to say something definite to my students what DNS experts think? Tell then to switch of java etc. :-). As noted, dnssec can protect against spoofed dns info. jaap
NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS
...
As noted, dnssec can protect against spoofed dns info.
Except DNSSEC wouldn't really be applicable. The attack (as I understand it) provides a new IP address (that of an attacker-owned caching resolver) to clients on a LAN attached to the broadband router, with the attacker-owned caching resolver returning answers to stub resolver queries. Since validation is done at the caching resolver, DNSSEC wouldn't apply. Rgds, -drc
David Conrad wrote:
NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS
...
As noted, dnssec can protect against spoofed dns info.
Except DNSSEC wouldn't really be applicable.
The attack (as I understand it) provides a new IP address (that of an attacker-owned caching resolver) to clients on a LAN attached to the broadband router, with the attacker-owned caching resolver returning answers to stub resolver queries. Since validation is done at the caching resolver, DNSSEC wouldn't apply.
It would apply in the (theoretical) subset of applications that are configured to rely on signed and validated responses, like hopefully windows/osx/mozilla/other software updaters could be configured to do. It could also apply to an even more theoretical future browser feature that uses a mechanism similar to the shiny gold SSL padlock icon to indicate a signed and validated response, but the value of that would be limited to the subset of users who wouldn't just click "go to the site anyway" like they do with SSL warnings now. Doug -- If you're never wrong, you're not trying hard enough
On Feb 16, 2007, at 12:50 PM, Doug Barton wrote:
David Conrad wrote:
NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS
...
As noted, dnssec can protect against spoofed dns info. Except DNSSEC wouldn't really be applicable. It would apply in the (theoretical) subset of applications that are configured to rely on signed and validated responses, like hopefully windows/osx/mozilla/other software updaters could be configured to do.
The question is how do they get the information that the data has been signed and the signatures validated. Since with this attack they'd be going through a compromised server, they lose. The only way out of that hole is if you run a local validating caching server and have appropriate (out-of-band validated) trust anchors configured and if you're running a local caching server, you're already not susceptible to the attack. Rgds, -drc
David Conrad wrote:
On Feb 16, 2007, at 12:50 PM, Doug Barton wrote:
David Conrad wrote:
NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS
...
As noted, dnssec can protect against spoofed dns info. Except DNSSEC wouldn't really be applicable. It would apply in the (theoretical) subset of applications that are configured to rely on signed and validated responses, like hopefully windows/osx/mozilla/other software updaters could be configured to do.
The question is how do they get the information that the data has been signed and the signatures validated. Since with this attack they'd be going through a compromised server, they lose. The only way out of that hole is if you run a local validating caching server and have appropriate (out-of-band validated) trust anchors configured and if you're running a local caching server, you're already not susceptible to the attack.
I was thinking similar like home routers could have default configuration to use DNSSEC responses, and maybe in the future only DNSSEC. As about trust anchors, in other security applications we looking now closely at the TPM (Trusted Platform Module)/TCG technology that provides hardware bound and hardware protected trust anchors. Yuri
David Conrad wrote:
NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS
...
As noted, dnssec can protect against spoofed dns info.
Except DNSSEC wouldn't really be applicable.
I know, it would be sloppy use of terms, but when I read the thread I "included" TSIG under the DNSSEC item. That could help, unless the shared secret gets easily compromised, too, and it probably would, assuming that java* or active* is enabled ;-)
The attack (as I understand it) provides a new IP address (that of an attacker-owned caching resolver) to clients on a LAN attached to the broadband router, with the attacker-owned caching resolver returning answers to stub resolver queries. Since validation is done at the caching resolver, DNSSEC wouldn't apply.
Rgds, -drc
Wilfried.
On Fri, Feb 16, 2007 at 12:07:45PM +0100, Yuri Demchenko <demch@chello.nl> wrote a message of 110 lines which said:
What does DNSSEC and Techsec-WG people think about recently revealed pharming attack technique that is based on the end user DNS altering?
I really wonder why do all newspapers present it as a DNS attack. It is an attack against a server (the home router). Once you control it, you can do many things besides changing the DNS configuration (such as setting up a tunnel and diverting all IP data through it, so DNSSEC would be screwed, anyway).
On the practical note, I need to say something definite to my students what DNS experts think?
As I said, the DNS is not involved at all in this attack.
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.
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
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. 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
participants (7)
-
David Conrad -
Doug Barton -
Jaap Akkerhuis -
Max Tulyev -
Stephane Bortzmeyer -
Wilfried Woeber, UniVie/ACOnet -
Yuri Demchenko