Re: Global PKI on DNS?

[Derek Atkins <derek@ihtfp.com>]

Eric Rescorla <ekr@rtfm.com> writes:

> > > Nearly all of the major IETF security protocols (TLS, IPsec, OpenPGP)
> > > already have their own certificate discovery mechanism
> >
> > More specifically, as far as I can tell (and, of course, I'm not a "card
> > carrying credentialed security person", so I shouldn't speak out of turn,
> > but...), none of the myriad existing key distribution mechanisms have been
> > deployed on anything like a significant scale.
>
> Huh? You must have somehow missed the millions of SSL sites on the net.

I am a "card carrying credentialed security person", so let me pipe
in. ;)

Eirc, SSL != (TLS, IPsec, OpenPGP).  I'll buy that SSL == TLS, but
that wasn't the original question.  IPsec, OpenPGP, and S/MIME all
have the key distribution problem.  You may argue that IPsec can solve
the problem the same way that SSL/TLS does by each endpoint sending
its signed cert to the peer, however that presupposes a global PKI
(which really doesn't exist) in order to have arbitrary communication.
Just look at the trouble the FreeS/WAN people have had with their
opportunistic encryption.

> In any case, I'm not sure what you mean by "key distribution
> mechanisms". The protocols in question typically have a way for one
> peer to give the other their certificate. This is vastly easier
> than trying to insert a certificate into some DNS server.

No, they don't.  Many protocols ignore the question of how certs are
obtained, they just assume they exist and are distributed "somehow."
For exmaple, if I want to send you a PGP message (or S/MIME message) I
need to have your cert before I contact you.  Once communication is
achieved I can cache the cert for linkability, however these protocols
still need a way to acquire certificates for initial communications.
Using DNS for said lookup (not necessarily verification) would
certainly be IMHO a reasonable way to do this.

> > Why reinvent the wheel each time a new protocol is developed?
> As protocol complexity goes, the difficulty of moving the certificates
> around when the associations are created is really trivial, and
> it's extremely convenient to have things be self-contained.

But now each new protocol needs to define its own way to move these
certs around, both within the protocol and potentially outside the
protocol, too!  That seems a bit wasteful.  There are obviously times
when real-time interactive peers want to transmit certs within the
protocol, but there are many other protocols where certs are "assumed"
out of band.  We're trying to solve this out-of-band problem.

> -Ekr

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com