Re: My take on the BoF session

[Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>]

> 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).

>    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.

> 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.  Note that the aforementioned typical ssh client
(willing to accept unprotected host keys on first connect) already
trusts DNS but contains policy knobs which allow you to turn this off.

> 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.

					- Bill