Hello Mike, thanks for the feedback.
> On Jan 4, 2020, at 5:14 PM, Michael StJohns <[email protected]> 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 >> >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
