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: Derek Atkins <[email-masked]>
Date: 28 Oct 2002 22:46:55 -0500

> about providing data integrity and authentication.

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.

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.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

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

> 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.

> 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: Dan Massey <[email-masked]>
Date: Mon, 28 Oct 2002 23:43:01 -0500

> all cases even when the DS set points to ALL the keys in the set.

I strongly agree with Olafur on this.  The main point of DS was to
simplify operations and separate parent/child key management
functions.   It is technically correct that you could authenticate
KEY3 with just the DS, but doing this creates special cases for
key rollovers and essentially starts re-introducing key management
issues that DS was designed to remove.

Dan

---

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: Derek Atkins <[email-masked]>
Date: 29 Oct 2002 09:42:45 -0500

> issues that DS was designed to remove.

Oh, I agree COMPLETELY agree that you should always have two keys
at a zone apex (ZKS and KSK).. I was just:
        a) pointing out that it _could_ be done, and
        b) playing devil's advcoate for Ed's position

-derek

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Oct 2002 08:36:42 -0800

>issues that DS was designed to remove.

Yeah, but:

1) The comment launching this is that "the DS RR does not require an 
additional validation when calculating an authentication chain" 
contrary to the cited text passage. (Okay, so the requirement that 
the KEY RR set must be self-signed means that the above is true, but 
is the requirement necessary?)

What is causing the extra calculation is an operational consideration 
that is being implicitly laid upon the use of the DS RR.  Nowhere do 
we require that their must be a distinction between the KSK and ZSK. 
We've just assumed it in our workshops, which have examined primarily 
registry zones[1].

2) Requiring a separation between ZSK and KSK because of our limited 
experience in the workshops is short sighted.  Recommending it for 
registry zones is a good thing, but for leaf zones, it may prove to 
be overkill.  E.g., for cs.myuniv.edu to lab.cs.myuniv.edu, there's 
probably no need to have an extra key.

"May prove to be" - I don't know if anyone has bothered to test the 
DS RR in that situation.

[1] Registry zone = a zone that is predominately filled by numerous 
delegations and little other authoritative data.  This is not 
restricted to the root and tld's, but they are prime examples.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Oct 2002 08:35:04 -0800

Okay - there's "A secure zone MUST contain a self-signed KEY RRset at 
its apex." in the draft.  This means that the DS RR approach will 
always incur the extra SIG check.

(But the question remains - is it necessary?)

>them to sign data generated by the attacker.

If there KEYX is a bogus key, and it is slipped into the KEY RR set, 
so long as the DS(KEY3) does not point to a SIG(KEY) by KEYX, what's 
the problem?

>about providing data integrity and authentication.

But the DS refers to a specific key.  And, if the attacker could 
forge a SIG(KEY by KEY3 that does cover {KEY3, KEYX}, the attacker 
might as well just forge SIG(DATA) by KEY3.

I don't think that the SIG(KEY) is needed if there's just one KEY RR 
in a set that is referred to by a DS RR.

>In this case 128.in-addr.arpa. NS [and DS set].

Then specify that only the DS RR set of the (what's the term?) zone 
in the referral is sent.  Or open this up to requiring that all DS 
RR's at the server are to be returned.

---

From: Dan Massey <[email-masked]>
Date: Tue, 29 Oct 2002 13:12:10 -0500

>         b) playing devil's advcoate for Ed's position

Understood.  I also agree with you that technically the authentication
path would work.  My concern is that I don't see any good reason to do it.

In this case, the advantage seems to be avoiding one signature check
during SOME cases.  We know it doesn't apply during KEY roll-over
(unless you do some ugly operations that basically take us back to previous
approaches and  motivated the addition of DS).  And its not just roll-over,
there are a number of other corner cases here concerning SIG lifetimes and
other operations.     In my view, this is optimizing a specific scenario that
could
occur sometime (but would not occur using any possible operations that
people testing the stuff have been able to use/recommend)  and all this is done

the expense is  the overall design architecture.   But perhaps there aren't
enough
options, corner cases, and extra  knobs already in DNSSEC... :)

Dan

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Oct 2002 10:39:14 -0800

Diverging from the original topic of whether there should be text 
that the DS RR requires an extra SIG check -or- if the extra SIG 
check is just an artifact of our operational choice:

I was asked at a workshop if the ZSK-KSK approach was required or 
recommended.  Truthfully, I don't know what the situation is.  Are we 
going to go down the road of mandating operational considerations at 
this stage of protocol development?  Minding that the context of this 
mailing list is protocol, not operations.

I don't want to come across as being unhappy with the ZSK-KSK 
approach, especially in the registry zones, but I've seen little 
consideration further down the tree.

>path would work.  My concern is that I don't see any good reason to do it.

My sense from the person posing the question is that having to fumble 
with more than one key when it seems one would do the trick is the 
reason to use a ZSK=KSK approach.  Yes, for registry (formal 
delegations) zones the consideration is not just operational 
simplicity at the child but the interface.  But in less formal 
situations where graceful rollover isn't as hard to pull off (parent 
and child share all authoritative servers, for example), is the need 
to separate into KSK's and ZSK's a protocol/operational requirement 
(MUST)?

>during SOME cases.  We know it doesn't apply during KEY roll-over

Lessening the number of keys in the directory is one other advantage, 
along with not having to handle as many (kinds of) keys.

>people testing the stuff have been able to use/recommend)  and all 

When folks mention "corner cases" please illustrate what you mean. 
We've already had an issue with the use of the phrase and perceived 
stonewalling.  Please document any corner case you want to cite.

>options, corner cases, and extra  knobs already in DNSSEC... :)

Then let's work to reduce them.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 30 Oct 2002 08:04:43 +0100

But isn't it the case that the SIG over the DS implements the parent's policy and
the SIG over the KSK implements the childs policy wrt to signature expiration?

If you leave out the validation over the KSK you can not check on the childs policy.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Dan Massey <[email-masked]>
Date: Wed, 30 Oct 2002 10:41:54 -0500

right.

so here's one place where we start to get into more
corner cases.  suppose you don't require the child SIG
as Ed suggests and suppose you have an authenticated
DS
   case 1: there is no SIG at the child
      - implies no child policy, you accept key
   case 2: there is a valid SIG at the child
       - do you have to use it

Problem how do you know the child SIG exists or not?
   if no child SIG received, do you check an NXT to
   prove it doesn't exist?? (note you just added a check
   and the point was to remove a check on the SIG).

So do we really need this "optimization"?   Note also that no
where are we saying you must use KSK-ZSK approach. You
can use only one key if you want or build any policy you want,
the only requirement is the child keyset MUST be self signed.

Dan

---

From: Edward Lewis <[email-masked]>
Date: Wed, 30 Oct 2002 09:17:40 -0800

The SIG(KEY) at the child is the only way in which the child can make 
any statement about the crypto-freshness of the key (private/public 
pair).  Although there is no requirement that an authoritative server 
verify the signature in the SIG RR, the server is required to check 
the validity period before responding to a non-CD bit request.

Without the SIG (KEY), there is no way a zone can express the 
crypto-freshness of a key.  The SIG validity period on the SIG(DS) is 
a function of the freshness of the parent's zone key, not the child's.

Even if a child zone's management breaks down and fails to refresh 
their key, the DS RR will be maintained and the SIG (DS) will be 
continually refreshed.  But once the SIG (KEY) falls out of time, KEY 
RR will no longer be validated/distributed, resulting in a hard 
failure - which is what is desired when it comes time to debug the 
problem.

So there is a need for the SIG (KEY) record.  It doesn't provide 
crypto-protection, but it does protect against a breakdown in the 
process of refreshing the key or resigning the zone.

(Note: this has an implication for signed dynamic update zones, which 
currently still don't have a process for resigning data that isn't 
updated.)

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 30 Oct 2002 16:26:19 -0500

At 13:39 2002-10-29, Edward Lewis wrote:
>Diverging from the original topic of whether there should be text that the 
>DS RR requires an extra SIG check -or- if the extra SIG check is just an 
>artifact of our operational choice:
>
>recommended.

Not required, when I started this draft I saw DS enable of this
approach and mentioned it in passing. With each month passing I think
that KSK-ZSK is a good approach especially in cases where DNS operation
is outscored. If I had to pick a RFC2119 keyword to describe this
MAY is the strongest one I would use.

>  Truthfully, I don't know what the situation is.  Are we going to go down 
> the road of mandating operational considerations at this stage of 
> protocol development?  Minding that the context of this mailing list is 
> protocol, not operations.

I could not agree more.

>My sense from the person posing the question is that having to fumble with 
>more than one key when it seems one would do the trick is the reason to 
>use a ZSK=KSK approach.  Yes, for registry (formal delegations) zones the 
>consideration is not just operational simplicity at the child but the 
>interface.  But in less formal situations where graceful rollover isn't as 
>hard to pull off (parent and child share all authoritative servers, for 
>example), is the need to separate into KSK's and ZSK's a 
>protocol/operational requirement (MUST)?

There are going to be many zones that will only use only one KEY, but I hope
the larger ones will consider using multiple keys.

         Olafur