Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

Michael StJohns <msj@nthpermutation.com> Mon, 21 September 2020 19:06 UTC

Return-Path: <msj@nthpermutation.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 411AD3A0CD0 for <dnsop@ietfa.amsl.com>; Mon, 21 Sep 2020 12:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 G5jgKzQCBKaL for <dnsop@ietfa.amsl.com>; Mon, 21 Sep 2020 12:06:06 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 705293A0CCD for <dnsop@ietf.org>; Mon, 21 Sep 2020 12:06:06 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id q10so8039297qvs.1 for <dnsop@ietf.org>; Mon, 21 Sep 2020 12:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Zy6OfgWySdrc+twlsAvL22JjiCb2xgBNO6pVBXO2Pwo=; b=q081CZ89otl30xPntBktfovq/ZA5o9K1b7sRVLCuQE5o1CXDA+zEMn6nmnNpv9HsLA +kZs06uV/h9+ZjNm45cKAqwEWuoo2MA/buqOW8KmBTKiFF+5aaz1zIPSixWg5dAjIom3 2mwqSGV8FgOXhJUQ9gTs/FbxQl+XY8HDBBb/fkfmL3vzdZgY/dSEnMlczSxvGJ7Ec8lP Nm5YjpyPR/xUgRghmFN2LMS1ypSwCOjaBGjr1awYCo9I75xK9AjFoupjcaXZr+jo5Pxz CqRls05y+zEkiHXnXN86SFF6jT3W7oXOCVBq5zTBRUkBAWeQKCvexGoedHdNS+f/g8C9 5RMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Zy6OfgWySdrc+twlsAvL22JjiCb2xgBNO6pVBXO2Pwo=; b=ihxVFdJzEulpKmwN6LHByO4Zv2uFVku81MM+OExqj1fAFado3xOatJPBSLnXG7gy4n ffC2b5hrY2LHJKHupwVZZwnOT/qXcFQ5rDa3gnH7mDXq/p6VW0b4sXz2Qp9vkBkW/Ref bSALdsya/T31M3J3b1ViXV5AgbxET3Yx29gWNVGbjQD1jfXr8O3tfsNNddzzcbqrxsEB ycevE5j9HWzCKCQKumiH8GhgITAKd+85eiNLeJ8zK4bwtXhtduu6iXWbdigEm4+NyJTM 1pVvXCpd2r/nZwh9msNKDpIY9/crBwedcSe/dihoq6xcOXlw7NrWaL1M9fW0LuHv4dqt 0cOw==
X-Gm-Message-State: AOAM5300B6Wgd4rX+WvheGtBeJFfiqgaXOBopKrZbSx3owajurjLMbl+ fuCm8UEAyhyhdx8puAHAvQqahNcfd5SSUY5AX3s=
X-Google-Smtp-Source: ABdhPJy2YxCLPcwgNmkzbZ8tr61r+6YskOQI1W9trDoxlNnzocpvgsl1v56dXmR+ajcr22pUgyUnPg==
X-Received: by 2002:a0c:f48e:: with SMTP id i14mr1689544qvm.9.1600715165158; Mon, 21 Sep 2020 12:06:05 -0700 (PDT)
Received: from [192.168.1.22] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id u18sm10972313qtk.61.2020.09.21.12.06.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2020 12:06:04 -0700 (PDT)
From: Michael StJohns <msj@nthpermutation.com>
To: dnsop@ietf.org, The IESG <iesg@ietf.org>
References: <160071009516.32585.7690187581775122560@ietfa.amsl.com> <a96ab6c1-59e8-170b-2272-ba274fbcfc45@nthpermutation.com>
Message-ID: <cb2991cf-c8db-72a4-b2c5-24d686bd59da@nthpermutation.com>
Date: Mon, 21 Sep 2020 15:06:03 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <a96ab6c1-59e8-170b-2272-ba274fbcfc45@nthpermutation.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nRtEarXg4H8CtHPY10P3PV60-WY>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt
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: Mon, 21 Sep 2020 19:06:10 -0000

Adding IESG - I didn't realize it was in IESG evaluation.

I'm not sure why this version was posted as there is nothing on the 
datatracker that indicates there were IESG issues to be resolved.  There 
are several changes that were non-editorial that really shouldn't have 
been included without WG review.  2.2.4 is the one that I would have 
problems with the most.

Mike


On 9/21/2020 2:26 PM, Michael StJohns wrote:
> 1.4.4 - "has not been modified." -> "has not been modified between 
> origination and retrieval."
>
> 2.2.2 - "MUST be implemented" -> "SHOULD be implemented. Failure to 
> implement this scheme without other standardized schemes being 
> specified may result in a receiver being unable to validate the zone.  
> However, it is possible to use ZONEMD with a private scheme, and for 
> that reason the requirement is set at "SHOULD"".
>
> 2.2.3 - "SHA384...that MUST be implemented." -> "SHA384 is the only 
> mandatory hash algorithm currently defined for the SIMPLE scheme, and 
> MUST be implemented if the SIMPLE scheme is implemented".
>
> 2.2.4 - SHA384 has a hash length of 48 bytes.  12 bytes seems to imply 
> some sort of left or right truncation.   Show stopper! Explain how 
> this value was selected and how it interacts with the native length of 
> the chosen hash. Note: I have no trouble with truncated hashes here, 
> but no modern hash has less than 20 bytes so 12 seems to be a very 
> strange number absent a discussion of truncated hashes.
>
> 3.1 - "It is RECOMMENDED...SOA". Add "However, the TTL of the ZONEMD 
> record may be safely ignored during verification in all cases."
>
> 6.2 - *sigh* No.   Basically, this allows a zone that is done ZONEMD 
> to push back on a parent zone that's doing key updates. (e.g. its not 
> the keys in the zone being ZONEMD you're concerned about in this 
> paragraph, but the keys in all of the parent zones).   Use *EXACTLY* 
> the same model for ZONEMD that DNSSEC would use and with exactly the 
> same implications for verification.   I'd delete this paragraph in its 
> entirety.
>
> Mike
>
>
> On 9/21/2020 1:41 PM, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of 
>> the IETF.
>>
>>          Title           : Message Digest for DNS Zones
>>          Authors         : Duane Wessels
>>                            Piet Barber
>>                            Matt Weinberg
>>                            Warren Kumari
>>                            Wes Hardaker
>>     Filename        : draft-ietf-dnsop-dns-zone-digest-10.txt
>>     Pages           : 36
>>     Date            : 2020-09-21
>>
>> Abstract:
>>     This document describes a protocol and new DNS Resource Record that
>>     provides a cryptographic message digest over DNS zone data. The
>>     ZONEMD Resource Record conveys the digest data in the zone itself.
>>     When a zone publisher includes a ZONEMD record, recipients can 
>> verify
>>     the zone contents for accuracy and completeness.  This provides
>>     assurance that received zone data matches published data, regardless
>>     of how the zone data has been transmitted and received.
>>
>>     ZONEMD does not replace DNSSEC.  Whereas DNSSEC protects individual
>>     RRSets (DNS data with fine granularity), ZONEMD protects a zone's
>>     data as a whole, whether consumed by authoritative name servers,
>>     recursive name servers, or any other applications.
>>
>>     As specified herein, ZONEMD is impractical for large, dynamic zones
>>     due to the time and resources required for digest calculation.
>>     However, The ZONEMD record is extensible so that new digest schemes
>>     may be added in the future to support large, dynamic zones.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-10
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-10 
>>
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-10
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>