Subject: [dnsext] Why do we dissipate efforts to sign the DNSKEY RRset with zsk if there is ksk in the zone?

From: "Cindy Wang" <[email-masked]>
Date: Tue, 24 Nov 2009 12:17:42 +0800

Hi all,

In the example given in In RFC 4035, Appendix A,

We have a signed zone and the DNSKEY RRSet and its corresponding RRSIGs look like:

                  3600 DNSKEY 256 3 5 (
                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
                              )
                  3600 DNSKEY 257 3 5 (
                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
                              )
                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
                              20040409183619 9465 example.
                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
                              7z5OXogYVaFzHKillDt3HRxHIZM= )

where the first DNSKEY rr is the zsk(key tag=38519) and second ksk(key tag=9465).
However, why is the RRSIG rr (key tag=38519) there? Is it of any use in the whole process? 

-----------------------------------------------
Cindy Wang
DNS Lab, CNNIC Labs
China INterent Network Information Center (CNNIC)
Phone: 8610-58813074
Email: [email-masked]
MSN: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 24 Nov 2009 15:42:51 +1100

In message <[email-masked]> <[email-masked]>, "Cindy Wang
> However, why is the RRSIG rr (key tag=38519) there? Is it of any use in the whole

The answer is: "it depends".

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 24 Nov 2009 16:56:38 +1100

In message <[email-masked]>, Mark Andrews writes:
> > We have a signed zone and the DNSKEY RRSet and its corresponding RRSIGs loo
> k like
> > :
> > 
> > 
> >                   3600 DNSKEY 256 3 5 (
> > However, why is the RRSIG rr (key tag=38519) there? Is it of any use in the
>  whole
> >  process? 
> 

Some of the things it depends on are:
* What DS are published?
* What trust anchors are publish?
* Are you moving to/from using KSKs and ZSKs?
* Does the SEP bit indicate a KSK or a ZSK?  One can reverse the sense of
	that bit.

There probably other conditions that come into play.  DNSSEC has lots of
degrees of freedom and the SEP bit is ignored by the validator.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 24 Nov 2009 07:17:50 +0100

> The answer is: "it depends".

Mark; could you please explain in what cases the ZSK signature over the apex DNSKEY RRset would be useful? (given that people don't configure a ZSK as a trust-anchor)

More recent signers, like OpenDNSSEC and IIRC BIND 9.7, by default only signs DNSKEY RRsets with the KSK. If this is a bad design, please speak up.

	jakob

---

From: Evan Hunt <[email-masked]>
Date: Tue, 24 Nov 2009 06:32:26 +0000

> More recent signers, like OpenDNSSEC and IIRC BIND 9.7, by default only
> signs DNSKEY RRsets with the KSK. If this is a bad design, please speak
> up.

Minor correction: BIND 9.7 has added an option to omit the ZSK signatures
from the DNSKEY RRset, but it doesn't do so by default.

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 24 Nov 2009 17:45:53 +1100

In message <[email-masked]>, Jakob Schlyter writ
es:
> >> where the first DNSKEY rr is the zsk(key tag=3D38519) and second =
> ksk(key tag=3D9465).
> >> However, why is the RRSIG rr (key tag=3D38519) there? Is it of any =
> use in the whole
> >> process?=20
> >=20
> Mark; could you please explain in what cases the ZSK signature over the =
> apex DNSKEY RRset would be useful? (given that people don't configure a =
> ZSK as a trust-anchor)

What was the previous DNSKEY RRset?  When was the DNSKEY RRset last
changed?  When was the DS RRset last changed?  What was the TTL of
the previos DS RRset?  What was the TTL of the previous DNSKEY
RRset?

In steady state where you are using KSKs and ZSKs the signature
isn't needed.  But there are corner cases where it is needed and
failing to provide it will result in validation failures.

> More recent signers, like OpenDNSSEC and IIRC BIND 9.7, by default only =
> signs DNSKEY RRsets with the KSK. If this is a bad design, please speak =
> up.

You have to explicitly tell named and dnssec-signzone to not sign
the DNSKEY RRset with a ZSK.  The default is to sign with all active
keys.  We don't assume that it is safe to drop the RRsig.

---

From: Michael Graff <[email-masked]>
Date: Tue, 24 Nov 2009 08:31:15 -0600

> failing to provide it will result in validation failures.

If KSKs are not used (which is a perfectly valid option) then the ZSKs
must obviously sign the zone.  This is easily detected by tools.

If the KSK is used and used as intended (that is, "best practice") and
the ZSKs are purely internal to the zone only, then the ZSK need not
sign the DNSKEY RRSet.  This is not so easily detected by tools, but...

If the admin is doing something strange and using ZSK to mean KSK and
KSK to mean ZSK, then all bets off and they deserve what they get:  more
work because they are fighting convention.  They shouldn't get a broken
zone no matter what they try, but they should have to specify this
unconventional configuration to the tools they are using.

- --Michael

---

From: "Roy Arends" <[email-masked]>
Date: Tue, 24 Nov 2009 17:39:09 +0000

> However, why is the RRSIG rr (key tag=38519) there? Is it of any use

The example would be just as valid without that signature there, so it is 
redundant. 

The DNSKEY RRset for .UK will have one signature, generated using the KSK. 
Saves space in responses too.

Kind regards,

Roy Arends
Sr. Researcher
Nominet UK

PS,  I'd argue that in theory, if there is just one DNSKEY in the zone, I 
don't see the point of having any signatures over the DNSKEY, though 
validators might stumble over that.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Nov 2009 08:11:45 +1100

In message <[email-masked]
> Saves space in responses too.

That's fine for .UK.

It is not fine however for a tool that does not have a mechanism
for tracking the history of keys along with the DS records that
refer to those key to not generate that signature without external
guidance.

I'm signing with one key which will become the ZSK.  I start signing
with a KSK and a ZSK.  I still need that ZSK signature.   Just
looking at the zone contents does not tell me that I need the ZSK's
signature.

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 23 Nov 2009 20:09:25 +0000

> > Saves space in responses too.

So.. this confirms that the spec allows this. That BIND will actually 
validate it.
 
> refer to those key to not generate that signature without external

I don't understand what you wrote. Would you mind rephrasing it?
 
> with a KSK and a ZSK.  I still need that ZSK signature.

Why?

> Just

You establish a chain of trust. Somehow. Solely the zone content wouldn't 
help doing this. You'd need something configured locally, and possibly a 
DS record at the parent. In all scenarios, how would a ZSK RRSIG over 
DNSKEY RRSET help, solve, be of value to the validator. Or how would 
absence of a ZSK RRSIG break things? To be a bit more abstract, given that 
a validator ignores the bit that distinguishes between ZSK and KSK, why 
would you have a signature over the DNSKEY RRSET by a key that is not 
referred to by a DS record in the parent or a configured trust anchor?

Roy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Nov 2009 12:44:12 +1100

In message <[email-masked]
rg.uk>, "Roy Arends" writes:
> This is a multipart message in MIME format.
> --=_alternative 006EBA7B80257677_=
> Content-Type: text/plain; charset="US-ASCII"
> 

	Think key rollover and all the timing issues involved.
 
> referred to by a DS record in the parent or a configured trust anchor?

	T=0 query for data in child zone.
	ZSK + RRSIG(ZSK) (ttl 1200) + DS(ZSK) + RRSIG(DS) (ttl 3600) => secure
	T=600 Add KSK to child zone, re-sign.
	Zone now has ZSK + KSK + RRSIG(KSK) (ttl 1200)
	T=601 Add DS(KSK) to parent zone.
	T=1200 DNSKEY RRset + RRSIGs expires from cache.
	T=1201 request zone data, new DNSKEY RRset fetched
	ZSK + KSK + RRSIG(KSK) (ttl 1200) + DS(ZSK) + RRSIG(DS) (ttl 1199)
		 => failure as there is not a trusted path that works.
		    cached DS does not point to a self signing DNSKEY.
	T=3601
	ZSK + KSK + RRSIG(KSK) (ttl 1200) + DS(KSK+ZSK) + RRSIG(DS) (ttl 3600)
		=> secure

	The signer does not know what is in the parent zone.  The
	signer does not know what is in caches.  Without that
	knowledge the signer cannot be sure it is safe to drop the
	ZSK RRSIG.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Tue, 24 Nov 2009 22:48:08 -0500

>	knowledge the signer cannot be sure it is safe to drop the

Where this explanation falls apart is in the failure to distinguish 
between "ZSK/KSK" and "SEP."  The former is a shorthand notation that 
has worked its way into too many places, the latter is a distinction 
that is represented by a bit in the key flags.

Let's say someone is operating a zone with just one key and it is not 
marked as an SEP key.  This single key is then configured in a 
resolver for testing purposes.  (*) Once the testing phase is 
complete the administrator wants to add an SEP key to the zone and 
use it as the "entry."

If the signing application reacts to the presence of the SEP key by 
dropping the signature by the first key, the administrator ought to 
do what "is right" - that is flip the SEP bit on the first key.  The 
signing application would then be right to add the signature back in 
- because the admin is indicating the true nature of the key.  BTW, 
the (*) signifies where the administrator made an operational error - 
that is, using the key for a purpose but not marking the key as being 
used that way.

It's not good if implementations try to cover over operational 
errors.  In general, this usually results in wasted energy.  Here, 
the waste is first in too many signatures in an already large 
response or in the need of an administrator to override default 
settings.

By default, an implementation of a DNSSEC signer ought to generate 
only signatures over the DNSKEY set from keys with the SEP bit set. 
There is no reason to sign it with any other key.  (It would be 
excusable to sign with non-SEP keys in the absence of an SEP marked 
key - but really - if there's no "SEP" then no signatures mean 
anything.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Nov 2009 15:36:14 +1100

In message <a06240800c732562fdf4c@[10.31.200.220]>, Edward Lewis writes:
> do what "is right" - that is flip the SEP bit on the first key.

Which is a new key as far as DNSSEC is concerned.  The flags are
part of the keyid.

> The 

No.  It is not a operational error.  If 4034 said all keys that are
used as trust-anchors or have DS records MUST have SEP set then it
would be a operational error.  The wg decided to not make SEP part
of the protocol and tools have to account for it not being part of
the protocol.

---

From: Michael Graff <[email-masked]>
Date: Wed, 25 Nov 2009 08:39:17 -0600

> that is represented by a bit in the key flags.

KSK, to me anyway, is a shorthand for "SEP capable."  But it does have
key flags 257, which means it's a KSK to most people.  It is not,
however, a protocol violation to use it otherwise.

The ZSK has flags 256, which is not a SEP in common practice.  It is
not, however, a protocol violation to use it as such.

These are "by convention" used in certain ways:

  KSKs are used externally as a link between parent and child through DS
or DLV records.  They are the things that get put into trusted-key
configuration in resolvers.

  ZSKs are used only within the zone, and are not intended by a
knowledgeable admin to have any other security properties other than
signing the zone and being signed by the SEP (KSK) keys.

This is by convention as much as by RFC descriptions of these keys.

- --Michael