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

From: [email-masked]
Date: Mon, 21 Sep 2020 10:41:35 -0700

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/

---

From: Michael StJohns <[email-masked]>
Date: Mon, 21 Sep 2020 14:26:44 -0400

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, [email-masked] wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Michael StJohns <[email-masked]>
Date: Mon, 21 Sep 2020 15:06:03 -0400

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 21 Sep 2020 17:16:19 -0400

I just put it into IESG Evaluation a couple of hours ago.  The recent
changes were to address the SecDir review, which you can see here:
https://mailarchive.ietf.org/arch/msg/secdir/RYS_YRmcHvwEauT-6UhvtqSJ9-8/

Barry

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 23 Sep 2020 16:40:40 +0000

Mike & everyone,

Here's a response on behalf of the coauthors.

> On Sep 21, 2020, at 12:06 PM, Michael StJohns <[email-masked]> wrote:
> 
> 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
> 
> 
>> 1.4.4 - "has not been modified." -> "has not been modified between origination and retrieval."

That proposed addition is fine with us, but note that sentence is not new
and hasn't changed since Oct 2018.

>> 
>> 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"".

"and MUST be implemented" was added based on advice from the SECDIR review.
Previously there was no discussion of implementation requirements in this
section.  Our opinion is that MUST is appropriate here.

The suggestion to change from MUST to SHOULD just because there are private
code points seems strange.

>> 
>> 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".

Language here probably depends on whether or not 2.2.2 needs changes.  Our
opinion is that "SHA384 MUST be implemented" is preferred and sufficient.

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

I think you're referring to this changed sentence in 2.2.4, which was made
in response to the SECDIR review:

OLD: The Digest field MUST NOT be empty.

NEW: The Digest field MUST NOT be shorter than 12 octets.

We're not sure if you're referring to the idea that longer hashes could
be truncated.  We are not suggesting that.  2.2.3 also says:

  When SHA384 is used, the size of the Digest field is 48 octets.

and similarly for SHA512 at 64 octets.  Also there is a new paragraph in
4(5)(D) which says:

      D.  The Digest field size MUST be checked.  If the size of the
          given Digest field is smaller than 12 octets, or if the size
          is not equal to the size expected for the corresponding Hash
          Algorithm, verification MUST NOT be considered successful
          with this ZONEMD RR and the verifier SHOULD report that the
          RR's digest could not be verified to to an incorrect digest
          length.

I see for RFC 4509 (SHA-256 for DS RRs) says "The results of the digest
algorithm MUST NOT be truncated."  Are you suggesting the same language
for this draft?

On the other hand, if you're just wondering where 12 came from (versus
some other value), that was Donald's suggestion ("Typical minimum size for
such a field in IETF protocols seems to be 96 bits or 12 octets").

>> 
>> 3.1 - "It is RECOMMENDED...SOA". Add "However, the TTL of the ZONEMD record may be safely ignored during verification in all cases."

Okay.

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

This subsection below was added in response to Stephane Bortzmeyer's lastcall comments:

6.2.  DNSSESC Timing Considerations

  As with all DNSSEC signatures, the ability to perform signature
  validation of a ZONEMD record is limited in time.  If the DS
  record(s) or trust anchors for the zone to be verified are no longer
  available, the recipient cannot validate the ZONEMD RRSet.  This
  could happen even if the ZONEMD signature is still current (not
  expired), since the zone's DS record(s) may have been withdrawn
  following a KSK rollover.

  For zones where it may be important to validate a ZONEMD RRSet
  through its entire signature validity period, the zone operator
  should ensure that KSK rollover timing takes this into consideration.

All this says is that a zone that deploys ZONEMD may want to keep signature
validity periods of ZONEMD RRs in mind when thinking about a KSK rollover.

(Stephane's suggested text ended with "Verification must be timely" but
our opinion is that its better here to put the onus on the zone operator
to do the right thing if that is important to them.)

A signed zone with a ZONEMD RR will always contain the KSK and ZSK DNSKEY
RRs.  To build a chain of trust for validation, the application needs to
join the "offline" in-zone DNSSEC data with the "online" ancestor DNSSEC
data, and the link between those two is the zone's DS record.  If that DS
record is no longer there (due to a rollover) then validation could fail.
But parent zone rollover won't have any impact on whether or not the ZONEMD
zone's DS record is still there or not.

DW

>>> https://secure-web.cisco.com/1Bciq9FKQYC7LPRB_xc5DUd2eectN1vID6gMeVeUvZjsC9YJ6gR0Y1X9uKqk-E2hG-aupvQW-vJixykihX8foFWsEamul7uYumJ9pTn4rB2bsVFllxWQ6oZYcw-f-GGBMzQPdjAvKUr42B5YYlZeminoQpdGMpfzqiTPiIf6vU1SKSq5s3jVaTfKuVkN-_HpvmoKQdG4kF6OOW151OV2KBsWnc2bA5IPTjW5r7J0Sa5ZoOJQAIpSdds4gNXh5I2XQKsdKzVJHoHPYxO6RVeoHvQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
>>> 
>>> https://secure-web.cisco.com/191c0vgh-YAcjBXWPCGyC3caoo2F3ilqCOrud8-TE4faxQzDDn4SgJj_5KNvmW1EazmC4NuCiiUsbyAdqYuFsa98WTDQXcDMgSv8pqeEoFb7dpJhdYd2FyraNlGPm4q7QPqIYYu5QalekRcQEy7n7nCVhgTXo0z-Xcu0PScviu0-Qc8HL0xPWtiXIzDZoPTycATAdOw3o-9NTa1QnZ8fFSeCxnAUmrQ93OmqhhLqh0nc7lPWU72oQl5JcLO3xhxSXyVbaYnClq4BUj1Bh_SFrffbcd3W-_0zt0bRg_SC2Kso/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-dnsop-dns-zone-digest-10
>>> https://secure-web.cisco.com/1o_pTg6x9j3zM6iNdwzB7XFoHZ6jjmWxkJLq1l9p422P_QEAlIIFZ8bj2jPIBDZTVt9cWgyCpAad0tlIvbbHUhMygGbbFwLCwnh0c1x87jQB2jgb3haHbnik618V_d9SYC7678tVdYSxh0dvguXLVpiQKfAUuB-o5Ln8kucsB-4rCXNhcZlsLSfM3UeckZwgKkYmpDKI5s9qb830pu_sgsTf0ktpZmExbwFHQ-WhtaU75jhTVI3ysAgHF9IoaB86ehBCXAj9GWrAU0SbaKBV4uw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dnsop-dns-zone-digest-10 
>>> 
>>> https://secure-web.cisco.com/1HGjXQI_4iLK5f4sDQfn5qQ6z9HYWmDKDJO1dAqOTnP2QwJyb371KfblT4labrcqaQFw4KICgfJ0q7J8gdnsntJq08bJFPNI9rpKF3JSaDic8n1nVza2er1QT9kny4MsnhD8LphgKurPjREbcq95d8JMRk8hj8pJ82_rOYO9Yepfr-C2Yy4uDXpB4V5POETKnRoV6BTsBElgyIeQbIcHrDhuSFV9LaDWP-hbsnbWYJ5wlB9ln4s3d1czbYruB1gpg3VXKWnuk_pe9EhmCBlNa0VrMlKfrKPzkRCV9oL4IGow/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-dnsop-dns-zone-digest-10
>>> 
>>> 
>>> https://secure-web.cisco.com/1hLFbYnvHqECH8cjYe-sOIimYA8qICY9J06FkQxqloKZx6DZXS2iEoYJbxUIedyflFr6PaoBHOv5dp0Bf9x0UVO7HHZUVo1bR5fAX3pzWitEO9Eo0rcl5hnrq5Q6Dd-xWSdMAPsO_H5PaOUNLPZvTCPJg6CeVPWDPJkDlQwMDNrFJNlGZfTcUIbUP7ucEsYZS5-k-kFrqKonOLi1gnxQH65clcnQe1tPS2Li9OeqEM7nZvQusi4KZQ3ytaibZjN34m7KqzVoPdnW35D_O4eRTudc6wDeXrzNLAn84Imv90do/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
>> 
>> 
> 
> https://secure-web.cisco.com/1hLFbYnvHqECH8cjYe-sOIimYA8qICY9J06FkQxqloKZx6DZXS2iEoYJbxUIedyflFr6PaoBHOv5dp0Bf9x0UVO7HHZUVo1bR5fAX3pzWitEO9Eo0rcl5hnrq5Q6Dd-xWSdMAPsO_H5PaOUNLPZvTCPJg6CeVPWDPJkDlQwMDNrFJNlGZfTcUIbUP7ucEsYZS5-k-kFrqKonOLi1gnxQH65clcnQe1tPS2Li9OeqEM7nZvQusi4KZQ3ytaibZjN34m7KqzVoPdnW35D_O4eRTudc6wDeXrzNLAn84Imv90do/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 23 Sep 2020 21:11:24 -0400

Hi,

Replying on just one point:

On Mon, Sep 21, 2020 at 2:27 PM Michael StJohns <[email-masked]> wrote:
> ...

Well, previously the draft said that the length of the digest field
must be larger than zero.  Do you think that the previous text implied
you could truncate to 1 byte?  There is nothing in the draft about
truncation.

This is intended to prohibit any future hash algorithm specification
(which could include a truncation operation) for ZOMEND that results
in less than 12 bytes. 96 bits seems to be a common minimum length for
disgests in the IETF although perhaps I have that impression due to
the common case of SHA-1 truncated to 96 bits. However, I note that
RFC 4635 on "HMAC SHA TSIG Algorithm Identifiers", issued in 2006,
prohibits hashes less than 10 bytes or 80 bits. If the draft is going
to specify a minimum length, I think it should be at least 96 bits.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

> ...

---

From: Michael StJohns <[email-masked]>
Date: Wed, 23 Sep 2020 21:27:46 -0400

> you could truncate to 1 byte?  There is nothing in the draft about

No - I assumed it was the full hash.  E.g. "the field can't be empty" is 
somewhat equivalent to "the length of the digest field must be greater 
than zero".

> to specify a minimum length, I think it should be at least 96 bits.

Begging still the question of whether or not the current ZONEMD hashes 
can be truncated and still be acceptable as long as they're 12  bytes or 
longer on production and transmission.

The language is ambiguous and could cause interoperability problems.

Something more like "The current hashes for the SIMPLE scheme all 
require production and inclusion of the entire length of the hash.  
Future hashes MAY be truncated, but MUST not be truncated to a length 
that's less than an equivalent to 96 bits of strength - e.g. 12 bytes 
for the SHA 2 and 3 family of hashes."

Later, Mike