Subject: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Sun, 11 Oct 2020 21:03:13 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-dns-zone-digest-13: Yes

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

Thanks for addressing my discuss (and comment!) points.  There are still
a few more threads to tidy up, but I'm happy with the direction we're
going.

Section 1

We (implicitly) mention "integrity" here as provided in the absence of
DNSSEC, but later in Section 1.1 we say that integrity can only be assured
when the zone is signed.  I leave it to Roman to say when his discuss is
resolved, but it seems likely that we should be consistent about which way
we go with it.

Section 1.1

It's perhaps unusual to follow "the motivation for this protocol" with "a
secondary motivation"; instead writing "the primary motivation" would reduce
the surprise at seeing a secondary motivation added later.

Section 2.2.2

This change seems to be a regression?  The value 1 in question is the
scheme value, not a Hash Algorithm value.  (I would make this a
Discuss point but I am sure we will get it resolved quickly.)

Section 3

(nit) Right now the literal reading of "identical" is that the ZONEMD and
the signature and the denial-of-existence records are identical, which
is of course nonsensical.  Perhaps adding "to the ones produced by this
procedure" or similar would reduce the stress for people who habitually
make sentence diagrams.

Section 4

I can't tell if there's a duplicate line in the XML source or not, here
(as an editing leftover), but that's my guess as to what happened.  In
particular, I'm not sure how one would query for a DS RR *in the anchor*.
If I'm reading the previous thread correctly we were only proposing to talk
about querying for (and validating) DS RRs in the parent zone, not the
anchor (whatever that means).

Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD
report" above and just say this:]"?  (I'd be fine with it, for what little
it's worth, but I don't think my opinion is anywhere close to the most
relevant one.)

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 12 Oct 2020 15:54:02 +0000

> On Oct 11, 2020, at 9:03 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

Looks like I missed that spot in when addressing Roman's point.  Now changed
to this:

   It allows a receiver of the
   zone to verify the zone's integrity and authenticity when used in
   combination with DNSSEC.

> the surprise at seeing a secondary motivation added later.

Agreed.  This has been changed.

> Discuss point but I am sure we will get it resolved quickly.)

Oops, I changed that in the wrong place.  Now it says "with Scheme value 1" there
and "with Hash Algorithm value 1" in the next section.

> procedure" or similar would reduce the stress for people who habitually

Changed to this:

   Implementations that deviate from the
   described algorithm are advised to ensure that it produces ZONEMD
   RRs, signatures, and dential-of-existence records that are identical
   to the ones generated by this procedure.

> anchor (whatever that means).

Yes indeed there was a line duplicated during editing.  Now:

       This is done by examining locally
       configured trust anchors, and, if necessary, querying for (and
       validating) DS RRs in the parent zone.

> it's worth, but I don't think my opinion is anywhere close to the most

Both you and Rob asked about this -- the possibility of overly verbose reporting.
I'd like to hear Rob's opinion.

DW

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Oct 2020 15:22:59 -0700

Hi Duane,

Thanks -- this all sounds good (and it sounds like Rob is okay with the new
thought for text about reporting, as well).

Thanks again!

-Ben