Re: From whence we came...

[Simon Josefsson <simon+keydist@josefsson.org>]

Greg Hudson <ghudson@mit.edu> writes:

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

I agree.  But you can alter the namespace to fit your purpose.  Lets
say the math.example.org department want to work securely with
cs.example.org but do not trust example.org, they can create
securezone.math.example.org and securezone.cs.example.org under which
they can put their SSH keys.  Again, this is very ugly and I don't
think anyone will bother with this.

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

Yes!  This bothers me alot.

> On Thu, 3 Jan 2002, Simon Josefsson wrote:
>> 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.

The hidden assumption I was using here is that the two parties do not
know (or trust) the same CA root.  This seems to be the case in the
real world.

The DNS, on the other hand, is only useful if provides a unique and
global namespace.  Implementing DNSSEC on top of a unique and global
namespace would let these two parties trust keys distributed via DNS.
Compromised private keys for a zone is a serious problem, but so is a
compromised DNS server for a zone today.