[DNSOP] [Technical Errata Reported] RFC8078 (5049)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 23 June 2017 10:54 UTC
Return-Path: <wwwrun@rfc-editor.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 9BBBD1200ED for <dnsop@ietfa.amsl.com>; Fri, 23 Jun 2017 03:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QnLmC11XF9fA for <dnsop@ietfa.amsl.com>; Fri, 23 Jun 2017 03:54:56 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13A5128B51 for <dnsop@ietf.org>; Fri, 23 Jun 2017 03:54:56 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 22478B810AB; Fri, 23 Jun 2017 03:54:34 -0700 (PDT)
To: olafur+ietf@cloudflare.com, pwouters@redhat.com, bclaise@cisco.com, warren@kumari.net, suzworldwide@gmail.com, tjw.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: Ondrej.Caletka@cesnet.cz, dnsop@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20170623105434.22478B810AB@rfc-editor.org>
Date: Fri, 23 Jun 2017 03:54:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3bIH_ZLHmssjte8l6TMKJgQSDGg>
Subject: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 23 Jun 2017 10:54:58 -0000
The following errata report has been submitted for RFC8078, "Managing DS Records from the Parent via CDS/CDNSKEY". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5049 -------------------------------------- Type: Technical Reported by: Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Section: 4 Original Text ------------- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 0 CDNSKEY 0 3 0 0 The keying material payload is represented by a single 0. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 0" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Corrected Text -------------- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 00 CDNSKEY 0 3 0 AA== The keying material payload is represented by a single octet with the value 00. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X 00" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 00" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Notes ----- RFC 7344 defines both CDS and CDNSKEY record wire and presentation format to be identical to DS and DNSKEY wire and presentation format defined in RFC 4034. In case of CDNSKEY record, RFC 4034 section 2.2 requires that: > The Public Key field MUST be represented as a Base64 encoding of the Public Key. As Base64 encoding encodes 6 bits into one character, one character alone can never be a valid Base64 sequence. The proper encoding of one-byte long sequence with binary value of 00 is AA==. In case of CDS record, RFC 4034 section 5.3 requires that: > The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits Although the value of a single 0 fulfils this requirement per se, it's not properly parsable by many implementations since it is expected to be even number of hex digits to align with octet boundaries in the wire format. So proper form of CDS record should contain two zeroes in place of the digest. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8078 (draft-ietf-dnsop-maintain-ds-06) -------------------------------------- Title : Managing DS Records from the Parent via CDS/CDNSKEY Publication Date : March 2017 Author(s) : O. Gudmundsson, P. Wouters Category : PROPOSED STANDARD Source : Domain Name System Operations Area : Operations and Management Stream : IETF Verifying Party : IESG
- [DNSOP] [Technical Errata Reported] RFC8078 (5049) RFC Errata System
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Ólafur Guðmundsson
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Dick Franks
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Ondřej Caletka
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Dick Franks
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Paul Hoffman
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Dick Franks
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Matthijs Mekking
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Jan Včelák
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Paul Wouters
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Dick Franks
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Dick Franks
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Matthijs Mekking
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Dick Franks
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Mark Andrews
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Jan Včelák
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Dick Franks
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Mark Andrews
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Matthijs Mekking
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Ondřej Caletka
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Ondřej Caletka
- Re: [DNSOP] [Technical Errata Reported] RFC8078 (… Warren Kumari