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
> 
> First, it *is* an unconditional security improvement for certain
> applications (for instance, the typical out-of-the-box ssh client).

I think we'll just have to disagree about this.  Personally, anything that 
mandates a greater degree of trust in VeriSign looks like a threat to me,
even if it ameliorates other threats.

> >    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.
> 
> Sounds like fodder for a security considerations sections to me.  I'd
> think it would be micromanagement to put more than "document
> limitations of the approaches chosen" in the charter.

That sounds about right.

> > 2. trusting DNS "by default" - i.e. presuming the user's choice.
> 
> Defaults are a sensitive issue and tend to be highly
> application-dependant; at best, the IETF can make recommendations
> about defaults.  

The most IETF can do about anything is to make recommendations.

> > 3. building a system that is so inflexible that it doesn't support
> >    other trust models.
> 
> But where do you put the flexibility?
> 
> There are at least two dimensions of flexibility here:
> 
> 1) For both of applications which have been discussed (ssh, ipsec),
> there is "application"-level flexibility already; a dns-based scheme
> would plug in alongside already running code for (among others) x.509
> and kerberos in both cases.
> 
> 2) dnssec may not be as rigid as you presume; certainly, I can do as
> Ran suggests and do out-of-band configuration of trusted keys for the
> zones I care about, and there be other ways in which we can improve
> the flexibility of the trust models implemented by dnssec.

I think you need something like #2 - a standard way to use out-of-band
information to invest trust in selected DNS zones without having to 
invest trust in their DNS parents.

Keith