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

Dick Franks <rwfranks@acm.org> Sat, 24 June 2017 13:26 UTC

Return-Path: <rwfranks@gmail.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 10B5712871F for <dnsop@ietfa.amsl.com>; Sat, 24 Jun 2017 06:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Dh__Cxu9WPIt for <dnsop@ietfa.amsl.com>; Sat, 24 Jun 2017 06:26:22 -0700 (PDT)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 866AC127342 for <dnsop@ietf.org>; Sat, 24 Jun 2017 06:26:22 -0700 (PDT)
Received: by mail-ot0-x22a.google.com with SMTP id r67so46545701ota.1 for <dnsop@ietf.org>; Sat, 24 Jun 2017 06:26:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dr7c+l/w5JT1B18CeO3tJDGCx3JTiXZxL2O8NpiE3Ro=; b=bwOEgTqxOZ0ob+bnT5mSPK3WRrfMoXtSnnQeoEPczC6imlTUhMEKL/7NVJ0Kdxbgee Y35CKwmXazGBu34S3s9kpVo47TGAcvc2wknWAo2Dlw11Uv2MeFnQOv8Kt16JzMYQ+BKL AaqG4W+sCFyqXiVfMe0lt6yyPq3zBS0Gz9ZOvGJnwJDF9Iyv1XY2gw4ouIHZnDgdrFGK /2eb+YUcz5WIXL3xmwZSPGoCqS1p96w6DEeeuJ3ljhL0bE/rRr/6cM92M1125Nx+wlcN prvO5wV6c9X7ZIINck4nQtdbkx+pZTESlriH6qX7XnVpDTLcufA1EMAzfeRkCGF35bjW qXyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dr7c+l/w5JT1B18CeO3tJDGCx3JTiXZxL2O8NpiE3Ro=; b=b0mQvjhIzZVBC1y8FzRHa/xtYTvyd/KTh0foXhs7RuLnDS46khMhIuc6+8MVXoexnP 796/I0N09XJpuclHe114kYuB8sjJONt3j6qpIAQzQu1aPzOr3vA4Ede96lFKS3TaSc+x fVOZ907cmZr6DO/vFEZpEYFQOHiLQ4/gV7Q+bkAdxrLNKOWKBhDYfYoCX24KUp97Q+D5 GnzkRY7Zny2g9GzguaL002rIsU5hXymmSdRyIq5Qbh5feetcLPyxsBGLNywv1D0YpWrE TNQwXpD6I3k1+Hc0R4wakFLEUcVZpXOQf0WHIgyOm0UzR+hbHbXNN2YEduuEMUHEgK96 fzsA==
X-Gm-Message-State: AKS2vOymGeuCr97HYqMMusqQYXuFY2vMO1QzG5itzqvYtDrKl1LCUpwT NOEa/4LhJI/os2usCU3bXZeyxgBX3w==
X-Received: by 10.157.21.39 with SMTP id u36mr6337140otf.187.1498310781851; Sat, 24 Jun 2017 06:26:21 -0700 (PDT)
MIME-Version: 1.0
Sender: rwfranks@gmail.com
Received: by 10.182.232.163 with HTTP; Sat, 24 Jun 2017 06:25:41 -0700 (PDT)
In-Reply-To: <CAN6NTqyBg74NF-F8imGiK0ArwxAbhc0uE_xXbX-No+Le8E9DUg@mail.gmail.com>
References: <20170623105434.22478B810AB@rfc-editor.org> <CAN6NTqyBg74NF-F8imGiK0ArwxAbhc0uE_xXbX-No+Le8E9DUg@mail.gmail.com>
From: Dick Franks <rwfranks@acm.org>
Date: Sat, 24 Jun 2017 14:25:41 +0100
X-Google-Sender-Auth: v_3doeh0PgWVYJh0NjXOWU5y_os
Message-ID: <CAKW6Ri7npS57gupPrUc2aGhsg21u8csx+69GKrCFkeQ6H5Dnxw@mail.gmail.com>
To: Ólafur Guðmundsson <olafur@cloudflare.com>
Cc: RFC Editor <rfc-editor@rfc-editor.org>, tjw.ietf@gmail.com, Ondrej.Caletka@cesnet.cz, IETF DNSOP WG <dnsop@ietf.org>, suzworldwide@gmail.com, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson <olafur+ietf@cloudflare.com>
Content-Type: multipart/alternative; boundary="94eb2c18d616ea5ba20552b4a947"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KSh-XBS5baablcYNYiaUJJvCyvw>
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: Sat, 24 Jun 2017 13:26:25 -0000

 Comments in line below

On 23 June 2017 at 12:37, Ólafur Guðmundsson <olafur@cloudflare.com> wrote:

> The errata is correct.
>


I beg to disagree.

In each case,

      CDS 0 0 0 0

      CDNSKEY 0 3 0 0

the final "0" is a conventional token representing a zero-length key field.
In neither case is it an attempt to specify a single octet key value.

A zone file parser is expected to recognise the zero algorithm field and
hence abstain from attempting to parse the non-existent key.

The fact that the placeholder is unparseable should be regarded not as an
error but a useful feature designed to root out under-performing zone file
parsers.

However, all of this confusion could have been avoided if RFC8078 had also
specified the corresponding RDATA wire format in each case.

Although this erratum should be rejected as it stands, it clearly does
identify an issue with RFC8078 which needs to be rectified at the earliest
opportunity.


--Dick



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
>>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>