Re: [dnsext] stub validation

[Phillip Hallam-Baker <[e-mail]>]

You probably don't want Starbucks to manage your network security.

But what about Symantec, MacAfee, Comodo, Kaspersky and the other companies
who specialize in providing security services?


The problem with making sense of DNSSEC data is that very little of it makes
much sense on its own. Any given observation can be the result of a
misconfiguration of a DNS server or an actual attack. It is very difficult
to decide how to react at the client end.

If instead we view a DNS recursive resolver as being a form of spam filter,
DNSSEC becomes one way to authenticate one form of input to that filter.
Cached data from previous requests becomes another. Blacklist and whitelist
data are yet more sources.

In this model the DNS resolver is not merely caching the result of a DNS
lookup, it is caching the result of a security risk analysis. And because it
is able to amortize that cost over multiple connections it is able to
perform a rather more thorough analysis than is possible in the pure end to
end discovery model.


In the PKI model we distinguish between path discovery and path validation.
For most purposes it is sufficient for the recursive resolver to perform
both. But for certain applications and certain platforms it makes better
sense to have discovery performed at the resolver and for the endpoint to
re-validate the path that is returned.

I agree on the problem of DNSSEC not being there until it is being used. One
of the problems has been that until the root was signed there were many
questions that many people did not want to hear raised lest they cast doubt
on the viability of DNSSEC as a whole.




On Sun, Oct 24, 2010 at 9:24 PM, Paul Vixie <[e-mail]> wrote:

> among many critical defects in DNSSEC as specified, there's no good model
> for stub validation, and as time goes on there are fewer and fewer
> trustworthy rdns servers.  as kaminsky said, "i'm not going to trust
> starbucks rdns to tell me the TLS key hash for my bank's HTTPS server".
>
> so...
>
> > From: David Conrad <[e-mail]>
> > Date: Sun, 24 Oct 2010 16:24:54 -0700
> >
> > The problem with applications doing their own resolving is that the 'real
> > control' implies there is someone at the other end of the application
> > that has the understanding and knowledge to make use of that control.
> > Haven't we seen the implications of this approach with browsers that ask
> > the end user whether or not to accept an SSL cert?
>
> ...at the risk of being that guy who just won't shut up about something,
> let me say that until DNSSEC is commonplace, DNSSEC is a failure.  when
> every apple and microsoft and google and RIM platform including every
> mobile phone can either validate end-to-end based on trust anchors (using
> DNSSEC), or validate hop-by-hop based on transaction signatures (using
> TSIG) from a trusted (and reachable!) rdns, then DNSSEC won't have been
> worth its (considerable) engineering cost.
>
> and it'll have to just work, out of the box, for nontechnical users, with
> no more or at least no different popups than we get from X.509 failures.
>
> but please everybody, don't dilute the DMNF thread with this argument.
>
>


-- 
Website: http://hallambaker.com/