Subject: Re: DNS SRV question (was Re: please post updated draft)

From: Bill Manning <[email-masked]>
Date: Thu, 28 Oct 1999 14:03:08 -0700 (PDT)

> At 2:00 AM -0400 10/28/99, Harald Tveit Alvestrand wrote:
> >if DNSSEC is used, not only the example.org zone must be secured, but also
> >the _tcp.example.org zone - NXT must be used to protect against the
> >gratuitous insertion of _tcp subzones into sites that do NOT support them.
> 
> I would imagine that the _tcp. names are subdomains, not subzones.  Hence,
> the NXT would cover this...
> 
>          a      A       address
>                 NXT     _tcp.a
>          _tcp.a SRV
>                 NXT     b
>          b      A       address
>                 NXT     c
>          c      A       address
>                 NXT     _tcp.c
>          _tcp.c SRV
> 
> etc.
> 
> Edward Lewis                                                NAI Labs

	I tested this in the last DNSSEC workshop.  Ed is right.

-- 
--bill

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 29 Oct 1999 08:23:10 +0200

>         I tested this in the last DNSSEC workshop.  Ed is right.

I think this imposes the requirement that in order to be safe against a 
SRV-insertion attack, you have to use and check NXT. This still interferes 
with the ability to use dynamically-added DNS entries, doesn't it?

We all agree that a signed NXT can defend against record insertion attack.

                    Harald

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Fri, 29 Oct 1999 13:22:29 -0400

>with the ability to use dynamically-added DNS entries, doesn't it?

No, there is no interference.  (Well, at least according to the "simple
secure dynamic update" proposal by Brian Wellington.)  NXT generation is
part of the atomic processing of a dynmic update.  This does cause there to
be a private zone key present on a network-connected host, which is a
vulnerability but not a show-stopper.

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

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

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

---

From: Rob Austein <[email-masked]>
Date: Fri, 29 Oct 1999 14:35:30 -0400

Date: 	Fri, 29 Oct 1999 13:22:29 -0400
   From: 	Edward Lewis <[email-masked]>

One way of handling this (suggested to me by Steve Bellovin) would be
to use a separate key for NXT signatures.  Keep the NXT private key
online, keep the other zone key offline.  This solution is not for
everybody, but it might be a reasonable compromise in some situations.

---

From: Brian Wellington <[email-masked]>
Date: Fri, 29 Oct 1999 19:19:38 -0400 (EDT)

On Fri, 29 Oct 1999, Rob Austein wrote: 
>    secure dynamic update" proposal by Brian Wellington.)  NXT generation
>    is part of the atomic processing of a dynmic update.  This does cause
>    there to be a private zone key present on a network-connected host,
>    which is a vulnerability but not a show-stopper.

The problem with this is that if data is signed with a valid zone key,
it's considered secure.  If someone compromised the online NXT signing
key, they could sign other records with it, and a secure resolver could
not know that this was data signed with the special 'NXT only' key.  The
net result is no different than having only one zone key for a dynamic
zone, which is online.

Brian