Re: looking for draft volunteers

[Keith Moore <moore@cs.utk.edu>]

> > > As I just pointed out, it is not.  You still need LDAP over TLS with
> > > either the SSL key or key fingerprint signed by DNSSec.
> > 
> > agreed that the keys you get from the lookup protocol must be signed
> > by DNSsec in order for DNSsec to be of use in helping the client establish
> > trust in those keys.
> > 
> > however, TLS isn't a very scalable mechanism for authenticating the
> > results of that lookup, since if effectively insists that all of the
> > keys you get from any particular server be signed by the TLS key.
> > trusting TLS for this purpose essentially forces you to have a
> > separate lookup server for each DNS zone.
> 
> Eh?
> 
> DNS hands you back a DNSSec-signed message that basically says:
>         contact <your-URI-here> using <your-KEY-here>
> 
> That's called a "secure referral" and now you go off using SSL
> (perhaps with a self-signed certificate) to protect your lookup
> method.

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.

> The whole point of this exercise was that some people wanted to
> have DNSSec refer users/applications to an external protocol to
> obtain keys.  If you're going to do that you need a trust path
> to the secure protocol.

of course.

> This does not imply that your SSL key is being used to sign the
> certificates/keys returned by this secondary protocol.  The SSL key is
> being used to protect your key-lookup protocol to make sure that you
> get the data you requested from the source you were told to request it
> from.

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.

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.

> > far better to use a protocol which allows each looked-up key to
> > return its own certs.
> 
> Funny that -- thats why a bunch of us want to store the keys in DNS!

yes, but DNS isn't very good for storing keys down to say the level of 
an individual user, 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)

Keith