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