Subject: RE: comments on krb-dns-locate draft

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 17 Dec 1999 16:03:19 -0800

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Thursday, December 16, 1999 11:58 AM

> 
> And, I keep coming back to: *Why* can't we simply insist on DNSSEC if
> sites want security?

Science: Because fundamental security principles say one should not insist
on an extra mechanism that isn't needed.
Engineering: because DNSSEC isn't deployed.

Paul

---

From: Ken Raeburn <[email-masked]>
Date: 18 Dec 1999 03:40:04 -0500

> on an extra mechanism that isn't needed.

You also shouldn't add complexity to a system that isn't needed.  (I'd
be much happier with a Kerberos-based referral proposal that wasn't
making changes to the core Kerberos protocol itself.  It can use
Kerberos for security, sure, and maybe even be processed by the KDCs.
The data being exchanged already has one well-understood wire
representation in use that we could just re-use, namely domain system
resource records....  DNSSEC is just a bit further down that road, and
a little off to the side.)

> Engineering: because DNSSEC isn't deployed.

I was under the impression that some sites were using it.  And for
those that aren't, BIND 8 already has the code, doesn't it?  Neither
of these can be said for kerberos-refer.  Whatever mechanism we use,
we have deployment and transition issues to deal with.  At least
DNSSEC has already had quite some time going through the review and
implementation processes, and has code available in a widely used
package, even if that code itself isn't so widely used.

Ken
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 18 Dec 1999 10:23:24 -0800

I haven't been closely following this thread but I can contribute to
this part of the conversation.

> package, even if that code itself isn't so widely used.

Some sites might be using DNSSEC but I question the wisdom of doing
so: not all non-DNSSEC servers ignore DNSSEC data. Specifically,
Microsoft DNS pre NT SP6 drop query responses if they contain DNSSEC
data. (Microsoft was suppose to fix the problem in SP6 but I haven't
checked.) Consequently, if you have a DNS server handing out DNSSEC
data on the Internet you probably won't be able to exchange DNS data
with MS based DNS servers.

I had my primary zones DNSSEC enabled on the Internet some time ago
and unDNSSEC'd them because I could no longer send and receive e-mail
with MS based enterprises. I still have one or two zones DNSSEC
enabled on the Internet I rarely use, so test for yourself against
yourveryowncompanyname.com. I haven't maintained the zone so I can't
guarantee its freshness or content. If you need help please contact me
off-line.

There are major issues with deploying DNSSEC on the Internet, starting
with who is in charge and key management issues among disparate
competing commercial interest, to name but two issues. (John Gillmore
spent a year trying to resolve the key management issues. I believe he
has given up.) The DNSSEC code in BIND 8 is in its infancy and there
have been problems, some of which I am still experiencing.

At Washington the DNSOP WG discussed the issue of how to get DNSSEC
deployed, so expect progress. However, I strongly recommend you don't
hold your breath.

---

From: Dennis Glatting <[email-masked]>
Date: Sat, 18 Dec 1999 11:09:19 -0800

I should have also mentioned my experience with the MS DNS problem
dates to last summer, pre SP5.

---

From: Ken Raeburn <[email-masked]>
Date: 19 Dec 1999 05:01:06 -0500

> with MS based DNS servers.

Ouch.

> has given up.)

But similar issues come up with Kerberos anyways.  If two competing
companies would run DNSSEC but wouldn't exchange public key info
securely, I bet they'd be just as unlikely to establish Kerberos
inter-realm keys.  And, on the flip side, if two sites have
established inter-realm keys, their security administrators could
probably arrange for the PK bits to happen.

>    The DNSSEC code in BIND 8 is in its infancy and there

> deployed, so expect progress. However, I strongly recommend you don't

Okay, between that and MS lossage, I guess DNSSEC is out.

Thanks for the info.  It's so much easier to examine possibilities
when one actually has some information.... :-)

Ken

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 19 Dec 1999 11:07:00 -0500

> Okay, between that and MS lossage, I guess DNSSEC is out.

I really hope we don't write off DNSSEC so easily on account of a
single bug in a single implementation..

					- Bill

---

From: Dennis Glatting <[email-masked]>
Date: Sun, 19 Dec 1999 11:46:57 -0800

> single bug in a single implementation..

I don't mean to dismiss DNSSEC, rather indicate there are problems. 

The reality is we do not have significant experience deploying DNSSEC,
so the MS bug may be an indication of things to come, but then again
maybe not. For myself, if SP6 does fix the bug then I will reintroduce
DNSSEC in my zones late 2000 and instruct people who have trouble
interfacing to either apply SP6, migrate to w2k, or, better, deploy
FreeBSD or Linux. :) 

The migration to DNSSEC by people like myself is of dubious value if
the roots themselves are not secure or offering signing services.
There is where the real trouble is: the DoC, ICANN, Network Solutions,
et. al. Consequently, we have the problem of distributing keys for
DNSSEC enabled zones. (Hmmm.... Maybe we could PGP sign zone keys at
IETF PGP key signing parties and register them on a PGP server as an
interim solution?)

---

From: Dennis Glatting <[email-masked]>
Date: Sun, 19 Dec 1999 20:24:45 -0800

Ken Raeburn wrote:

> :  The DNSSEC code in BIND 8 is in its infancy and there
> : have been problems, some of which I am still experiencing.
> 
> BTW, I tried looking at the yourveryowncompanyname.com domain, and a
> newly-build BIND 8.2.2-P5 nslookup complained of RR format errors.
> The eariler version that NetBSD is still shipping complained of a
> truncated response, and told me the name didn't exist, but only when I
> use the -debug flag; without that flag, it complained of a bunch of
> type-0 RRs for the root.
> 

The print function in the resolver is incomplete. It sets the name to
"?" then further in the code it expects a component count of at least
two, but there is only one.

> If neither BIND nor MS include a working implementation, what's the
> likelyhood that we can debug and deploy it anywhere near as quickly as
> some homegrown hack designed solely for Kerberos?
> 
> On the other hand, if Dennis's problems have all been fixed in later
> revs, maybe we've got half a chance.  (And a quick web search found
> metainfo.com, which looks like it might have DNSSEC support for
> Windows through a BIND port.  It also found me one site that says W2k
> won't have DNSSEC support.  Which is not the same as discarding data
> from zones using DNSSEC.)
> 

Metainfo is a BIND 8 ported to NT. 

> I doubt all site admins have the luxury of forcing their users to
> update their entire operating systems.  I'm sure we wouldn't at MIT.
> An update to existing Windows versions to at least not discard signed
> records would be far easier, but still not "easy" by any stretch of
> the imagination.
> 

If you update the local servers then you are well on your way to
having a solution because clients usually trust the local servers and
you usually have control over and trust your WANs and LANs. Another
proposed standard, TSIG, can be used between the clients and the local
servers to securely transport the data, but there is a problem.

TSIG (draft-ietf-dnsind-tsig-12.txt) is based on shared secrets and is
implemented in BIND 8. Microsoft, last I read, is implementing
GSS-TSIG (draft-skwan-gss-tsig-04.txt) only. They are not compatible.

I requested TSIG be "mandatory to implement" because 1, we need a
simple, common base; and 2, I believe it would be a mistake to bundle
Kerberos with BIND due to complexity and export issues. (The ISC is
reportedly rewriting BIND 8 in BIND 9.) There was a discussion on the
mailing list but I don't remember the result.

---

From: Ken Raeburn <[email-masked]>
Date: 19 Dec 1999 21:57:25 -0500

> > single bug in a single implementation..

I shouldn't have written it as so offhand a dismissal, but if the
problems Dennis describes aren't somehow limited to his own site, it
pretty much means that no one who wants to be well-connected can
deploy DNSSEC right now, and unless MS fixes the problem in W2k (I've
no evidence either way right now, but I won't hold my breath), they
aren't going to be able to for a while.  If that's the case, and we
want secure lookups for Kerberos any time soon, we do have to roll our
own.  (That's *not* meant to dismiss the possibility of coming up with
a working DNSSEC type scheme and distributing it as a Kerberos-only
add-on, such that the primary nameservers of a given domain *don't*
use it.  But that'd be ugly, and probably hard.)

Dennis also indicated there are problems with the BIND implementation:

> IETF PGP key signing parties and register them on a PGP server as an

Makes sense.  Or have KDC administrators exchange DNSSEC keys
protected by Kerberos.  None of this is very different from manually
exchanging Kerberos inter-realm keys and domain info (except for the
public-key vs shared-secret bit).  Sites unwilling to expend the
effort likely won't do inter-realm Kerberos either, so I'm inclined to
discount such issues to some degree.  (But, we have to keep in mind,
users may want to contact such sites with applications that are
capable of doing non-Kerberos authentication as well as Kerberos.
Being able to make Kerberos safe against DNS spoofing but not GSS-API
or SASL applications would pretty much continue to suck.)

Ken