Re: What are we trying to do?

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

Randy Bush <randy@psg.com> writes:

>> _ssh.host.example.org.  IN [REFERRAL-RR] http://www.example.org/key.txt?hash=A61B2DF..
>
> actually, i am still thinking more of using the dns only to locate the
> service for all users and hosts in the domain.  e.g.
>
>     _keys.psg.com     A      <my ldap server>
>
> signed, of course
>
> and having the ldap server be available only authed and crypted, and serving
                                               ^^^^^^     ^^^^^^^

This is where the problem is -- how do you propose to achieve auth/crypt?

Assuming symmetric techniques are used; the client and server need to
have exchanged keying material via some secure channel earlier.  If
the idea is to do "opportunistic" encryption, assuming previously
shared secrets sort of spoils the idea -- they can exchange the keys
used for IPSEC, SSH, PGP or whatever via this secure channel as well.
Admittedly, to scale a bit better than this, kerberos-like techniques
could be used.  But still, not everyone trusts a kerberos realm that
trust the server's kerberos realm.

Assuming asymmetric techniques; the client need to get the public key
of the server without any possibility of man-in-the-middle attacks
replacing the public key.  So the client is back where it started, it
wants to get a public key securely.  Again I'll admit that the
situation can be improved by preconfiguring clients with a couple of
CAs, like the web browser situation today, but still not everyone
trusts the CA that the server chosed to use.

Assuming Secure DNS on any useful scale will happen; storing the
public key in DNS directly (or via a secure referral, as above) would
allow, e. g., a email client to find the key of someone directly.

(Upon re-reading this I find the rant vague, but at best it will
provoke someone to write up good ideas instead.  Assuming anyone
survived christmas food...)