Re: [DNSOP] [Technical Errata Reported] RFC8976 (6425)

"Wessels, Duane" <dwessels@verisign.com> Thu, 11 February 2021 23:40 UTC

Return-Path: <dwessels@verisign.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 E5A603A0E3B for <dnsop@ietfa.amsl.com>; Thu, 11 Feb 2021 15:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_BAD_THREAD_QP_64=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 hFvLFW2t7kao for <dnsop@ietfa.amsl.com>; Thu, 11 Feb 2021 15:40:49 -0800 (PST)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 402C33A0E37 for <dnsop@ietf.org>; Thu, 11 Feb 2021 15:40:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=11613; q=dns/txt; s=VRSN; t=1613086849; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=vzGEX500vGy4ZtQh7DTBa8p9F0W07pAIr+dcvKLe6c4=; b=hg8bTZjPDyZ94mR+RWw6hm069MVkDlD0SUf16xFW2Gtbyi0CUiKrd4Gb EK2nXMqb7GyE0o/7gp//8/8K51sl8GbISpD9ta5/J+FfPo2G/CkfW7nD1 Bx33AOO1hQNH6tRrr1oyZAxQuQtWn5ZcWhhZSNc+J3aIgu6nbaJMoOmIZ ulcvQneEadXWK3nCh52UbiX1PQFmoesR5PofhDLlm2xopGuV+5rLIJoAx VoaQ5q5sP4qWSQLtoGa26UFDJ+tGsYu915gLEl4kExQUiAZAtXg5BFHMf GAMdplX54aZDJo0YK/EfLHNlGmJaa/WeSSpbW55okUaDFt3gLRVprJ5Rk g==;
IronPort-SDR: hkJtrig7EsWNJDR+Nw5tp3WP9gpteoVy4AMokhGLBBeFSm7mw+X1E5Z336ud7FH5p3XFA4GG6K 504bjqdAxnGN6IOGVFmyOuv4SLJIE1b5jOFaZIQlp115kK5CQ9S5JSX+7XHgK4m1OashfY5bwv Lv5l798PQDEkoS8fq4UOqFyAXNlrr57gESi7u0VE8oGcUadsSQ/+IcwmKPQPfnWJ1J7kGZjwvb 53vOK32cUBV/LrSZHcI7JxVDZiASg8XQ7zlTSrUBDiIm2026JhbJc48m5ymVCO3lAYlWg0gVb6 Y/o=
X-IronPort-AV: E=Sophos; i="5.81,172,1610427600"; d="p7s'?scan'208"; a="5129953"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 11 Feb 2021 18:40:37 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2176.002; Thu, 11 Feb 2021 18:40:37 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: "Wellington, Brian" <bwelling@akamai.com>
CC: RFC Errata System <rfc-editor@rfc-editor.org>, "Barber, Piet" <pbarber@verisign.com>, "Weinberg, Matt" <matweinb@amazon.com>, Warren Kumari <warren@kumari.net>, Wes Hardaker <ietf@hardakers.net>, "rwilton@cisco.com" <rwilton@cisco.com>, "<benno@nlnetlabs.nl>" <benno@NLnetLabs.nl>, "suzworldwide@gmail.com" <suzworldwide@gmail.com>, "tjw.ietf@gmail.com" <tjw.ietf@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [Technical Errata Reported] RFC8976 (6425)
Thread-Index: AQHXAKrXkrU8fymLnkK9IgHt6lHCF6pT8RMA
Date: Thu, 11 Feb 2021 23:40:36 +0000
Message-ID: <E02F3642-0D49-4E6A-BB0D-C5E4FF7B6E58@verisign.com>
References: <20210210214825.C81B9F4073F@rfc-editor.org> <D944A6A0-C2F8-4AC7-8327-47EF396D849F@verisign.com> <9106CD0F-ABF2-4A44-87CA-B592995553CD@akamai.com>
In-Reply-To: <9106CD0F-ABF2-4A44-87CA-B592995553CD@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.4)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_0BD0D7B3-87BD-4E79-9471-589AB0754992"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8hyfvqONfx4qtc0YanZvaR_PfhM>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC8976 (6425)
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: Thu, 11 Feb 2021 23:40:51 -0000

Hi Brian,

I see what you're saying.  For implementations that treat the truncated digest as a zone parsing failure then example A.3 is not valid.

DW
  

> On Feb 11, 2021, at 11:19 AM, Wellington, Brian <bwelling@akamai.com> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> Hi Duane,
> 
> I’m not sure if I completely agree with this analysis.  The issue isn’t about validation; it’s about parsing the presentation format.   The RFC says:
> 
>   When SHA384 is used, the size of the
>   Digest field is 48 octets.  The result of the SHA384 digest algorithm
>   MUST NOT be truncated
> I’d interpret that as requiring (or at least allowing) a zone file parser to reject the example record as malformed, and fail to parse the zone.  Section 2 is describing the format of the record itself, not the process of validation, so I would expect the specific text in 2.2.3 to be applicable to parsing the record, not validating it.
> 
> Thanks,
> Brian
> 
>> On Feb 11, 2021, at 10:25 AM, Wessels, Duane <dwessels@verisign.com> wrote:
>> 
>> Brian,
>> 
>> Thank you for reporting this.  Indeed this example SHA384 digest should have 48 octets, although the A.3 example zone as a whole is still valid because a verifier will either exclude the ZONEMD RR in question either because of the private-use scheme or because it is truncated.  Since the example wasn't intended to include a truncated digest, we think the errata should be accepted and corrected.  Proposed correction:
>> 
>> example.      86400  IN  ZONEMD  2018031900 241 1 (
>>                                e1846540e33a9e41
>>                                89792d18d5d131f6
>>                                05fc283e8136a8ed
>>                                924937852d0076a3
>>                                fd5cd859c4265eaf
>>                                a8dd75c61e3dc079 )
>> 
>> DW
>> 
>> 
>>> On Feb 10, 2021, at 1:48 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>> 
>>> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
>>> 
>>> The following errata report has been submitted for RFC8976,
>>> "Message Digest for DNS Zones".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://secure-web.cisco.com/1dYEy0TvU88Njg8yutPU4SwLggJQyQtMtCFHusS4a4nwHHkd3A6abr3omPJ9EK6U3LD99P6cBoRMQRg-6Qj9F83dYEUwv96xU0ZwpAXLazBepRocQLDO8SepHSeqtdZG2kjMy8KxUal-6tWtES4U88sanGAhpTvqbNvYpBaChoyDTB8PjjI0GnW8u0axgqd-BA6e4p8QHMODXQqiosSeXaDTrRmXEn4O3Ftg-2Mg-GdvlRjRjTBwrs4Q09iRyKBYb/https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6425
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Brian Wellington <bwelling@akamai.com>
>>> 
>>> Section: A.3
>>> 
>>> Original Text
>>> -------------
>>> example.      86400  IN  ZONEMD  2018031900 241 1 (
>>>                               e1846540e33a9e41
>>>                               89792d18d5d131f6
>>>                               05fc283e )
>>> 
>>> 
>>> Corrected Text
>>> --------------
>>> <A ZONEMD record with a digest of length 48>
>>> 
>>> Notes
>>> -----
>>> 2.2.3 defines Hash Algorithm 1 as SHA384, and says that "the size of the Digest field is 48 octets". There is nothing in 2.2.3 (or 2.2.2, where Scheme is defined) that indicates that Scheme and Hash Algorithm are dependent on each other, so the fact that the Scheme value (241) is private should have no effect on the digest computed by Hash Algorithm 1.
>>> 
>>> 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. 
>>> 
>>> --------------------------------------
>>> RFC8976 (draft-ietf-dnsop-dns-zone-digest-14)
>>> --------------------------------------
>>> Title               : Message Digest for DNS Zones
>>> Publication Date    : February 2021
>>> Author(s)           : D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker
>>> Category            : PROPOSED STANDARD
>>> Source              : Domain Name System Operations
>>> Area                : Operations and Management
>>> Stream              : IETF
>>> Verifying Party     : IESG