Subject: RE: Admitting more documents: application keys in DNS

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 30 Oct 2001 07:49:02 -0800

> In summary, if I was an application developer, I would USE 
> the key data
> in DNS, and I would probably rely on it for privacy assurance, but not
> for authentication.

The problem with this approach is that privacy assurance has proved
in practice to be an easier problem to solve than authentication.

While I accept the argument that permiscuous encryption can be a good
idea and that a good argument can be made that it is better to encrypt
against a key you do not have absolute trust in than to send in the clear,
distribution of low assurance keys is not a difficult problem, it can be
achieved in band in almost all protocols, there is no need to involve
DNS and no particular advantage in doing so.

If there is key data in DNS it will be used for authentication purposes.
That would be a very bad thing.

What we need to do is to separate the discussion of assured key 
distribution from that of non-assured.

* The idea that we can turn the DNS system into a key distribution 
	center is a very, very very bad one. 

* The idea that we can use DNS to help locate key distribution
	centers is a good one.

* In particular DNS may have some utility in addressing the problem
	of downgrade attacks.

For example it would be a good thing (TM) if SMTP over SSL was the 
default for mail services even if the mail servers used self signed 
certificates.

If you have a MS Exchange mail server talking to another MS Exchange
server and both have SSL certificates installed the session will
automatically upgrade to use SSL (pity they don't mention this in the
documentation eh?).

If you are using self signed certificates the connection is vulnerable
to a man-in-the-middle attack. 

Because the default for email is to not support encryption the scheme
is also vulnerable to a downgrade attack. A Man in the middle can 
respond to the query 'should we upgrade' with 'no' and the connection
will default to being in the clear.

There is a utility in being able to specify in DNS the fact that the 
mail service supports encryption.

As a security specialist I would much prefer to obtain from the DNS
service a referral to a Key Exchange service rather than a key itself.

That would allow for the keying to be performed by either public 
key, or if it was an intranet communication via a Kerberos style
exchange.

It might even be the case that the machine hosting the DNS would turn
out in some cases to be the machine hosting the key exchange service.

But I don't want to merge my security code with BIND any more than I 
want to merge BIND with Sendmail, Apache or any other unrelated service.

Finally, the claim that inventing a new protocol is a worse option
than overextending an existing protocol is a complete crock. Repeating
the claim ad-nauseam does not make it any more true.

We are not re-inventing the wheel, we are pointing out the difference
between a bicycle and a truck.

		Phill

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 30 Oct 2001 11:55:41 -0500

>	center is a very, very very bad one.

I understand your sentiment, but I think this is overstated.

>* The idea that we can use DNS to help locate key distribution

For example, take SSH (as has been done repeatedly).

Assuming we use APPKEY, the risk is that the admin of the host incorrectly
interfaces with the admin of the zone.  The result is that at sometime, the
wrong key may be entered into DNS.

Assuming SSH derives a key distribution mechanism (other than the server
just sending the key), the first question SSH will have to answer is "how
will a server host key be validated?"  Once that is answered, the same
issue arrives - will the practice of this be compromised?  The second
question is how will SSH tell the client where to get the key?  If DNS is
used, the referral is as suspect as the key above.

SSH also has some other properties that make this issue interesting.  One
is that SSH is generally a closed-set protocol - the client and server have
preexisting relationships (accounts).  It doesn't seem worthwhile to set up
a large scale key management mechanism when given the option of DNS.
(Everytime I've discussed this locally, we keep arriving at the conclusion
that such a system would just be enriching to CA interests - each
organization would need to certificate-signing certificate, and those are
quite expensive.)

Looking at email and web security is a different matter.  In these cases,
the open-community nature is more ameanable to the higher overhead (because
of scaling problems).  In those instances, certificates make much more
sense.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.