Subject: TKEY

From: Mark Gritter <[email-masked]>
Date: Fri, 16 Jul 1999 00:36:11 -0700

In the meeting, I questioned the need for this document.  I'll try to 
expand on that, and specify some flaws I see in the draft.

First, the more specific complaint: the "server assigned keying"
and "Diffie-Hellman" TKEY exchanges only set up a secret key between the
participants, NOT verify the identify of the server.  The latter is
necessary to avoid man-in-the-middle attacks--- it doesn't help to set
up the secret key if it's not really with the DNS server we want to "trust".

Second, the general complaint: IKE/ISAKMP already provide key management
with authentication.  I believe IKE does not require DNS to operate;
while it may have to be configured (on the clients) with some sort of public
key for the DNS server, similar information would be needed to do an
authenticated TKEY correctly.  I don't think this is administratively any 
harder than configuring the resolver, and I think it reasonable to require
secure DNS servers to run IKE; this colocation prevents the need for
DNS bootstrapping.

In the long term, I think that for non-update uses of TSIG, IPSec is 
sufficient, since it can provide authentication of the connection to the DNS 
server.  I guess that DNS through NAT boxes won't work with IPSec (leaving 
some need for TSIG), but is this a common setup?  I also agree
that deploying TSIG is easier than IPSec.

-- 
Mark Gritter <[email-masked]>
http://www-cs-students.stanford.edu/~mgritter/

---

From: Mark Gritter <[email-masked]>
Date: Sat, 17 Jul 1999 10:41:11 -0700

> up the secret key if it's not really with the DNS server we want to "trust".

Oops, that was a mistake.  My apologies.  The "security considerations"
section requires a server signature.

---

From: Paul A Vixie <[email-masked]>
Date: Fri, 16 Jul 1999 11:57:24 -0700

> ...
> First, the more specific complaint: the "server assigned keying" and
> "Diffie-Hellman" TKEY exchanges only set up a secret key between the
> participants, NOT verify the identify of the server.  

Or the client.

>                                                        The latter is
> necessary to avoid man-in-the-middle attacks--- it doesn't help to set up
> the secret key if it's not really with the DNS server we want to "trust".

Client identity is also important for server-side ACL checking.

GSS-TSIG appears to suffer from the same problem.

> ...
> sufficient, since it can provide authentication of the connection to the
> DNS server.  I guess that DNS through NAT boxes won't work with IPSec
> (leaving some need for TSIG), but is this a common setup?  I also agree

We chose, early on, not to hitch any part of DNS Security's wagon to any
part of IPsec.  There have been proponents in the past of using DNSSEC to
carry IPsec keys, and vice versa.  It depends on which one we think will
be widely deployed before the other, and that bet has changed more than
once.  Eventually both will exist and we'll need a bridge, but until we
know which one will exist first, we're treating them as separate problems
which are in need of separate solutions.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 18 Jul 1999 18:37:49 -0400

Hi,

From:  Mark Gritter <[email-masked]>
Date:  Fri, 16 Jul 1999 00:36:11 -0700
To:  [email-masked]
Message-ID:  <[email-masked]>

>up the secret key if it's not really with the DNS server we want to "trust".

As you point out in a later message, the Security Considerations
section does say that all responses "SHOULD" be signed but I think I
was trying to be too clever in factoring this out.  In any case, the
man-in-the-middle attack is not explicitly mentioned and it should be.
I'll add this and make sure it is clearer when authentication is
required and acknowledge you in my next pass over the draft.

I don't think the GSS-TSIG version of TKEY, which I think has already
been implemented, has this problem because it is all supposed to be
magicly handled inside GSS.

>secure DNS servers to run IKE; this colocation prevents the need for

IKE may not "require" DNS but is it always going to be configured with
numeric IP addresses?  If you are doing secure DNS, you need to be
configured with a public key anyway and, if that were for example the
root key, you could then probably retrieve and authenticate the DNS
server public key you need to do authenticated TKEY modes.

I think it is a bit messy that TKEY has a many different modes as it
does and I'm not sure they will all survive when it does to Draft
Standard but it is a paragon of simplicity compared with the IKE/ISAKP
complex.

>that deploying TSIG is easier than IPSec.

If you agree that TSIG (or SIG) is easier, needed for NAT
environments, and needed for update, why not use them all the time for
DNS security instead of adding the complexity of sometimes using
IPSEC?  TKEY can be viewed as a simple way, within DNS, of getting
from public keys/SIG or an existing GSS deployment to more efficient
symetric keys and TSIG.

Thanks,
Donald