Re: looking for draft volunteers

[Derek Atkins <warlord@MIT.EDU>]

Keith Moore <moore@cs.utk.edu> writes:

> if the SSL cert you get back is fine-grained enough for your purposes,
> that's quite sufficient.  but as I said (in slightly different words), 
> if you want to use the SSL key to authenticate the SSL payload, it 
> essentially requires you to trust that SSL key to authenticate 
> everything on that server.

From a security standpoint that is not necessarily an unreasonable
requirement.  Then again, nothing says that you can't have a different
SSL key for each user key.  But if you're going to do that, why not
just store the user key in DNS in the first place?

> that's fine.  but unless the SSL key is verifiable from DNSSEC,
> you don't know for sure that you're talking to the right server.

Right, that was my point.  That's why you need the SSL key (or a hash
thereof) in the NAPTR referral, signed by DNSSEC.

> and even if can tell you are talking to the right server, that's not 
> the same thing as knowing that the information returned by the server
> is trustworthy.  it's one thing to trust the SSL key to thwart 
> man-in-the-middle attack on its encryption, something else to trust
> it to assure the authenticity of all data stored on a server.

No. but if you know you are talking to the right server, and if you
know that the data you receive over the network has not been modified
in-transit, then you know that the data you received is what the
(correct) server sent.  How much you trust that information is up to
you.

Why should you trust the information you get from e.g. www.mit.edu?

However, if you do have a signature path to "something" you know and
all the signatures verify properly, then you have a reasonable stance
to trust that information.  However, without first-hand knowledge of
everyone in the path, you obviously have some meat-space issues to
contend with.

> yes, but DNS isn't very good for storing keys down to say the level of 
> an individual user, 

Sure it is -- you just need a naming convention to name users.  See
Hesiod for one example:

 warlord.pgpkey.ns.athena.mit.edu. ...
 warlord.passwd.ns.athena.mit.edu. in txt ...
 warlord.pobox.ns.athena.mit.edu. in txt ...

Note that the latter two actually exist; the former _could_ exist.

>     and it isn't very good for storing multiple keys 
> per resource either (in case you want to satisfy different clients 
> that trust different key chains)

DNS certainly COULD do this, and there are at least two different
approaches for means to do it.  One would be by naming converntion for
different client applications, another would be for differnt RRTypes
for each application.

The only thing DNS wont do well is storing multiple certificates using
different CAs for the same client application.

> Keith

-derek

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