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
>
>
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
<training(a)ripe.net>.
Kind regards,
Rumy Kanis
Training Services Manager
RIPE NCC
