Re: From whence we came...

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

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

> Simon Josefsson wrote:
>> Steve Hanna <steve.hanna@sun.com> writes:
>> > I'm pretty sure that we want certs here, not just keys. Putting keys
>> > in DNS and relying on DNSSEC to authenticate the keys means that
>> > you're tied to the DNSSEC trust model. Top down, single root (per
>> > TLD), single certification policy that may not match an application
>> > or user's needs, etc. Not good!
>> 
>> 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.

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

Still another option would be to put the TSIG key of the other
department into the local DNS configuration as a trusted key.  This
seems rather clean and might work.

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.

>> > And certs are often big, so retrieving them from DNS is problematic.
>> 
>> Right, so applications that use keys instead of certs might be better
>> suited to use DNS.  Anyway, IPv6 and DNSSEC will also generate large
>> DNS packets, so the size issue is not specific to keys in DNS.
>
> 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).

>> > Passing the certs in the application protocol (as with TLS) is
>> > certainly the easiest way to handle key distribution.
>> 
>> Yes, but it assumes that you have a separate trust infrastructure
>> already in place.  If this is the case, I agree putting certificates
>> in DNS buys you nothing.
>> 
>> But if you don't have a prior arrangement between the parties, using
>> keys in DNS might overcome this problem.
>
> 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?

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

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