[DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 08 October 2020 11:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF33A08B6; Thu, 8 Oct 2020 04:18:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dnsop-dns-zone-digest@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <160215590178.19643.8185294724542473578@ietfa.amsl.com>
Date: Thu, 08 Oct 2020 04:18:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m00-EUYHgJDkZD_1pfCTwKb6_uc>
Subject: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Oct 2020 11:18:22 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-dns-zone-digest-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank for you this document.  I found it interesting and it looks useful.

I have a few comments that may improve this document for you to please consider:

   Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash
   Algorithm defined for ZONEMD records that MUST be implemented.  When
   SHA384 is used, the size of the Digest field is 48 octets.  The
   result of the SHA384 digest algorithm MUST NOT be truncated, and the
   entire 48 octet digest is published in the ZONEMD record.

   SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for
   ZONEMD records, and SHOULD be implemented.  When SHA512 is used, the
   size of the Digest field is 64 octets.  The result of the SHA512
   digest algorithm MUST NOT be truncated, and the entire 64 octet
   digest is published in the ZONEMD record.

For consistency, perhaps change "with value 1" to "with Hash Algorithm value 1"?

    2.2.4.  The Digest Field

       The Digest field MUST NOT be shorter than 12 octets.  Digests for the
       SHA384 and SHA512 hash algorithms specified herein are never
       truncated.  Digests for future hash algorithms MAY be truncated, but
       MUST NOT be truncated to a length that results in less than 96-bits
       (12 octets) of equivalent strength.

When I read this, I wonder why the limit of 12 bytes was chosen.  Possibly a
sentence that justifies why this value was chosen might be useful, noting that
the two suggested algorithms have significantly longer digests.

    2.  The ZONEMD Resource Record

       It is
       RECOMMENDED that a zone include only one ZONEMD RR, unless the zone
       publisher is in the process of transitioning to a new Scheme or Hash
       Algorithm.

I'm not quite sure how well this fits with sections 2.2.3 restriction that
SHA384 MUST be implemented, and SHA512 SHOULD be implemented.   As a recipient
of the zone info I understand that I would need to implement both, but as a
sender am I allowed to only send SHA512, or both, or must I always send SHA384?

    3.1.  Add ZONEMD Placeholder

       In preparation for calculating the zone digest, any existing ZONEMD
       records (and covering RRSIGs) at the zone apex are first deleted.

I think that this places a requirement that all zone digests must be
constructed at the same time.  I suggest at least changing "zone digest" to
"zone digest(s)", but it might also be worth adding a sentence to highlight
that.

I was also left wondering whether it is strictly required that the zone digests
must be deleted, or just that placeholder zone digests must be used in their
place during the calculation.  E.g. what happens if a request is received to
fetch the ZONEMD record at the same time that it is being reconstructed?

4.  Verifying Zone Digest

   5.  Loop over all apex ZONEMD RRs and perform the following steps:

   ...

My, perhaps mistaken, interpretation of these error reporting instructions in
this loop is that they really assume only a single ZONEMD RR.  I.e., I wouldn't
expect the recipient to generate/return these errors if there were two ZONEMD
RR's and only one scheme/algorithm was was supported.  Yes, there is some text
at the beginning of the entire algorithm that suggests what to do here, but
further guidance here may also be helpful.  E.g. what does the server return if
there are two ZONEMD records and neither of them are acceptable for different
reasons?  I'm presuming, perhaps incorrectly, that only a single error
can/should be returned.

Regards,
Rob