Re: What are we trying to do?

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

Randy Bush <randy@psg.com> writes:

>> Ultimately the need should be driven by application writers
>
> to see what some apps writers, who were embarrassed by what
> dumping all their non-dns stuff in the dns, would do, take a
> look at draft-hall-ldap-whois-00.txt.  they put *locating* the
> app-level service in the dns (kinda what the dns is about),
> but not the mass of the service.

This is a good pointer.  I hope that model is considered here, there's
no need to put the actual public key in DNS, if putting a reference to
where you can fetch the public key in DNS suffice.  We have at least
five specifications [1] that enables this models today, so let me for
the record describe what the problem with the idea is:

The problem is that if the "reference" put in DNS is not secure, the
whole point of doing all this becomes moot.  Say something like this
is used for SSH

_ssh.host.example.org.    IN [REFERRAL-RR] http://www.example.org/key.txt

indicating that you should get http://www.example.org/key.txt to get
the hosts' key.  Even if Secure DNS protects this referral, there is
no protection between the application and the web server.

Faced with this problem (as application writers have been), I can see
at least three solutions:

* Replace the referral in DNS with the actual public key.  (A public
  key, btw, is shorter than many URLs.)

* Make a requirement that the client has access to a "secure"
  infrastructure separate from DNS.  Such as HTTP or LDAP over TLS.

* A third solution would be something I haven't seen proposed here,
  but that is in frequent use within WAP: Ammend the referrence with a
  SHA1 fingerprint of the public key.  This prevents from the
  man-in-the-middle attack possible above.  A'la the WAP PKI document:

_ssh.host.example.org.  IN [REFERRAL-RR] http://www.example.org/key.txt?hash=A61B2DF..

  The client would then be able to check that the fetched key has the
  same hash as the URL in the referral in DNS.  The referral could be
  protected by Secure DNS. No man in the middle, no keys in DNS, just
  referrals.  Everyone happy?  (Thought not..)

[1] RFC 2219, RFC 2782, RFC 2915, draft-ietf-ldapext-locate,
draft-ietf-pkix-pkixrep-00.txt.