Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-14

Note: This ballot was opened for revision 10 and is now closed.

Benjamin Kaduk (was Discuss) Yes

Comment (2020-10-11 for -13)
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.)

Erik Kline Yes

Comment (2020-10-06 for -12)
[[ nits ]]

[ section 1.2 ]

* "Whereas DNSSEC is primarily protects" ->
  "Whereas DNSSEC primarily protects"

[ section 6.2 ]

* "DNSSESC" -> "DNSSEC"

Alvaro Retana No Objection

Martin Duke No Objection

Murray Kucherawy No Objection

Comment (2020-10-07 for -12)
I support Benjamin's DISCUSS about the IANA issues.  I'd also suggest adding text about what the possible values of the "Implementation Requirement" column are and what they mean.  Further, what's the "Mnemonic" used for?  That word appears nowhere in the document other than in the column headings in this section.

Roman made some other good editorial suggestions.  Please check those out.

Section 3.3.1 says: "SIMPLE is a good choice for zones that are small and/or stable, but probably not good for zones that are large and/or dynamic."  There's no alternative presented for large/dynamic zones.  Are there plans to develop such a thing?

Robert Wilton No Objection

Comment (2020-10-08 for -12)
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

Roman Danyliw (was Discuss) No Objection

Comment (2020-10-15)
No email
send info
Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review).

Thanks for addressing my DISCUSS and COMMENTs.

Éric Vyncke No Objection

Comment (2020-10-07 for -12)
Thank you for the work put into this document. I really like the idea of protecting the zone integrity even at rest.

Please find below one non-blocking COMMENT points and one nit. I would really appreciate a reply for my comment about section 1.2.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 1.2 --
Why is draft-ietf-dprive-xfr-over-tls not mentioned in this section as an alternative for data on the move?

== NITS ==
-- Section 1.4.3 --
Suggest to add "(RPZ)" after the first use of the expansion.

Warren Kumari Recuse

Comment (2020-09-23 for -10)
No email
send info
'm a'norther

(Barry Leiba; former steering group member) Yes

Yes ( for -10)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-10-07 for -12)
No email
send info
I support Benjamin's DISCUSS.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -12)
No email
send info