Duane On the zone size point, I would suggest define what you consider to be 'large' and 'very large'. Today I consider 'large' to be in the 10MM records, but in a year, I would say 'large' is 30MM records.
Tim On Mon, Jan 6, 2020 at 6:22 PM Wessels, Duane <dwessels= 40verisign....@dmarc.ietf.org> wrote: > Hello Mike, thanks for the feedback. > > > > On Jan 4, 2020, at 5:14 PM, Michael StJohns <m...@nthpermutation.com> > wrote: > > > > Hi Tim et al - > > > > I read through this back a few versions ago and mostly thought it > harmless as an experimental RFC. I'm not sure that it's quite ready for > prime time as a Standards track RFC. > > > > Here's what I think is missing: > > > > 1) A recommendation for the maximum size of the zone (and for that > matter the maximum churn rate). This is hinted at in the abstract, but > missing from the body of the document. > > I am reluctant to add this. As John said, I think it won't age well. I > think there is no obvious size at which to make a recommendation. For uses > cases such as CZDS / zone file access, I see no harm at all to add ZONEMD > for even very large zones. What might be missing is a paragraph that says > those that publish ZONEMD records need to be aware of the possible > consequences it would have on the consumers of their zone data. > > > > 2) For each of the use cases, an explanation of how this RRSet actually > mitigates or solves the identified problem. E.g. at least a paragraph each > for each the subsections of 1.3. That paragraph should lay out why the > receiver of the zone should actually want to do this verification and the > cost/benefit of that for the end user. > > As one of the coauthors I feel the use cases are pretty self explanatory, > but I'm willing to be convinced by others. > > > > 3) Section 2 uses SHOULD or MUST related to data content rather than > protocol. That's a problem in that humans are notorious for making > mistakes and screwing up the records. > > > Thanks, I think I see what you're saying. Expect changes there. > > > > > >> This section describes the ZONEMD Resource Record, including its > >> fields, wire format, and presentation format. The Type value for the > >> ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of > >> the resource record consists of four fields: Serial, Digest Type, > >> Parameter, and Digest. > >> > >> This specification utilizes ZONEMD RRs located at the zone apex. > >> Non-apex ZONEMD RRs are not forbidden, but have no meaning in this > >> specification. > >> > > Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client". > > The current text was agreed to during earlier working group discussion. > The problem with "ignore" (as John points out) is that it could mean the > non-apex RR should be omitted from the zone. > > At one point the document said that non-apex ZONEMD was forbidden, with > the implication that if found the whole zone should be rejected. Similar > to what you might do with a non-apex SOA. But that seemed pretty harsh and > in the end we settled on the current text. > > > >> > >> A zone MAY contain multiple ZONEMD RRs to support algorithm agility > >> [RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest > >> Type and Parameter tuple. > >> > > "A client that receives multiple ZONEMD RRs with the same DT and > Parameter MUST try to verify each in turn and MUST accept the zone if any > verify". > > and "If there are multiple ZONEMD RRs with distinct DT and Parameters, > the zone is acceptable if the client can verify at least one of those > RRs" > > I don't understand the use case for this. IMO multiple ZONEMD RRs with > same DT and Parameter, but different digest value is an error and should > not be allowed. > > >> It is RECOMMENDED that a zone include only > >> one ZONEMD RR, unless the zone publisher is in the process of > >> transitioning to a new Digest Type. > >> > > > > Lower case "recommended" here please. > > I don't feel too strongly about it, but can you say why? By my reading of > the key words BCP upper case is appropriate? > > > > > > 4) 2.1.3 - The parameter field MUST be set to 0 for SHA384-SIMPLE on > creation, and the client MUST NOT accept the RR if this field is not set to > zero for SHA384-SIMPLE. > > Personally I would be willing to stipulate to that, but not in 2.1.3. I > would rather it go in section 4 (verification). > > > > > 5) 3.1.2 - This is I believe different than how DNSSEC does it? If it's > the same, then this is fine, otherwise this protocol should be calculating > the RRSet wire representation the same as DNSSEC does it. > > In my experience, duplicates are suppressed either when a zone is loaded > or when it is signed. ZONEMD matches DNSSEC. > > > Here's how named-checkzone behaves: > > $ named-checkzone -i none -o /dev/fd/1 example.com /dev/fd/0 > $ORIGIN example.com. > @ 60 SOA a b 1 2 3 4 5 > @ 60 NS ns > NS 60 A 192.168.1.1 > @ 60 A 127.0.0.1 > @ 60 A 127.0.0.1 > zone example.com/IN: loaded serial 1 > example.com. 60 IN SOA > a.example.com. b.example.com. 1 2 3 4 5 > example.com. 60 IN NS > ns.example.com. > example.com. 60 IN A 127.0.0.1 > NS.example.com. 60 IN A > 192.168.1.1 > OK > > > And in ldns_dnssec_rrs_add_rr() at > https://github.com/NLnetLabs/ldns/blob/develop/dnssec_zone.c#L46 you can > see at the end that equal RRs are silently ignored. > > > > > > > > 6) 3.2 - another set of data set MUSTs (the recommended isn't an issue, > but should probably be lower case) that need guidance for the > accepting client if the MUST doesn't hold because of human error. > > Okay. > > > 7) 3.3 - Probably lower case may for DNSSEC. The rest of this is > operational guidance that really doesn't give anything useful for the > protocol. > > > > Okay. > > > > 8) 3.4.1, there is no reason whatsoever to make the setting of the > parameter field a SHOULD here. MUST is correct. > > As I said above I'm willing to make this a MUST, but I disagree there are > no reasons whatsoever. > > I think one legitimate reason would be to avoid ossification, or what I > think they call GREASE in the TLS world. > > > > > > 9) 3.4.2 - Third bullet. See above and also, as currently written here > this implies you ignore ALL RRs at that owner/class/type/RDATA if there are > duplicates. Rephrase at least. > > is this better? > > Include only one instance of duplicate RRs with equal owner, class, > type, and RDATA. > > > > > 10) 3.5 - This section needs a bit of re-working. Generally, what you > want to say is that if you have ZONEMD RRs, that they have to be published > at the same time as the matching SOA. > > I think you're focusing on the last paragraph of 3.5. I can attempt to > clarify it. > > > > You also want to probably make a note somewhere that if the SOA and > ZONEMD RR do not match on receipt you do ... something? Not sure what. > > Yes, its there, #5 in section 4. > > > > > > 11) I really need to write an RFC on "SHOULD considered harmful (if not > qualified)". For section 4, bullet 1 - explain what you mean by SHOULD - > e.g. is this a configuration option, or a implementation option. If a > configuration option, in which case might a recipient not want to do this? > If an implementation option, why isn't this a MUST? Also, if you don't do > the DNSSEC thing, identify the next step to be executed (i.e. 4). > > How about removing the SHOULD and saying "The verifier first determines > ....." ? > > > > > > 11.1) Sorry for the numbering - missed step 4 in section 4 - see point 3 > and reconcile or remove 3rd and subsequent paras from section 2 to make > this section the only normative one. > > > > 12) 4.1 vs my point 3 above - reconcile, or remove 3rd and subsequent > paras from section 2 to make this section the only normative one. > > > > 13) Missing a section 4.2 which says what you do when a zone doesn't > verify. Otherwise, what's the point? > > I'm in alignment with John Levine's responses on this. It depends. And > if folks are arguing for Experimental then I'd say it doesn't matter. > > But if the WG supports Proposed Standard and wants to see such a section > 4.2, then with the help of name server implementors I would be willing to > add a section describing what name server software should do if the zone is > signed with DNSSEC but the ZONEMD doesn't verify. > > > > > 14) Section 6.1, third paragraph is incorrect. Note that Section 4 step > 2 is part of the stuff that's skipped if the zone is provably insecure or > if you decide that SHOULD means "I'm lazy and I don't want to do it". E.g. > Section 4 does not "REQUIRE" this because of the preceding and enclosing > "RECOMMENDED". > > Okay, will try to fix that. > > > > > 15) Add a section 6.3 to security considerations which describe the > downsides of this RR - e.g. for example that it can make a zone more > fragile by requiring complete coherence in the zone and that this is a > substantial change both to DNSSEC and the original design of DNS. Or when > applied to a large dynamic zone may never be able to calculate a valid > digest in time, nor have a recipient accept it. > > I will add something to the security considerations. > > DW > > > > > > > > > > > > > I think Experimental is fine. I'm not sure without a clear text > addressing my points 1,2, 13 and 15 that this is useful as a standards > track document for general use. > > > > > > > > Later, Mike > > > > > > > > > > > > > > On 1/4/2020 5:30 PM, Tim Wicinski wrote: > >> All, > >> > >> The chairs would like to welcome the new year with some work. > >> The authors and chairs feel this document is ready to move forward. > >> > >> One thing to note: This document has the status "Experimental", but > >> the authors feel they've performed their experiments and their current > >> status is "Standards Track". > >> > >> This starts a Working Group Last Call for "Message Digest for DNS Zones" > >> > >> Current versions of the draft is available here: > >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ > >> > >> The Current Intended Status of this document is: *Standards Track* > >> Please speak out if the intended status seems incorrect. > >> > >> Please review the draft and offer relevant comments. > >> If this does not seem appropriate please speak out. > >> If someone feels the document is *not* ready for publication, > >> please speak out with your reasons. > >> > >> This starts a two week Working Group Last Call process, and ends on: > >> 18 January 2020 > >> > >> thanks > >> tim > >> > >> > >> > >> _______________________________________________ > >> DNSOP mailing list > >> > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
