Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-11

[Donald Eastlake <[e-mail]>]

Hi Duane,

Thanks for being so agreeable. As soon as a new version is posted with
the changes I'll send out a message confirming that all my comments
are resolved.

Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Mon, Sep 28, 2020 at 6:54 PM Wessels, Duane <[e-mail]> wrote:
>
>
>
> > On Sep 27, 2020, at 7:50 PM, Donald Eastlake <[e-mail]> wrote:
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG. Document editors and WG chairs should treat these comments just
> > like any other last call comments.
> >
> > The summary of the review is Ready with Nits.
> >
> > Overall, I am pretty happy with the state of the draft. Essentially
> > all of the comments from my review of -09 have been resolved and I
> > don't see any problem with other changes that have been made. However,
> > on reviewing -11, I did come up with a few things as listed below.
> >
> > Section 2, last sentence right before the Section 2.1 header, should
> > "recommended" be all capital?
>
> That change is fine with me.
>
>
> >
> > Something I didn't notice in my first review:
> > Section 2.2.1, ZONEMD already covers the SOA that is in the zone and
> > so includes the zone serial in its Digest. Thus it seems a little odd
> > to say that the field is needed to make the DNS response meaningful.
> > I'm not suggesting removing the field or anything... Perhaps some
> > wording change like the following:
> > OLD
> >   It is included here in order to make DNS response messages of type
> >   ZONEMD meaningful.  Without the serial number, a stand-alone ZONEMD
> >   digest has no association to any particular instance of a zone.
> > NEW
> >   It is included here to clearly bind the ZONEMD RR to a particular
> >   version of the zone's content. Without the serial number, a
> >   stand-alone ZONEMD digest has no obvious association to any
> >   particular instance of a zone.
>
> I think that is an improvement.
>
>
> >
> > Section 3.1, last sentence just before the Section 3.2 header: This
> > says ZONEMD RRs are excluded from digest calculation but in Section
> > 2.1 it says that non-apex ZONEMD RRs are treated are ordinary RRs and
> > included. I think that 2.1 is correct and suggest inserting the word
> > "apex" so the last sentence of Section 3.1 starts with "Since apex
> > ZONEMD RRs are excluded ..." Although less important, "apex" probably
> > should also be inserted before "ZONEMD" in the fourth and sixth bullet
> > points of Section 3.3.1.1.
>
> I don't mind inserting "apex" where you suggest.  I felt we were covered
> by the earlier statement that ZONEMD means apex ZONEMD unless stated
> otherwise, but its good to be explicit in those places.
>
>
>
> >
> > Section 5.3, the last sentence, after the table, is no longer needed,
> > since that information is given above the table, so it should be
> > deleted.
>
> Yes.
>
> > Section 6.2: Need to expand KSK on first use or alternatively, since it
> > is the only use, just not use the acronym at all and spell it out in
> > full.
>
> Done.
>
>
> >
> > Section 6.3: Size estimate for ZONEMD RR seems a bit low, perhaps
> > based on algorithms in earlier versions of the draft with shorter
> > digests. I would say 55 to 85 octets would be a better current
> > estimate.
>
> Yes indeed.  I changed it to "65 to 95" now since the smallest SHA384 SIMPLE
> RR is 65 bytes and a SHA512 SIMPLE RR for "example.com" is 93 bytes.
>
>
> >
> > Section 6.4: In the second paragraph, I think you mean "private use
> > hash algorithm code points", not "private use hash algorithms".
>
> Yes, thats better.
>
> >
> > That's it.
> >
> > Thanks,
> > Donald
>
> Thank you again.
>
> DW
>
>