Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

Ólafur Guðmundsson <olafur@cloudflare.com> Fri, 23 June 2017 11:37 UTC

Return-Path: <olafur@cloudflare.com>
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 BFD51127342 for <dnsop@ietfa.amsl.com>; Fri, 23 Jun 2017 04:37:48 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 CE5U_F0KGlso for <dnsop@ietfa.amsl.com>; Fri, 23 Jun 2017 04:37:46 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BB812EAB2 for <dnsop@ietf.org>; Fri, 23 Jun 2017 04:37:46 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id i2so32126412qta.3 for <dnsop@ietf.org>; Fri, 23 Jun 2017 04:37:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZZdBB2QBUSch+d3wr6ued/H2MV6JVOnl1z4x+v7sdNE=; b=YcJbWWyq76ZUaX9wEkxtv9rVfuZvbCxMyM/pnujSGy0epenTMk6AomRB2boU2tobWv qrB4j0Jmvyh08ygfJTCK060TaFs2RmXVcSryDQsNUbWAWix/J5XM7S/QYqb5kA3Oj335 yCCKA/4+OISDybNvX+/UwM5zxq3muLEDhUjHc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZZdBB2QBUSch+d3wr6ued/H2MV6JVOnl1z4x+v7sdNE=; b=jTKiY4CqU7834fxJDqNQn8ySY/w6ENvbeeXMJ6Nd1MzgY8F9vQSCerfpxjHFjnHJul eecDzs5+ngJCaJrrl/UXkMv1jGPM3jJcVTzXrY6ODesDSbsc2zE8XiSjKihjLxp9ouIK Q6v0I0lCh3H9CSh04XvavvMLw/e7xfRlZ6MDFlIr3tTkK2K9AMo96lgCtm048LPQvudp jHzCAK/h9hEdjaAmI1olvJaMpjqiINP6eKUXJXMXxYtQ9XcBW7+F0m8ANKg7p1PT/llj AJB5K9aP/vnBFyUdI0I+Tk+02z1AlTmpi4SFAuigjLwvD12pFqAd/F900jCQTD2VMCGC qGdw==
X-Gm-Message-State: AKS2vOzi//GucY0JgGzMHUw9BaHIv9EuWk8n4Q5ToOP3Nft0PZY45E3i BNFtFYldqi8nPjj5+22n4Vf7tO/G3LIt
X-Received: by 10.237.40.97 with SMTP id r88mr9333869qtd.27.1498217865743; Fri, 23 Jun 2017 04:37:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.94.181 with HTTP; Fri, 23 Jun 2017 04:37:45 -0700 (PDT)
Received: by 10.140.94.181 with HTTP; Fri, 23 Jun 2017 04:37:45 -0700 (PDT)
In-Reply-To: <20170623105434.22478B810AB@rfc-editor.org>
References: <20170623105434.22478B810AB@rfc-editor.org>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Fri, 23 Jun 2017 12:37:45 +0100
Message-ID: <CAN6NTqyBg74NF-F8imGiK0ArwxAbhc0uE_xXbX-No+Le8E9DUg@mail.gmail.com>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: Warren Kumari <warren@kumari.net>, Olafur Gudmundsson <olafur+ietf@cloudflare.com>, tjw.ietf@gmail.com, pwouters@redhat.com, Ondrej.Caletka@cesnet.cz, dnsop@ietf.org, suzworldwide@gmail.com, bclaise@cisco.com
Content-Type: multipart/alternative; boundary="94eb2c068b34af1f9b05529f0704"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DFt3rxdCwR3-6E_14YQjgYTjJvU>
Subject: Re: [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 11:37:49 -0000

The errata is correct.

Ólafur

sent from phone

On Jun 23, 2017 11:54, "RFC Errata System" <rfc-editor@rfc-editor.org>
wrote:

> 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
>