Re: My take on the BoF session

[Keith Moore <moore@cs.utk.edu>]

> > as I see it, there are three major problems with this approach:
> >
> > 1. unconditionally representing this as a security improvement and not
> >    informing the user about the limitations of this approach - and in
> >    particular, about the degree of trust that this invests in the
> >    root and higher-level zones.
> 
> It does NOT necessarily invest more trust in the root zone.
> 
> Example:  inet.org could use its own key to sign DNS records
>           under inet.org and could distribute the authentication key
>           for inet.org's records via out-of-band/non-DNS methods.
>           Parties having that authentication key could use DNS to
>           validate the specific entries obtained via DNS (with DNSsec)
>           without having to place ANY additional trust in the root
>               or ORG zones.

that's fine, as long as applications support the ability to utilize
and recognize those out-of-band authentication keys.  in other words
the mechanisms by which this is done needs to be part of the
specification.

> > 2. trusting DNS "by default" - i.e. presuming the user's choice.
> 
> That hasn't been Bill's proposal.  However, Bill is quite correct
> that if the existing (untrusted) DNS gives out bad data, nearly
> everyone is in trouble.

The existing DNS can arrange to return false NS RRs and false glue
RRs for any existing zone.  Those NS RRs can point to servers which
provide only slight differences in the RR that they return.  If this
is done for only a small number of zones, the existing DNS can be used
to impersonate those services without putting "everyone" in trouble.

Similar attacks are possible with DNSSEC.  The difference is that
a greater amount of trust will be invested in the system if users
believe that DNSSEC insulates them from such misrepresentation.

DNSSEC does minimize the potential for attack, but it does not eliminate
it.  I'm not asking for perfection, I'm asking that we be honest about
the limitations of this approach and that provide reasonable alternatives
for those who don't feel that this approach is sufficient for their purposes.

> > 3. building a system that is so inflexible that it doesn't support
> >    other trust models.
> 
> Nothing in Bill's proposal precludes other trust models.

I wasn't referring to Bill's proposal specifically; if that was an implicit
part of this thread, I wasn't aware of it.

Keith