Subject: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-04.txt

From: [email-masked]
Date: Mon, 22 Oct 2018 04:32:31 -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-wessels-dns-zone-digest-04.txt
	Pages           : 26
	Date            : 2018-10-22

Abstract:
   This document describes an experimental protocol and new DNS Resource
   Record that can be used to provide an message digest over DNS zone
   data.  The ZONEMD Resource Record conveys the message digest data in
   the zone itself.  When a zone publisher includes an 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 is not designed to replace DNSSEC.  Whereas DNSSEC is designed
   to protect recursive name servers and their caches, ZONEMD protects
   applications that consume zone files, whether they be authoritative
   name servers, recursive name servers, or uses of zone file data.

   As specified at this time, ZONEMD is not designed for use in large,
   dynamic zones due to the time and resources required for digest
   calculation.  The ZONEMD record described in this document includes
   fields reserved for future work to support large, dynamic zones.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-wessels-dns-zone-digest-04
https://datatracker.ietf.org/doc/html/draft-wessels-dns-zone-digest-04

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

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: Bob Harold <[email-masked]>
Date: Mon, 22 Oct 2018 12:53:28 -0400

> https://www.ietf.org/rfcdiff?url2=draft-wessels-dns-zone-digest-04

Just my opinions:

Keep the Reserved field

Include occluded data - it is part of the zone, even if never served.
(Similar to glue data when a server has both a parent and child zone.)

If you might have multiple zonemd records not at the apex later, why not
allow them now?  Otherwise, your choice whether to restrict them.  (Someone
will find a use for them, like verifying glue records.  Everyone else can
ignore them.)

-- 
Bob Harold

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Oct 2018 22:16:41 +0000

Section 5 says:

   FOR DISCUSSION: The authors are willing to remove the Reserved field
   from this specification if the working group would prefer it.  It
   would mean, however, that a future version of this protocol designed
   to efficiently support large, dynamic zones would most likely require
   a new RR type.

Please strongly consider removing the Reserved field so that designing an way to do a message digest over a dynamic zone can be done independently.

Quite frankly, if the Reserved field isn't there and it's clear that this is for complete zones, I see no reason why this should even be considered experimental. The mic line at the presentation at the recent DNS-OARC seems to agree with wanting this for real, as soon as possible.

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 24 Oct 2018 09:49:12 +0000

> On Oct 22, 2018, at 6:53 PM, Bob Harold <[email-masked]> wrote:
> 
> Just my opinions:
> 
> Keep the Reserved field
> 
> Include occluded data - it is part of the zone, even if never served.  (Similar to glue data when a server has both a parent and child zone.)
> 
> If you might have multiple zonemd records not at the apex later, why not allow them now?  Otherwise, your choice whether to restrict them.  (Someone will find a use for them, like verifying glue records.  Everyone else can ignore them.)
> 

Thanks for the feedback, Bob.

My thought about non-apex ZONEMD records is that ZONEMD has some similarities to SOA.  They both say something about the zone has a whole, and I know some software at least rejects zones with a non-apex SOA record.  OTOH, I don't want to make things unnecessarily complex...

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 24 Oct 2018 09:57:13 +0000

> On Oct 24, 2018, at 12:16 AM, Paul Hoffman <[email-masked]> wrote:
> 
> Section 5 says:
> 

Thanks for the feedback, Paul.

Personally I feel like keeping the Reserved field is potentially useful in the future, but harmless if it never gets used. Can you say more about why keeping it prevents independent work?

I would be very happy with standards track, but to the extent the WG is skeptical I would settle for experimental at this time.

DW

---

From: Joe Abley <[email-masked]>
Date: Wed, 24 Oct 2018 12:29:33 +0200

HI Duane,

> Personally I feel like keeping the Reserved field is potentially useful in the future, but harmless if it never gets used. Can you say more about why keeping it prevents independent work?

I would also appreciate more words on that.

To my mind it's better to have a reserved field that is never used than to need a new field in the future and not have a reserved field to redefine.

> I would be very happy with standards track, but to the extent the WG is skeptical I would settle for experimental at this time.

I am mainly interested in a stable specification. I don't care what label is applied to it.

If the DNS specification ever matures to the point where we need a standards-track specification for any practical reason, cutting a new rev of this document is surely the tiniest atom of extra work imagineable.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 17:32:14 +0000

> Personally I feel like keeping the Reserved field is potentially useful in the future, but harmless if it never gets used. Can you say more about why keeping it prevents independent work?

From the earlier list discussion and your presentation at DNS-OARC, processing dynamic zones is hard, and you might make different choices based on different amounts of dynamicness (dynamicity?). This should cause developers concern about implementing ZONEMD now because there will be an expectation that they will have to implement the changes in the future.

On the other hand, if you indicate "ZONEMD is for the static zones, and there will be a different RRtype for dynamic zones", vendors can choose later whether to implement the new RRtype. As others have said, new RRtypes are cheap.

> I would be very happy with standards track, but to the extent the WG is skeptical I would settle for experimental at this time.

I am not skeptical of the current protocol: I am skeptical of unknown changes to it in the future.

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Wed, 24 Oct 2018 14:31:32 -0400

On Wed, Oct 24, 2018 at 5:49 AM Wessels, Duane <[email-masked]>
wrote:

> My thought about non-apex ZONEMD records is that ZONEMD has some
> similarities to SOA.  They both say something about the zone has a whole,
> and I know some software at least rejects zones with a non-apex SOA
> record.  OTOH, I don't want to make things unnecessarily complex...
>
> DW

Having since read more discussions on whether to keep the Reserved field, I
would say that if the Reserved field is removed, then we should only allow
one ZONEMD record, and it should be at the apex.  If we keep the Reserved
field, then let's allow ZONEMD records in other places for future use.

-- 
Bob Harold

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Oct 2018 16:44:32 -0400 (EDT)

> Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-04.txt

Duane,

It seems this document is really aiming at the root zone, even though
there is some text about making it sort of general.

What if we signed root-servers.net and allowed people to AXFR that
zone along with the root zone. Would there be any need to do any
checksumming? It seems a much simpler solution to protecting the unsigned
glue records then a new checksum method.

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 29 Oct 2018 20:36:48 +0000

> On Oct 25, 2018, at 1:44 PM, Paul Wouters <[email-masked]> wrote:
> 
> 
> 

Hi Paul,

Certainly the root zone use case is of particular interest to me, but I also
believe it is a mistake to focus narrowly on that.  I've heard others say they think
its useful in general, and I think as time goes on it will find more use cases.

> glue records then a new checksum method.

First, I don't really see how it makes things simpler.  You'd have to look
in two places (zones) rather than one.

Second, A signed root-servers.net zone doesn't cover all the root zone glue.
From the presentation I recently gave at DNS-OARC (https://indico.dns-oarc.net/event/29/contributions/656/), a root zone from August 2018 has
10,773 total RRsets, 1400 of which are signed, and 9373 are unsigned.

Whether or not root-servers.net should be signed is, IMO, a separate discussion.

DW

---

From: Joe Abley <[email-masked]>
Date: Mon, 29 Oct 2018 17:45:33 -0400

Hi all,

I have read draft-wessels-dns-zone-digest-04.

General Summary

I find this document to be generally well-written, clear and unambiguous.

I think being able to embed a checksum in a zone, which can be authenticated using DNSSEC, is generally useful. I think describing the construction and verification of that checksum in the RFC series is useful for interoperability. I like the fact that this is all optional and does not upset the camel, and experimental seems fine to me -- in fact, I think experimental and optional functionality should be welcome at all times since it provides benefit to people who might use it and does no harm to those that have no interest.

I don't find it particularly compelling for the specific use-case that I have heard mentioned by others of securing a zone transfer, for which other mechanisms (already implemented) already exist. Also, any close association of this optional, experimental thing with the required, standard business of AXFR is going to make the camel twitch.

I don't think the utility of this functionality is limited to the root zone, even if that's the obvious use-case that people can imagine today.

I think other suggestions around signing glue RRSets in order to provide a different mechanism to be able to verify the integrity of a zone by walking the set of owner names are inferior to this suggestion, since (a) they involve changes that ought to make the camel nervously edge towards the door and (b) they put the bulk of the computational burden on the receiver of the zone data rather than the originator, which I find inefficient in the extreme.

I think the general business of moving data from authoritative servers into the caches of resolvers could benefit from experimentation beyond the request/response/cache of individual RRSets. I think we should be open to the idea that we could approach that database replication problem in different ways, including alternatives to AXFR, and I think being able to design around and authenticate larger objects than an RRSet is useful. This document's functionality seems like it could help with that (and if it doesn't, it's optional and experimental; not every experiment needs to succeed in ways you expect to be useful).

Nits

The document contains a normative reference to RFC 3658 which I think is fine in the context in which it used.

The document makes frequent reference to "zone file" which I find anachronistic. Maybe it's just me, but I think we're talking about a zone object or a zone structure, and the phrase "zone file" to me suggests that we've all tripped down a time vortex, it's 1993 and Vixie hasn't even bought his first tractor yet.

This document uses "RRset" and "RRsets" rather than "RRSet" and "RSets". The RFC editor seems to have no style guide for this, but my impression is that RRSet is slightly preferable (not to me, but I'm happy to sheep with the consensus). Just thought I'd mention it.

Commentary

Section 1.2

I don't understand the benefits of suggesting that verification of a zone digest "would be implemented in name server software". The inference is that software that normally concerns itself with responding to queries should be extended to check zone digests, which seems unnecessary and contentious; in general it's not the libraries or executables in which the software live that is important but rather that there be a trusted relationship between the verification process and the software that consumes the validated zone data. I think the final paragraph could just be removed.

Section 1.3

I don't find any of these useful, but then again I have already convinced myself that zone digests as a concept are useful. I don't object to any of this. To me, the section makes the document seems a little defensive and apologetic, almost as if it's trying to persuade a reluctant professor to pass a paper. I don't think that's necessary. I refer my honourable colleagues to the earlier pulpit. You could replace the whole section with the text from 1.3.5 I think, but again it's not for me, so I should not really make suggestions.

Section 2

I think you could get an RRType assignment based on expert review without waiting for this document. I mention that simply because early implementations that use temporary/reserved codes have the habit of escaping into the wild, and can be a pain to track down. Since we have the procedural option of getting a low-friction early assignment of a type code, I think we might as well use it.

I think supporting multiple ZONEMD records per zone using different digest types might be useful if it was specified in such a way that it ensured that consumers of the ZONEMD RRSet should not fall back to other digest types if their preferred type did not work. I understand the concern about downgrade attacks in general, but in this case if the ZONEMD RRSet is signed, a downgrade attack would require the ability to replace the covering RRSIG, and if you can do that you don't need to force a downgrade, you can just replace the ZONEMD RRs' RDATA with your own and re-sign illicitly.

I think it would be handy to specify a short name for each of the four fields used in the ZONEMD RDATA, e.g. as was done in 1035 with SOA.

Section 2.1.3

You might specify what action a consumer of a ZONEMD RRSet is required to take (following this specification) in the event that it finds an RR with reserved field != 0.

Section 2.2

You don't specify the representation of unsigned decimal integers clearly enough for me to know whether leading zeros are tolerated or preferred. The example in section 2.3 makes it clear that the venerable tradition of using round brackets to encapsulate multi-line presentation formats is expected; I can't remember just now whether that's written down anywhere, but if it isn't perhaps it's worth a mention.

Section 3.1.2

I think that in the specific case mentioned the two SOA RRs are expected to be identical. I wonder whether it's worth generalising the advice to confirm that where there are multiple identical instances of RRs within a single RRSet (same owner name, RRType, RDATA, class, TTL) only one is included in the calculation of the zone digest?

Perhaps SOA is the only example of this. For the precise reasons given, calling SOA out as a well-known example would make sense even if the specification was generalised as suggested above.

Section 3.2

I think that today all structural metadata relating to the zone (the SOA and the apex NS RRSet) appear at the zone apex, and in fact the apex (informed by a referral response except in the specific case of the root zone) is the only owner name an otherwise uninformed client can know exists. For those reasons the zone apex is the only sensible place for a ZONEMD RRSet.

This did make me pause briefly and consider the case where zone A contains an apex DNAME with target in zone B, and how a client might interpret ZONEMD RRs if they were looking for them with queries and not as part of a complete zone object. Perhaps that's not a useful thing to think about (and if it's not, perhaps the document should give advice that ZONEMD RRs are recomended to be eaten fresh from the refrigerator, not after they have been left out at room temperature).

Section 3.3

I don't see the point of ZONEMD in the absence of DNSSEC. This section to me suggests that there might be a point to it. I don't know what that might be.

Section 3.4.1

See commentary on Section 3.1.2.

I think the situation suggested by the question for discussion in this section only arises if you are querying piecemeal for ZONEMD RRSets and not starting with the job of verifying the digest over a whole zone. But I haven't thought very hard about that, as should be obvious from the frequency of hand oscillation in the commentary above on section 3.2.

Section 4

As above, I don't think it's useful to specify verification of zone digests in the absence of DNSSEC. If there's no chain of trust to the apex DNSKEY RRSet, I think consumers SHOULD NOT infer anything about zone integrity.

Section 5

I am mainly ambivalent about the RESERVED field. I generally it would be better to burn another type code for a new mechanism, but I understand the consequent trade-off of having to specify carefully what behaviour should be intended in zones that contain both, perhaps where one verifies and one does not. Given that the authors already have some code and experimental results of using Merkle trees that seem promising, however, if pressed to have an opinion I would suggest keeping it.

Section 6.1

I think you should specify precisely what row you want to insert into that table as a kindness to the IANA (e.g. specify the TYPE, Value, Meaning and Reference). If you get an early assignment then the appropriate documentation will be in the corresponding template and this section can just be removed.

Section 6.2

If you want the IANA to create a new registry they need more information than is supplied here. RFC 8126 contains guidance. I'm not convinced, incidentally, that a new registry is required; seems to me that it would be cleaner to reuse the DS RR Digest Type table, but perhaps this has already been discussed and the implementation status thing is real.

Joe

> On 22 Oct 2018, at 07:32, [email-masked] wrote:
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Oct 2018 22:50:58 -0400 (EDT)

> in two places (zones) rather than one.

It would then all be using just DNSSEC, and not other kinds of
authentication or verification schemes that _also_ need DNSSEC.

> Second, A signed root-servers.net zone doesn't cover all the root zone glue.

Indeed, I was wrong there. And to turn all that glue into signed records
will be a larger task, even if assuming all newgTLDs would have signed
records for the glue in the root.

> Whether or not root-servers.net should be signed is, IMO, a separate discussion.

Yeah, I only meant in the context of this discussion.

So you convinced me that it is okay to move forward with this.

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 31 Oct 2018 23:03:51 +0000

Hi Joe, 

Thanks for the detailed review.

> On Oct 29, 2018, at 2:45 PM, Joe Abley <[email-masked]> wrote:
> 
> Hi all,
> 
> ...

Yes, Mukund pointed this out as well and it is fixed.

> This document uses "RRset" and "RRsets" rather than "RRSet" and "RSets". The RFC editor seems to have no style guide for this, but my impression is that RRSet is slightly preferable (not to me, but…

Changed to RRSet and RRSets

> I don't understand the benefits of suggesting that verification of a zone digest "would be implemented in name server software". The inference is that software that normally concerns itself with re…

The thinking here is that its best to have the verification part as close to the serving part as possible.  If there is agreement that this text is an unnecessary distraction, then it would be okay
to remove it.  It doesn't affect the protocol itself. 

The trusted relationship is key, I think.  I have heard people suggest, in the context of "hyperlocal root," that the perhaps all these millions of Internet access routers and access points should serve the root zone.  These devices have notoriously bad security, and I think it would be a mistake to assume that zone data read from its flash storage does not need to be verified before it is served.

> I think supporting multiple ZONEMD records per zone using different digest types might be useful if it was specified in such a way that it ensured that consumers of the ZONEMD RRSet should not fall…

I think you might be the first person to argue for supporting multiple ZONEMD algorithms per zone. I actually expected more.

What you're saying is that a recipient would have a list of supported algorithms, ordered by its own preference.  It finds the most-preferred ZONEMD RR, and uses only that one for verification, ignoring all others.  Correct?

> I think it would be handy to specify a short name for each of the four fields used in the ZONEMD RDATA, e.g. as was done in 1035 with SOA.

I'm open to it.

> You might specify what action a consumer of a ZONEMD RRSet is required to take (following this specification) in the event that it finds an RR with reserved field != 0.

To me this belongs in the Verifying Zone Message Digest section:

        The Reserved field MUST be checked.  If the Reserved field value
        is not zero, verification MUST NOT be considered successful.

> 
> Section 2.2
> 
> You don't specify the representation of unsigned decimal integers clearly enough for me to know whether leading zeros are tolerated or preferred.

I emulated RFC 4034 here.  I guess I'm not aware of any decimal presentation fields that prefer leading zeroes.  How would you like to see it specified?

> The example in section 2.3 makes it clear that the venerable tradition of using round brackets to encapsulate multi-line presentation formats is expected; I can't remember just now whether that's written down anywhere, but if it isn't perhaps it's worth a mention.

RFC 1034 sayeth:

3.6.1. Textual expression of RRs

  ...
  In this format, most RRs are shown on a single line, although continuation
  lines are possible using parentheses.

> I think that in the specific case mentioned the two SOA RRs are expected to be identical. I wonder whether it's worth generalising the advice to confirm that where there are multiple identical inst…

It sounds wrong to me to say that identical instances of RRs would not be allowed in a zone.

> Perhaps SOA is the only example of this. For the precise reasons given, calling SOA out as a well-known example would make sense even if the specification was generalised as suggested above.

Mukund informed me that repeated SOAs are likely less common than I believed, and probably due to
thinking in terms of "zone files" rather than zones.  Perhaps the bullet about multiple SOAs should
just be removed.

> I don't see the point of ZONEMD in the absence of DNSSEC. This section to me suggests that there might be a point to it. I don't know what that might be.

The only point would be so that you could discover accidental zone corruption, rather than intentional fiddling.

> I think the situation suggested by the question for discussion in this section only arises if you are querying piecemeal for ZONEMD RRSets and not starting with the job of verifying the digest over…

(this is in reference to occluded data).  Per discussions with others I am convinced that occluded data is still considered part of the zone, and should be included in the digest.

> As above, I don't think it's useful to specify verification of zone digests in the absence of DNSSEC. If there's no chain of trust to the apex DNSKEY RRSet, I think consumers SHOULD NOT infer anyth…

I'd like to hear from others on this point.

> If you want the IANA to create a new registry they need more information than is supplied here. RFC 8126 contains guidance. I'm not convinced, incidentally, that a new registry is required; seems t…

Good ideas, thanks.

DW

---

From: Joe Abley <[email-masked]>
Date: Wed, 31 Oct 2018 19:50:23 -0400

Hi Duane,

On 31 Oct 2018, at 19:03, Wessels, Duane <[email-masked]> wrote:

> The thinking here is that its best to have the verification part as close to the serving part as possible.  If there is agreement that this text is an unnecessary distraction, then it would be okay to remove it. It doesn't affect the protocol itself. 

There is understandable sensitivity to the idea that new protocol development work makes diversity of implementation of nameserver software more expensive, since the list of specifications to support gets ever longer. I think there's value in emphasising that this protocol is optional by avoiding any inference that modifications to nameservers are required to use it. While that's certainly an option, it's an implementation decision, not a requirement.

> What you're saying is that a recipient would have a list of supported algorithms, ordered by its own preference.  It finds the most-preferred ZONEMD RR, and uses only that one for verification, ign…

That seems reasonable, although I'm not convinced I fully understand the restriction on checking only one. Seems to me that could also be left to local policy, along with the interpretation of the case where some subset of ZONEMD RRs in a set fail verification.

> I emulated RFC 4034 here.  I guess I'm not aware of any decimal presentation fields that prefer leading zeroes.  How would you like to see it specified?

If it's good enough for 4034 then I guess it's good enough for this draft. I just always find it imprecise to specify that a value should be presented (or provided) as a decimal integer without confirming whether 123 0123 000123 and 1.23E2 are equivalently acceptable.

> It sounds wrong to me to say that identical instances of RRs would not be allowed in a zone.

It's true though, right? It's not meaningful to include more than one resource record with the same (owner,type, class, TTL, RDATA) in the same RRSet, and hence also not meaningful to include such duplicates in a single zone (which is a particular set of RRSets). I don't think RFC 1034 is explicit about this, but it's surely implied. I don't know of any nameserver software that would allow duplicates like that, though, with the possible exception of the SOA. Quite possibly I have just typed more nonsense about this than the world ever needed to see.

> thinking in terms of "zone files" rather than zones.  Perhaps the bullet about multiple SOAs should

Repeated SOAs are specified in RFC 5936 section 2.2; even if a retrieved zone never touches a disk the AXFR response is still bracketed by identical SOA RRs. I think it's reasonable to consider that framing though and not the presence of a duplicate RR in a zone structure.

> The only point would be so that you could discover accidental zone corruption, rather than intentional fiddling.

Oh, true. That might be worth spelling out.

Joe