To:
Steve Hanna <steve.hanna@sun.com>
Cc:
Simon Josefsson <simon+keydist@josefsson.org>, Edward Lewis <lewis@tislabs.com>, keydist@cafax.se
From:
Derek Atkins <warlord@MIT.EDU>
Date:
17 Jan 2002 13:32:28 -0500
In-Reply-To:
<3C47041D.A8198F7D@sun.com>
Sender:
owner-keydist@cafax.se
User-Agent:
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
Subject:
Re: looking for draft volunteers
I think this sounds reasonable.
It doesn't rule out using DNSSec, but it doesn't rule out
"outside-DNS" certificate verification.
-derek
Steve Hanna <steve.hanna@sun.com> writes:
> 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).
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available