Re: [DNSOP] On obsoleting DNSSEC RFCs; Example from RFC 4035 (2)

Дилян Палаузов <dilyan.palauzov@aegee.org> Mon, 11 November 2019 19:39 UTC

Return-Path: <dilyan.palauzov@aegee.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648DF120024 for <dnsop@ietfa.amsl.com>; Mon, 11 Nov 2019 11:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOz08Z4XIz7W for <dnsop@ietfa.amsl.com>; Mon, 11 Nov 2019 11:39:25 -0800 (PST)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B393C1208B0 for <dnsop@ietf.org>; Mon, 11 Nov 2019 11:39:24 -0800 (PST)
Authentication-Results: mail.aegee.org/xABJdJZe017015; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1573501162; i=dkim+MSA-tls@aegee.org; bh=cjhMOXwyQw2iXCg64X17qtjLlcOkil9jg8S8x8wYDcI=; h=Subject:From:To:Date:In-Reply-To:References; b=ZG8uRukHo0GVA+2bFu7CuJCnm/ndtaCc2IExhu/FAjEsbkPekLy/xvzzBOkGmAHyF fH/nQ4neekq4aBOyj/vWRHMg55kaTWeMD0FoW4JZmo56YtvoW+AhYaVquLI31Aj0F4 GgWuMy0NdSOft6x7RxL+6aRB/oSWlULWUJncWu8T/5+ZNKdfup+bwK170cu+pHyIbU DhWabMJCkMQC+qJzJH/XfPQB3l1S46PKCReQ118xq9fBw1CYu3nd4wic165Zyy1oPn btfRSR86Vhc6ulJADdLwlzFbCP2ls1OOWDb2JnI3UJYGe+wYyPpqi75XtnDoVCZrKg 9/2trp/IWactlKTWUtSLc6J8Q5W//2bxuz9Q7p334w++tEiP2Na4Wcd3gByuB/nd+b OPk3WMDcu+n3QJO2zvK5HDT/xtWyVLfdzdPRAkk781XRWI9zhjTS5Szft9Zx4X3fnZ FUzc4Df77x5ujcoISLAKjtNDNP7357A8c1ISfL/5mnKPPPgafRiNLRdk/YvFlI19ls ZRdeF9P9Abf0mZhP3R3iJExOywwvx6MPJhw1Ca5ohCb+mRzlyvOh27IvR+BcQHTnil JmKXogT9iwqSamv3kdOTWK/ojKJh2xkUEC2T+wsz4Qtb7Ek64mW5ulG8ei0gss4WaG /DZD//mxaIYoEZDByEDVVC+0=
Authentication-Results: mail.aegee.org/xABJdJZe017015; dkim=none
Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id xABJdJZe017015 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <dnsop@ietf.org>; Mon, 11 Nov 2019 19:39:22 GMT
Message-ID: <45da1ecde592be34b00b8fab64bcd6ee591019b4.camel@aegee.org>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <dilyan.palauzov@aegee.org>
To: dnsop@ietf.org
Date: Mon, 11 Nov 2019 19:39:18 +0000
In-Reply-To: <8f5027d509619b8dd14d821eaec6d4b050e12077.camel@aegee.org>
References: <8f5027d509619b8dd14d821eaec6d4b050e12077.camel@aegee.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.35.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.4 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cjuasoF1o-n1aUd7zPG_rrryWRI>
Subject: Re: [DNSOP] On obsoleting DNSSEC RFCs; Example from RFC 4035 (2)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 19:39:27 -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?

On Mon, 2019-11-11 at 19:07 +0000, Дилян Палаузов wrote:
> 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
>   Дилян