Mukund, Thanks for the comments. I have incorporated most of them. I will follow up below on items I did not incorporate.
> On Oct 29, 2018, at 8:55 AM, Mukund Sivaraman <m...@mukund.org> wrote: > > After a reading, despite what is said in Section 5, I'd like to see such > a scheme to be generally useful for larger zones and zones with high > rates of updates. There are some kinds of zones in common use which can > benefit from better performance. So I recommend working on an > incremental scheme now than having multiple types of schemes later. The feedback I have received regarding this point has been mixed. I have some folks saying "make it work with stable zones now, figure out dynamic zones later" and others saying "have to support incremental updates now." The proposal to have a reserved-for-future use field is an attempt to find compromise. I personally think incremental updates can be efficiently supported with a variable-depth Merkle tree. But I have concerns about the complexity / benefit tradeoff. I presented on this at the last DNS-OARC meeting (not sure if you had a chance to see it). This is why the authors propose proceeding with the Reserved field at this time. If it later turns out we can agree on a way to support incremental updates by using this 8-bit field, then that would be great. If not, we can, as you say, consume another RR type and the wasted 8-bits stays Reserved indefinitely. > > Again, it appears use of zone *file* is incorrect. It seems to appear > several times in this memo, and I'll not repeat this observation. My apologies. I've fixed it for the next revision. > >> The root zone [InterNIC] is perhaps the most widely distributed DNS >> zone on the Internet, served by 930 separate instances [RootServers] >> at the time of this writing. > > It can be argued, but I think popular RPZ zones have a lot more > distribution. More below. [citation needed]? > > RPZ seems like a good candidate for end-to-end authentication of data > without having to trust the peer a resolver got the data from, esp. for > open(unrestricted) policy zones. Some popular RPZ zones are very large, > and change very frequently (sooner than a minute). The current memo's > performance is inadequate to be used with such zones. Out of curiosity, are these large RPZ zones signed? I ask because some people say ZONEMD is worthless without DNSSEC and, as far as I know, policy zones don't necessarily need to align with the name space. > >> 2.1.1. The Serial Field > >> The Serial field is a 32-bit unsigned integer in network order. It >> is equal to the serial number from the zone's SOA record ([RFC1035] >> section 3.3.13) for which the message digest was generated. > > Why is this field necessary? Can't the serial number be determined from > the SOA's field? This was a point of discussion in earlier revisions: FOR DISCUSSION: the serial number is included in order to make DNS response messages of type ZONEMD meaningful. Without the serial number, a stand-alone ZONEMD digest has no association to any particular zone file. If there is agreement that ZONEMD responses are not useful, this field could be removed. See also the end of Security Considerations. Based on feedback from that revision, seems like there was consensus to keep the Serial field and allow ZONEMD queries/responses. > > I had mentioned this in my first reply to an early version of this draft. > > May I implore that that you avoid other hash types and make SHA-384 as > mandatory? So many types are not needed. SHA-512(/384) is a faster hash > to calculate on many 64-bit platforms (what will be typically used by > this draft's target market) than SHA-256, and its hash construction and > size (compared to the rest of the zone) are not very different from > SHA-256 to require SHA-256 as well. Speed is good, especially in this > simplistic version of this scheme. If you want to include more hash > algorithms, pick a different hash construction such as SHA-3. I was thinking it would be useful to have ZONEMD digest types track DS digest types, so that it wouldn't require a new RFC to define a new ZONEMD digest type. But I'm not sensing much support for this approach. As an implementor, you would be okay with, say SHA384 having value 4 when used in as a DS digest type, but value 1 when used as a ZONEMD digest type? > >> For the purposes of calculating the zone digest, RRsets having the >> same owner name MUST be numerically ordered by their numeric RR TYPE. > > in ascending or descending order? (I don't blame you.. RFC 4034 also > makes no mention of that except "sorting the names"). Does "... RRsets having the same owner name MUST be processed in numerically ascending order by their numeric RR TYPE" work for you? > >> 3.1.2. Special Considerations for SOA RRs > >> When AXFR is used to transfer zone data, the first and last records >> are always the SOA RR ([RFC5936] Section 2.2). Because of this, zone >> files on disk often contain two SOA RRs. > > Is this fair to say.. the "often" part? How about "sometimes" instead of often? > >> 3. For zones that are provably signed, the SOA RR and ZONEMD RR(set) > > Isn't >1 RR for ZONEMD prohibited by this draft? The distinction > "RR(set)" isn't clear vs. "SOA RR". Yes. There was a time when the draft was less clear about single/multiple ZONEMD records and I missed this one when cleaning it up. > >> Additionally, the ZONEMD record defined in this document includes a >> Reserved field. The authors have a particular future use in mind for >> this field, namely to support efficient digests in large, dynamic >> zones. We intend to conduct future experiments using Merkle trees of >> varying depth. The choice of tree depth can be encoded in this >> reserved field. > > Sorry I'm seeing this after writing some comments earlier. This > experimental Merkle tree scheme needs to be described more thoroughly to > make sense of "depth" to be encoded in the reserved field. Assuming the document were to move forward with this reserved-for-future-use field, I'm not sure what would be the appropriate level of detail to put here. I'd rather not get too caught up in those details yet. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
