From shyaam at evilfingers.com Wed Feb 7 16:18:22 2007 From: shyaam at evilfingers.com (shyaam at evilfingers.com) Date: Wed, 07 Feb 2007 08:18:22 -0700 Subject: [techsec-wg] Re: Welcome to the "techsec-wg" mailing list In-Reply-To: <20070207151701.14132.2259.Mailman@postboy.ripe.net> References: <20070207151701.14132.2259.Mailman@postboy.ripe.net> Message-ID: <20070207081822.9b4cfejveo4kw4kg@mail.evilfingers.com> Hi guys, I am new to the Security Mailing lists at RIPE. Have always been in the anti-spam one. Glad to be in here too. kind Regards, Shyaam From training at ripe.net Mon Feb 12 18:11:15 2007 From: training at ripe.net (RIPE NCC Training Services) Date: Mon, 12 Feb 2007 18:11:15 +0100 Subject: [techsec-wg] Announcement DNS for LIRs Training Courses Message-ID: <20070212171115.5DDB52F583@herring.ripe.net> Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Friday 30 March 2007 Time: 09:00-17:00 Location: Lisbon, Portugal And Date: Friday 20 April 2007 Time: 09:00-17:00 Location: Frankfurt, Germany Hosted by: DE.CIX: http://www.decix.de/ And Date: Friday 27 April 2007 Time: 09:00-17:00 Location: Budapest, Hungary And Date: Friday 18 May 2007 Time: 09:00-17:00 Location: Amsterdam, Netherlands And Date: Friday 8 June 2007 Time: 09:00-17:00 Location: London, United Kingdom And Date: Thursday 21 June 2007 Time: 09:00-17:00 Location: Tehran, Iran The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From training at ripe.net Mon Feb 12 18:11:15 2007 From: training at ripe.net (RIPE NCC Training Services) Date: Mon, 12 Feb 2007 18:11:15 +0100 Subject: [techsec-wg] [ncc-announce] Announcement DNS for LIRs Training Courses Message-ID: <20070212171115.5DDB52F583@herring.ripe.net> Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Friday 30 March 2007 Time: 09:00-17:00 Location: Lisbon, Portugal And Date: Friday 20 April 2007 Time: 09:00-17:00 Location: Frankfurt, Germany Hosted by: DE.CIX: http://www.decix.de/ And Date: Friday 27 April 2007 Time: 09:00-17:00 Location: Budapest, Hungary And Date: Friday 18 May 2007 Time: 09:00-17:00 Location: Amsterdam, Netherlands And Date: Friday 8 June 2007 Time: 09:00-17:00 Location: London, United Kingdom And Date: Thursday 21 June 2007 Time: 09:00-17:00 Location: Tehran, Iran The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From demch at chello.nl Fri Feb 16 12:07:45 2007 From: demch at chello.nl (Yuri Demchenko) Date: Fri, 16 Feb 2007 12:07:45 +0100 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: <45D59081.8030201@chello.nl> 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 > > From demch at chello.nl Fri Feb 16 23:37:39 2007 From: demch at chello.nl (Yuri Demchenko) Date: Fri, 16 Feb 2007 23:37:39 +0100 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <7FA2BFC1-5947-46D7-82FE-85AF266A0E54@icann.org> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> <45D618FF.2050904@dougbarton.us> <7FA2BFC1-5947-46D7-82FE-85AF266A0E54@icann.org> Message-ID: <45D63233.7020708@chello.nl> 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 From president at ukraine.su Mon Feb 19 00:33:16 2007 From: president at ukraine.su (Max Tulyev) Date: Sun, 18 Feb 2007 23:33:16 +0000 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <45D59081.8030201@chello.nl> References: <45D59081.8030201@chello.nl> Message-ID: <45D8E23C.3@ukraine.su> 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 >> >> > From jaap at NLnetLabs.nl Fri Feb 16 13:46:38 2007 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Fri, 16 Feb 2007 13:46:38 +0100 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: Your message of Fri, 16 Feb 2007 12:07:45 +0100. <45D59081.8030201@chello.nl> Message-ID: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> 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 From bortzmeyer at nic.fr Fri Feb 16 13:57:18 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 16 Feb 2007 13:57:18 +0100 Subject: [techsec-wg] Re: What about the last mile, was: getting DNSSEC deployed In-Reply-To: <45D59081.8030201@chello.nl> References: <45D59081.8030201@chello.nl> Message-ID: <20070216125718.GB22183@nic.fr> On Fri, Feb 16, 2007 at 12:07:45PM +0100, Yuri Demchenko 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. From david.conrad at icann.org Fri Feb 16 17:51:13 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 16 Feb 2007 08:51:13 -0800 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> Message-ID: <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> > 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 From david.conrad at icann.org Fri Feb 16 22:10:45 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 16 Feb 2007 13:10:45 -0800 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <45D618FF.2050904@dougbarton.us> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> <45D618FF.2050904@dougbarton.us> Message-ID: <7FA2BFC1-5947-46D7-82FE-85AF266A0E54@icann.org> 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 From dougb at dougbarton.us Fri Feb 16 21:50:07 2007 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 16 Feb 2007 12:50:07 -0800 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> Message-ID: <45D618FF.2050904@dougbarton.us> 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 From Woeber at CC.UniVie.ac.at Mon Feb 19 11:05:59 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 19 Feb 2007 10:05:59 +0000 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> Message-ID: <45D97687.9070407@CC.UniVie.ac.at> 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.