Subject: Delegation Signer Resource Record

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Oct 2002 11:39:13 -0400

Section 1 - isn't there an NLnet Labs report on SIG/KEY@parent?

"Storing the KEY RRset at the parent simplifies the communication." to
  Storing the KEY RR set at the parent was thought to simplify the 
communication.
                    ^                  ^^^^^^^^^^^^^^^
"Given these (and what other?) reasons, SIG/KEY@parent isn't any 
better than SIG/KEY@child."

I'm beginning to think that the last paragraph in 1 isn't really needed.

End of sect 2.1

Requiring two sig validations is no different than what happens in 
lateral signing.  The DS doesn't require two sig validations in all 
cases - if the DS points to the ZSK, there's no KSK, no need to check 
the self-signed key.

Sect 2.2.

What if the response is an answer and not a referral?  (Ie the server 
is authoritative for parent and child.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Oct 2002 17:50:29 -0500 (EST)

>   Storing the KEY RR set at the parent was thought to simplify the

applied
> better than SIG/KEY@child."

Applied

> I'm beginning to think that the last paragraph in 1 isn't really needed.

I agree, KEY restict eliminates the need for this paragraph.

Paragrpah gone.

> cases - if the DS points to the ZSK, there's no KSK, no need to check

sorry, you are wrong, DS requires two validations
	one for DS set and one for KEY set.
> is authoritative for parent and child.)

The server must know to look for DS in the parent zone as stated in
section "Special processing for DS queries.

thanks for the comments
I will push new version out late tomorrow if there are no more comments.

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Oct 2002 15:56:13 -0800

>	one for DS set and one for KEY set.

parent:
@      KEY1
        KEY2
        SIG(KEY) by KEY1
child  DS(KEY3)
        SIG(DS) by KEY2

child:
@      SOA
        SIG(SOA) by KEY3
        KEY3

Why must KEY3 be signed?  I know that if "SIG(KEY3) by KEY3" exists, 
you get a warm and fuzzy feeling, but is it's existence a MUST?

>section "Special processing for DS queries.

E.g., I issue:

    dig @a.root-servers.net 128.in-addr.arpa. soa

Do I get the DS for arpa and in-addr.arpa in the referral?  I'm 
asking in the context of this text in 2.2:

#   If DS RRset is present:
#        parent NS RRset
#        DS and SIG(DS)

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Oct 2002 21:23:01 -0500 (EST)

> you get a warm and fuzzy feeling, but is it's existence a MUST?

So, other bogus can not insert other keys into the KEY set and then use
them to sign data generated by the attacker.
Having the child KEY set signed by a "known key" whole reason, DNSSEC is
about providing data integrity and authentication.

> #   If DS RRset is present:

Only the one it is returning NS records for.
In this case 128.in-addr.arpa. NS [and DS set].

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Oct 2002 23:01:54 -0500 (EST)

On 28 Oct 2002, Derek Atkins wrote:

> Olafur Gudmundsson <[email-masked]> writes:
>
> Yes, but KEY3 _IS_ signed -- through the DS in the parent.  An
> attacker couldn't supply a "KEY4" because it would not be tied into
> the parent's DS hierarchy.

The whole point of DS is to simplify and minimize communication about
KEY's between parent and child. IFF DS is used as a signature for
KEY's in the child keyset we are in exactly same position as SIG@parent.

>
> OTOH, note that if you _DO_ have a KEY4 in the child zone you _DO_
> require a "SIG(KEY) by KEY3" record...  So it may be easier to always
> include it "just in case".  However KEY3 can certainly stand "alone"
> without a self-signature -- it's validity is certified by the
> DS/SIG(DS) in the parent.
>

Bingo, you got it. Without signature KEY3 can not enable/authorize
other KEY such as short lived zone signing keys.
It is MUCH simpler for a protocol to have one rule that applies
everywhere with no special cases.
Thus for flexibility reasons lets keep the signature on KEY set in
all cases even when the DS set points to ALL the keys in the set.

	Olafur

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Oct 2002 04:58:09 +0000

> the parent's DS hierarchy.

during the time that some important parents are not signed (. and COM)
a lot of us are just exchanging public keys for static configuration,
and thus learning of signitude by means other than DS RRs.

> DS/SIG(DS) in the parent.

i think things should be self-signed.

---

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 31 Oct 2002 09:12:32 -0500

> There are going to be many zones that will only use only one 
> KEY [have separate ZSK and KSK for DS], but I hope
> the larger ones will consider using multiple keys.

I think that many of the smaller ones will end up using
multiple keys as well--anyone who wants to do dynamic update
of a signed zone will need to keep at least *some* of the
keying material online.  Keeping only the ZSK on the
authoritative master, and keeping the KSK on an off-line
signing system, seems to be the best compromise right now
to support re-signing a zone following dynamic update.

At the most, though, the DS protocol/standard document should recommend
the use of two separate keys, rather than requiring it.  An
operational BCP should probably discuss the issues like
dynamic update of secure zones.

--
Rip Loomis                         Senior Systems Security Engineer
SAIC Secure Business Solutions Group         www.saic.com/securebiz
Center for Information Security Technology   www.cist-east.saic.com