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

From: [email-masked]
Date: Fri, 25 Sep 2020 13:09:21 -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-11.txt
	Pages           : 36
	Date            : 2020-09-25

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-11
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-11

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: "libor.peltan" <[email-masked]>
Date: Tue, 29 Sep 2020 11:51:08 +0200

Hi,

I don't fully know the background of this topic, so my question might be 
dumb.

Often the zone operators work with both un-signed and signed "versions" 
of their zone. The un-signed version usually comes from a registry 
system or a database, whereas a "signer" server adds "the DNSSEC stuff", 
like DNSKEYs, RRSIGs, NSECs, etc. It's also usually possible to do the 
reverse: strip DNSSEC-related records from signed zone, if needed.

I feel like it would be equally useful to maintain a digest of the 
un-signed and signed version of the zone, respectively.

Does the calculation of ZONEMD include the DNSSEC-related records? Have 
you maybe thought about including two such records, for both cases?

Thanks for comments,

Libor

Dne 25.09.20 v 22:09 [email-masked] napsal(a):
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Tue, 29 Sep 2020 09:03:19 -0400

Hi Libor,

On Sep 29, 2020, at 05:51, libor.peltan <[email-masked]> wrote:

> Often the zone operators work with both un-signed and signed "versions" of their zone. The un-signed version usually comes from a registry system or a database, whereas a "signer" server adds "the DNSSEC stuff", like DNSKEYs, RRSIGs, NSECs, etc. It's also usually possible to do the reverse: strip DNSSEC-related records from signed zone, if needed.
> 
> I feel like it would be equally useful to maintain a digest of the un-signed and signed version of the zone, respectively.

Others may have different ideas about this, but to me it makes the most sense for a particular zone that contains a ZONEMD RRSet to use it to carry a checksum of itself, not some other zone. 

The unsigned zone, as you have described it, is a different zone from the signed zone; it contains different resource records. It could contain its own ZONEMD RRSet, but that would reflect its own checksum. Since it's unsigned, its ZONEMD would also have no authenticity protection, but there could be internal, trusted environments where that was not a concern and the unsigned ZONEMD could still be useful.

For example, you could still compute a ZONEMD for an unsigned zone in order to use it to check that the zone was intact within the internal registry/signer machinery. You would replace it with a newly-computed ZONEMD once the zone had changed through the process of signing (the new ZONEMD reflects those changes).

The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate representation of the unsigned zone using the unsigned-zone ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm just not thinking hard enough?

Joe

---

From: "libor.peltan" <[email-masked]>
Date: Tue, 29 Sep 2020 15:42:05 +0200

Hi Joe,

> The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the abili…

yes, something like this.

My initial thought was that the signer, which converts the un-signed 
zone by adding signatures and keys, might not be able to compute/update 
the ZONEMD record.

It might also be useful, when the zone is only re-signed and otherwise 
unchanged, if the zone checksum was unchanged.

I'm not sure. This is just a thing to be thought of.

I would love if there was a bit flag indicating if the checksum has been 
computed including DNSSEC records, or without them. This would let the 
freedom of choice on the users, while adding some complexity to software 
implementation.

Thanks for consideration,

Libor

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 29 Sep 2020 17:16:38 +0000

> On Sep 29, 2020, at 6:42 AM, libor.peltan <[email-masked]> wrote:
> 
> Hi Joe,
> 
> My initial thought was that the signer, which converts the un-signed zone by adding signatures and keys, might not be able to compute/update the ZONEMD record.
> 
> It might also be useful, when the zone is only re-signed and otherwise unchanged, if the zone checksum was unchanged.
> 
> I would love if there was a bit flag indicating if the checksum has been computed including DNSSEC records, or without them. This would let the freedom of choice on the users, while adding some complexity to software implementation.
> 

Joe's response was very good, especially with respect to signed and unsigned being two different zones. 

During the working group discussions, we often heard the opinion that ZONEMD is not reliable without DNSSEC signatures.  Without a signature on the ZONEMD record, an adversary can easily change the digest to match changes to zone content.  I expect in most cases digest calculation will be done at the same time as zone signing.

There is no flags field, but you could probably accomplish your goal with a new or private use scheme code point.  That is, you could define a collation scheme that excludes DNSSEC RR types during digest calculation.

If there were a proposal to standardize such a scheme, the concern I would have is that it complicates the meaning of zone digest verification.  It would essentially be verifying a subset of the zone, which is not as strong as verifying the full zone.

DW