Re: looking for draft volunteers

[Steve Hanna <steve.hanna@sun.com>]

So you're saying that the requirement "MUST be possible to secure
locating and retrival of the key" could include either verifying
the key using a trusted key or using an out-of-band mechanism?
That's true, although SSH depends on just this sort of out-of-band
mechanism and users almost always omit the out-of-band check.
In my opinion, we should require something better (although
out-of-band verification could always be an option).

So I would suggest changing that requirement to say "MUST be
possible to secure locating and retrieval of the key (including
support for at least one alternative to out-of-band verification)".

-Steve

Simon Josefsson wrote:
> 
> On Mon, 14 Jan 2002, Steve Hanna wrote:
> 
> > > > > Requirements on a Solution
> > > > >
> > > > >   "MUST be possible to locate application keys given only IP address
> > > > >   or hostname"
> > > >
> > > > You also need *some* sort of trusted key (DNS or PKI). Otherwise,
> > > > you're wide open for impersonation. Note that the first use case for
> > > > SSH above seems to suffer from this problem. You only brought one
> > > > key, the SSH host key for beagle. Now that machine is down. You're
> > > > SOL unless you also have another trusted key.
> > >
> > > I think the assumption is 'some DNSSec key'...
> >
> > If there's a built-in assumption here, it should be made explicit.
> > The use case should say "Fortunately, I have the key of the DNS
> > root or a PKI trust anchor." The requirements should say "MUST be
> > possible to locate application keys given only IP address or
> > hostname *and* a trusted key (DNS or PKI)"
> >
> > Simon, was there a built-in assumption there?
> 
> No.  I separated the issues into two requirements:
> 
>   "MUST be possible to locate application keys given only IP address
>   or hostname"
> 
>   "MUST be possible to secure locating and retrival of the key"
> 
> I did not want to restrict the mechanism of locating and retrieving keys
> by assuming the locating/retrieving mechanism is secure.
> 
> If DNSSEC never happens, it still can be useful to distribute, e.g., SSH
> keys using DNS as long as you have some other mechanism to secure the
> retrieval afterwards.  The retrieved key might contain information that
> lets you contact whatever trust point you may have to make sure it is the
> right key.  Clients in general should not have to be manually configured
> to point at one LDAP server, lets make the application find this out
> themselves.  (Of course, trust points should (only) be manually
> configured.)
> 
> Given the state of DNSSEC, I believe we should include this model as well
> (or at least not exclude it).