[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list