Re: From whence we came...

[Greg Hudson <ghudson@MIT.EDU>]

On Thu, 3 Jan 2002, Simon Josefsson wrote:

> Altough another option might be to alter the DNS namespace to match
> your trust model, which would be ugly.

For some applications (anything using DNS-based identifiers: email, ssh,
etc.), if two departments don't trust their common DNS
ancestor, there is a problem, since that ancestor is implicitly authorized
to administer both DNS spaces.  Right now the information provided by that
ancestor isn't (generally) provided securely, but that doesn't mean people
don't trust it.

> Steve Hanna <steve.hanna@sun.com> writes:
> > Why is it better to depend on the "trust infrastructure" of DNSSEC
> > than to depend on a PKI? Millions of people use PKI every day (with
> > HTTPS). Popularity does not equate to superiority, but it's hard to
> > argue that PKI is not practical.

It is very easy to argue that PKI, in its current incarnation, is not
practical beyond use by web sites belonging to companies with large
budgets.  "Every certificate generates $500 in revenue to Verisign" is not
what some of us call practical.

It is also a little bothersome to have one authority give out DNS
information and another authority give out certificates saying that I hold
an identifier at a given domain.  What happens if they disagree?  (Of
course, right now, the de facto monopoly PKI root is also the de jure
monopoly DNS root, but that might not always be the case; and if it is
going to always be the case, then it's not clear why we should be using
different technical mechanisms.)

> via DNS, rather than implementing PKIX based solutions.  Especially
> since I don't see how a PKIX based solution would solve the problem
> these applications wants to solve -- how to find a random hostnames'
> or email address' public key and be able to trust it?

I'm not quite sure what you're missing or what assumptions you're using.
This is how the PKIX-based solution would work, by my understanding, which
is probably a bit simplified:

  * Everyone trusts and knows the public key of some number of well-known
    PKIX roots.  (Just like almost every web browser trusts Verisign and
    knows its public key, on account of having a pre-configured
    self-signed root certificate.)

  * The ssh protocol would be modified so that a host can present a
    certificate instead of just a public key.

  * The client verifies the certificate against the appropriate
    preconfigured root CA.

Likewise for email (people can already do this, although almost nobody
does): the sender transmits a certificate in each message, or in the first
message if there is a prolonged exchange and people feel like optimizing.
The receiver can verify this certificate using its preconfigured root CAs.

If the requirement for preconfigured root CAs bothers you, then you
shouldn't like the DNS solution either, since it requires every recursive
resolver to know the public key of the DNS root.