Re: looking for draft volunteers

[Keith Moore <moore@cs.utk.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?

how well would this support a zone like aol.com that has tens of 
millions of users, with a fair percentage of these keys changing
each day?

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

again, I don't think the key (or a hash) belongs in the NAPTR referral,
but that's just an argument about what's reasonable to put in a NAPTR
RR. 

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

since I don't currently use that information for anything critical
or sensitive, I don't currently need to trust it.

and since www.mit.edu has been hacked in the past, I wouldn't trust 
its SSL key for much.  (granted it's probably safer than most web 
servers - unlike most organizations MIT actully has people that 
understand security) 

OTOH if www.mit.edu returned me a key along with a cert that allowed
me to verify the key via some external means, that would be much better
than my having to trust the SSL key.  

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

I didn't say it couldn't be done, I said DNS "isn't very good" for this -
partially because you have to encode the query type in the DNS label,
partially because if you're searching for multiple keys you have to
query each of several labels, partially because of limitations in the
DNS protocol on the length of data you can return, partially because
DNS servers tend to be maintained by different parties than the ones
that you want to maintain your key servers.  I also think there are some
benefits to separating function between the way you find your servers 
that describe resources (DNS) and servers that actually describe
the resources (e.g. rescap) - each protocol and server can then be 
optimized for its purpose.

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

I think we understand each other here; we just basically disagree
on what it means for DNS to do this "well".

Keith