[DNSOP] [Errata Verified] RFC8078 (5049)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 10 August 2017 13:30 UTC

To: Ondrej.Caletka@cesnet.cz, olafur+ietf@cloudflare.com, pwouters@redhat.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: warren@kumari.net, iesg@ietf.org, dnsop@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20170810133030.B840FB81B5A@rfc-editor.org>
Date: Thu, 10 Aug 2017 06:30:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/l7hPBRbVIRybScg_4u-hqXwa9mo>
Subject: [DNSOP] [Errata Verified] RFC8078 (5049)
Precedence: list

The following errata report has been verified 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

--------------------------------------
Status: Verified
Type: Technical

Reported by: Ondřej Caletka <Ondrej.Caletka@cesnet.cz>
Date Reported: 2017-06-23
Verified by: Warren Kumari (IESG)

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

[ AD Note: Discussion on the DNSOP list: - https://www.ietf.org/mail-archive/web/dnsop/current/msg20267.html ]

--------------------------------------
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] [Errata Verified] RFC8078 (5049) RFC Errata System