Re: From whence we came...

[Steve Hanna <steve.hanna@sun.com>]

Simon Josefsson wrote:
> Steve Hanna <steve.hanna@sun.com> writes:
> > Simon Josefsson wrote:
> >> For some applications the DNSSEC trust model is sufficient.
> >>
> >> Also, I'd imagine that a department using SSH with keys (not certs)
> >> stored in DNS protected by DNSSEC would configure their clients to
> >> trust their own DNSSEC key directly.  Or simply using TSIG protected
> >> DNS to a local DNS server that knows the SSH keys.  In practice this
> >> would mean having a separate trust root and a separate policy.
> >
> > This works OK, as long as you have only one department. What if
> > you have two? What if math departments at two colleges want to
> > work together securely? Who's the root then? The DNS namespace
> > often doesn't match the structure of trust.
> 
> Right.  I'm not saying that we have found a silver bullet.  If you are
> in a small closed environment, the usual mechanisms work fine -- set
> up a local CA and issue certificates to all people involved.

If you're in a small closed environment, preconfigured keys (current
practice for many SSH and IPsec installations) works fine, too. I'm
not sure we need three mechanisms: preconfigured keys, DNSSEC with
application keys, and certificates.

> Which solution you chose depends on what is available. If DNSSEC is
> deployed, using DNS to distribute keys to the applications might be
> cheap.  If you have a local CA configured and clients supporting LDAP,
> PKIX is easier.

You don't need LDAP to use certificates. The certificates can be
exchanged using application protocols (as TLS, S/MIME, and IKE do
today). Or you can store the certificates in DNS (using the CERT
record).

> > Applications that use keys instead of certs? What do you mean?
> > Certs are only a mechanism for key distribution. All these apps
> > end up using keys in the end.
> 
> Yes, I meant that the key isn't transported inside a (PKIX)
> certificate, but rather as a raw key.  Such as the KEY resource record
> in DNSSEC.  There seem to be use cases for this (SSH, IPSEC).

SSH and IPSEC use preconfigured keys (or keys transported in SSH and
verified by external means), not the KEY resource record. At least,
that's my understanding of current practice. I don't see that we
gain much by adding another key distribution mechanism (other than
certs and preconfigured keys).

> > 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.
> 
> I don't see them as competing ideas -- for some applications that is
> closely tied to DNS and wants DNSSEC for other reasons (such as making
> sure the hostnames they look up isn't spoofed), it might be easier to
> also distribute public keys (secured by DNSSEC) used by applications
> 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?

Now we get down to some basic issues. I don't think that's the
problem that most applications want to solve. Most applications
can simply connect to the other party, exchange and verify
certificates during the handshake, and terminate the connection
if verification fails. This doesn't work with email because it's
a store-and-forward application, but that's unusual.

> >> Replace IPSEC with S/MIME in the draft and you get another nice
> >> applications -- secure email between two persons that only knows each
> >> others email addresses.  Today it isn't really possible to find
> >> someone's certificate using only the email address other than
> >> trial'n'error attempted fetches against a couple of likely CAs.
> >
> > The current practice is for the parties to exchange signed emails
> > with little content except their certificates. Then they can use
> > those certificates to send encrypted email.
> 
> Isn't there a man-in-the-middle attack here?

Nope. Certificates are verified when the signed emails are received
and before the encrypted emails are sent. So the man-in-the-middle
can't participate (unless they have a valid certificate from a
trusted party under the intended recipient's name).

> > Maybe at some point email clients will start using SRV records to
> > find an LDAP server that might contain an unknown recipient's
> > certificate.
> 
> Yes, this is a step towards solving the same problem, it was discussed
> briefly a few days ago (see the archives).  If that solutions actually
> gets deployed in any significant scale, I think many of the use-cases
> that seem to be discussed here can be solved using it.  So far it
> hasn't.  My understanding of this lists' topic is that it wants to
> explore how to get something like it (that is: public-key distribution
> via DNS, possibly via SRV referrals) to work.

Hmmm. I read the archives before joining. My understanding is that
the purpose of the list is to find a simple way to securely
distribute keys to applications. Whether and how DNS should be used
seems to be a matter of some dispute and discussion.

-Steve