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