Re: From whence we came...

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

Steve Hanna <steve.hanna@sun.com> writes:

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

I'm not sure either, but it might be "good enough" (for some
applications) to do DNSSEC with application keys, so that you don't
need the additional complexities that PKIX brings.

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

Current practice, yes, but there are drafts that describes these new
use cases.  Assuming DNSSEC is deployed and trusted, it would make it
possible to get a hosts public key.  A PKIX CERT stored in DNS and
secured by DNSSEC would achieve the same thing as well, but
implementing PKIX has a cost as well.  So I'm not sure we need this
either, but I think it is an idea that should be considered.

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

The problem if you talk to a "random" host is that you generally can't
know what CA is used by the other host.  Assuming DNSSEC happens (to
fix the DNS spoofing problems), that infrastructure may be leveraged
for opportunistic IPSEC etc.

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

In general I don't think you can assume that both parties use and
trust the same CA.  On the other hand, it is reasonable to assume that
both parties trust the DNS (since email addresses assumes a globally
shared namespace).

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

Yes, the exact purpose of this list will probably only be clear when
it has concluded.