[dns-wg] What about the last mile, was: getting DNSSEC deployed

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