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

So I lied. It wasn't my last response on the subject.

Lutz Donnerhacke wrote on 02/16/2007 01:13:40 PM:

> * Roy Arends wrote:
> > Lutz Donnerhacke wrote on 02/16/2007 11:40:14 AM:
> >> You can't update the installed base quick enought to gain the 
benefits
> >> of DNSSEC. If the recursing resolvers do not validate, the whole 
DNSSEC
> >> effect is going to zero. You will find about 100000 validating
> >> resolvers at end user sites and nobody will sign a zone for this 
group
> >> of geeks.
> >
> > Ah, you're assuming that folk will en-masse sign their zones for the 
> > handfull of validating resolvers ?
> 
> Yes. See the reactions to the last announcement of a Swedish ISP.

So folks with domains under '.se' are signing their zone en-masse ? 

Haven't seen those reactions.

> > Meanwhile, my OS/X and windows boxes are configured (by default) to 
update
> > itself regularly. Some of my applications do that as well. My browsers
> > have validation intergrated. Joe end user would not even see the
> > difference.... but he's better off than before.
> 
> He will see a difference, if some spoofing attacks does not longer work.

Stub resolvers can be spoofed trivially. resolver code in dsl 
routers/cable modems can be spoofed trivially.

So, unless the end-user has dnssec deployed locally, spoofing attacks 
work.

> > I don't really expect any demand from end-users in general.
> 
> I see a strong demand from commercial banking institutes (not really).
> Let's assume some major DSL-ISPs does switch on validating. This results 
in
> a trusted DNS for about 60% of there customers (may be more). Now 
consider
> the phishing buzzword.

security theater. Nothing really changes for the end user. Those who tried 
to spoof resolvers will now change their focus towards the end-users stub. 
Arms race.

> > That leaves us with pushing code to the end user, in applications and 
OS,
> > which implies coorperation from and education to software developers.
> 
> Taking this road means: Redo from start.

It _is_ done from the start. We've put in the current standards. 
Applications can already use. My jabber server uses it. Validation on a 
stub.

> Never get a reasonable deployment.
> Root will not be signed, because there are not enough installations. 
More
> installations will not come up, because the root is not signed and key
> maintainence is a mess. Catch-22.

That is the _current_ status quo. not enough installations have 'switched 
on' dnssec, so why bother signing. why bother switching on dnssec if not 
enough domains are signed.
 
> >> I can't see your point here.
> >
> > acl's, firewalls, etc, that decide on source ip address if it can 
query
> > your resolver. I can circumvent that.
> 
> How do you want to do this? 

I scan a range, a few boxes will do a reverse lookup. I control the 
specific reverse address space, hence your resolver is talking to me: 
window of opportunity. Another way is spraying spam around, antispam code 
resolve whatever I tell it to resolve. 

This reminds to finish my article about intrusion detection detection 
(sic) methods, and develop some anti intrusion detection dection (sic) 
methods.

> Please respond by email directly, it's off-topic.

Well. Others might be interested in this as well, so, there.

> >> You are a geek. But you spoke about end users. And they trust their 
ISP
> >> for the data they received from him.
> >
> > I'd advice joe end user to validate locally.
> 
> They are free to do so. They are free to use any nameserver they want.
> But if they use the ISP's recursive resolver, this will be a validating 
one.

What is the use of seeing a bit set in the response that claims that the 
response is validated, when I can't trust the link !!!!!!!

> > Just as I'd advice them validate certificates (which browsers do
> > automagically). Are you saying that end users should blindly trust 
their
> > http connection, just because it come via their ISP, or the ISP's 
proxy?
> 
> No, you confuse the source of the data.

eh ? 

> The ISP can validate the integrity of DNSSEC-signed zones, and it is 
good to do so.

The ISP can validate the integrity, sure. To me that would be another 
middlebox fondling with the data. 

> The ISP can't validate the
> integrety of HTTPS certificates, because the protocols does not show 
them to
> him without serveral crude hacks.

So, basically, if the https protocol would allow it, ISP's like to 
validate the integrity of certificates as well.... so end users don't have 
to ? 

Roy