Subject: [DNSOP] On obsoleting DNSSEC RFCs; Example from RFC 4035

From: Дилян Палаузов <[email-masked]>
Date: Mon, 11 Nov 2019 19:07:57 +0000

Hello,

my understanding of the RFC series is, that if an RFC B obsoletes RFC A, then RFC B cannot briefly mention a subject and
refer to RFC A for details.

At  https://tools.ietf.org/html/rfc4033 , https://tools.ietf.org/html/rfc4034 and https://tools.ietf.org/html/rfc4035 is
written that these RFCs together obsolete RFC 3755 and RFC 3757.  The obsoleting text is in the Introduction of RFC
4033.

RFC 4033 Section 2 „Definitions of Important DNSSEC Terms“ says: „Key signing keys are discussed in more detail in
[RFC3757].“

In “3.1.  Data Origin Authentication and Data Integrity” it states “See [RFC3755] for details.”

RFC 4034 contains in section “2.1.1.  The Flags Field”: “Bit 15 of the Flags field is the Secure Entry Point flag,
described in [RFC3757].”

So RFC 4033 obsoletes RFC 3757, mentions briefy the term “Key signing keys” and refers to RFC 3757 for details.

This way of describing adds additional complexity for the reader to understand DNSSEC, as it is not clear in which order
to read the RFCs to understand the topics and leaves unclear, whether obsoleted RFCs shall be read.

--
I have a question about https://tools.ietf.org/html/rfc4035#appendix-A “Signed Zone Example” for the zone “example.”:

The zone contains:

  3600 DNSKEY 256 3 5 (
    AQOy1b*Yvh0z2542lzMKR4Dh8uZffQ==
  ) ;{id = 38519 (zsk), size = 1024b}
  3600 DNSKEY 257 3 5 (
    AQOeX7+*k5/j8vfd4jWCWD+E1Sze0Q==
  ) ;{id = 9465 (ksk), size = 1024b}
  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
    20040409183619 9465 example.
    ZxgauAuI*1Tp4VKDqxqG7R5tTVM=
   )
  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
    20040409183619 38519 example.
    eGL0s90g*aFzHKillDt3HRxHIZM=
  )

For brevity I have replaced some base64-encoded text with *.  The id=(zks/ksk) comments are not part of the RFCs.  I 
extracted them with ldns-read-zone.

The DNSKEY 256 is the Zone-Signing-Key with id 38519 and 257 is the Key-Signing-Key id 9465.

My understanding is that the root zone (.) has signed one DS record for the example. zone and this DS record in practice
refers to the 257 Key-Signing-Key.  Then the resolver validates that the hash in the DS record matches a KSK DNSKEY in
the zone appex and that this DNSKEY validates the RRSIG.  The valid RRSIG validates and covers all DNSKEYs, meaning the
ZSK DNSKEY is validated this way.

Why does example. zone contain a RRSIG for DNSKEY that are signend by the ZSK?

Compare to DS IANA.ORG, which returns currently six DS records for three distinct DNSKEYs with labels 6730, 14351 and
39817 (delv +short DS IANA.ORG):

6730 8 1 15A1EE709E51C0652799D9CD364A37ACB8E67285
6730 8 2 FCA03776FA33AB57369AAE8B089938F4001E208094362734242A7EBE 4DDB5755
14351 8 1 4C08C05754DDA7CCF62B41AC450873D271221CC3
14351 8 2 E1A0C92C0663202240FC3481F747D00901CD14E268B884A1142D7A47 5DB1A810
39817 8 1 4B2634F69EDD8D0741DA8629E2064B05E8138E51
39817 8 2 5FB72AE84C35A35DDF7FA24EA791CD9763C4360979C0CBB6FF2C407A F9AE5802

delv +dnssec DNSKEY IANA.ORG   returns:

DNSKEY  256 3 8 AwEAAbS+H*zJr  ; ZSK; alg = RSASHA256 ; key id = 41470
DNSKEY  256 3 8 AwEAAc0xH*yrP  ; ZSK; alg = RSASHA256 ; key id = 1723
DNSKEY  257 3 8 AwEAAa02O*qU=  ; KSK; alg = RSASHA256 ; key id = 21911
DNSKEY  257 3 8 AwEAAb0i1*Ik=  ; KSK; alg = RSASHA256 ; key id = 39817
RRSIG   DNSKEY 8 2 3600 20191127114538 20191106083616 21911 iana.org. bdC*3A==
RRSIG   DNSKEY 8 2 3600 20191127114538 20191106083616 39817 iana.org. ADP*XEQ==

So the RRSIG are signed only by KSKs (21911 and 39817) and the ZSK are not used to generate RRSIG for the DNSKEYs.  I
guess label 39817 is in a roll-over process and will disappear soon.

Why the example from RFC 4035 Appendix A generats RRSIG for DNSKEY signed by the ZSK, but for IANA.ORG there is no such
RRSIG?

If this is not the right mailing list, which is the right one?

Greetings
  Дилян

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Nov 2019 14:32:34 -0500

Hi Дилян,

> Why the example from RFC 4035 Appendix A generats RRSIG for DNSKEY signed by the ZSK, but for IANA.ORG there is no such

Some signing toolchains sign every RRSet in the a zone with the ZSK and additionally sign the DNSKEY RRSet with a KSK (in situations where both ZSK and KSK are used). Some toolchains specifically suppress the signature over the DNSKEY RRSet. Some toolchains give you one of those as a default with an option to switch to the other behaviour.

Using ZSKs and KSKs is conventional and often assumed, but perhaps it's reasonable for some implementers to worry about making assumptions and to err on the side of too many signatures. It's might not always be possible to infer intent from a single SEP bit on one RR. In a conventional scenario the signature by the ZSK over the DNSKEY RRSet is not needed, since for the ZSK to be useful the KSK must already be trusted, and the mechanism for gaining trust in a published ZSK is to verify the signature by a trusted KSK over the DNSKEY RRSet. The ZSK signature adds nothing useful.

More generally, I suppose, this is an example of the specification not demanding a particular behaviour, and implementers having the freedom to make their own decisions. In this case I can't think of a reason why the ambiguity is harmful, though.

> If this is not the right mailing list, which is the right one?

I think this is a perfectly good place to ask that question.

Joe

---

From: Дилян Палаузов <[email-masked]>
Date: Mon, 11 Nov 2019 19:39:18 +0000

Post scriptum:

these DNSSEC capable DNS servers are maintained under the DNSSEC-enabled domains
BIND → ISC.ORG
NSD → nlnetlabs.nl
PowerDNS → powerdns.com

For powerdns.com and nlnetlabs.nl, currently there is one DS label and only that KSK is used to sign the RRSIG of the
zone appex.

For isc.org there are two DS with ID 7250 and 12892 at the delegation point.  At the zone appex there two ZSK: 28347 +
27566, two KSK with labels 12892 and 7250 and four “RRSIG DNSKEY” that use each of the fourDNSKEYs to generate RRSIG.

Does it make sense to generate RRSIG for the ZSK and why 1/3 of the DNSSEC enabled sites, maintaining DNSSEC enabled DNS
servers do it?

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Nov 2019 15:47:58 -0500

> On Nov 11, 2019, at 2:39 PM, Дилян Палаузов <[email-masked]> wrote:
> 
> Does it make sense to generate RRSIG for the ZSK and why 1/3 of the DNSSEC
> enabled sites [sample size of 3], maintaining DNSSEC enabled DNS servers do it?

While it makes sense to keep DNS RRsets as small as possible,
to avoid UDP fragmentation issues, there is no prior restraint
on signing the DNSKEY RRset also with the ZSKs.

Therefore, while avoiding redundant signatures can be seen as
a best-practice it is not presently a requirement.

If you're looking for guidance on whether your DNSKEY RRsets
should be signed also with the ZSKs, the answer is generally
"no".

You're typically better off signing them with just the KSKs
(keys with the SEP bit set in their flags), provided it is
these same KSKs that match the DS RRs in the parent zone.

IIRC the SEP bit in the key flags is only a hint (generally
valid) that the key is (was, or is intended to be in the
future) one of the ones matching a DS RRset at the parent.
Ultimately, one or more key matching the DS RRs signs the
DNSKEY RRset, and one or more keys that appear in the DNSKEY
RRset sign the rest of the RRsets.

Algorithm agility means that validators may ignore some
weaker algorithms or keys in the presence of stronger
algorithms, which may necessitate signing with more than
one key in some cases, to accommodate both validators
that prefer stronger keys and validators that don't yet
support the stronger keys.

The rule of thumb is that each key algorithm that appears
in the DNSKEY RRset, should also be used to sign each RRset
with at least one key of that type.

Thus, for example, when removing a signing algorithm, one
should first remove the DS RR, then the KSK and finally the
ZSK.  When adding a new algorithm, first add a ZSK, then a
corresponding KSK, and finally the DS.  In both cases with
various delays in between to allow updated records to displace
stale cached data.

I should perhaps also note that recently many zones employing
ECDSA P-256 (algorithm 13) have dispensed with having a separate
KSK and ZSK and use the KSK also for zone signing.  Their DNSKEY
RRset has just one key.  With RSA one generally wants a 2048-bit
"long-term" KSK and a shorter (1280-bit perhaps) ZSK that should
be rotated more frequently.  A 2048-bit ZSK would result in NSEC
and especially NSEC3 response sizes that exceed recommended UDP
response size limits.

KSK == ZSK is a valid choice for ECDSA P-256 that also keeps
the DNSKEY RRset reasonably small.

The single KSK == ZSK count is quite visible in my DNSSEC survey:

  https://stats.dnssec-tools.org/#parameter

    * 3477400 algorithm 13 "KSKs" ((flags & 257) == 257)
    * 2016046 algorithm 13 "ZKSs" ((flags & 257) == 256)

The 1.46 million domain discrepancy is domains with just one key.
 
-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 Nov 2019 15:03:32 +0000

Дилян Палаузов <[email-masked]> wrote:
>
> Does it make sense to generate RRSIG for the ZSK and why 1/3 of the
> DNSSEC enabled sites, maintaining DNSSEC enabled DNS servers do it?

This is at least partly a BIND peculiarity. By default it signs the DNSKEY
RRset with all the keys. You can tell `named` to sign only with the KSK
using the `dnssec-dnskey-kskonly` option, and `dnssec-signzone` with the
`-x` option.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: North or northwest 3 to 5 increasing 6
or 7, perhaps gale 8 later, in Cromarty, Forth and east Forties. Slight or
moderate, occasionally rough. Showers. Good.