Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-dns-zone-digest-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Inclusion of an "implementation requirement" column in the IANA registries implies a need for a defined procedure to make changes to existing registrations. With only a "specification required" procedure, it seems there would need to be a "change controller" column as well. Furthermore, is it expected that anyone with any specification could set, e.g., an implementation requirement of "MUST"? It seems like this attribute might be better left for the RFCs defining the protocol, to be modified by an updating RFC... If we are to retain the Implementation Status appendix in the final RFC, the boilerplate will need some changes, and I think those changes should get review prior to AUTH48. For example, "at the time of posting of this Internet-Draft" will make no sense in an RFC, and the relationship to RFC 7942 is not quite as clear given that we diverge from its recommendations. "[A]ssist the IETF in its decision process" does not seem to apply after the IETF has made its decision, though the disclaimer about endorsement seems highly important to retain. This seems to be related to Roman's Discuss point, but the document seems to be inconsistent as to the primary purpose of the mechanism -- Section 1.1 says that it is to verify "authenticity" of a stand-alone zone, whereas the Introduction implies that "integrity" is primary (with authenticity as an add-on "when used in combination with DNSSEC), and the Abstract refers to "accuracy and completeness". In particular, it is easy to read references to "integrity" (and, indeed, the Abstract itself) as referring to something akin to a transport checksum instead of a cryptographic message integrity code. I think the document needs to be much more clear, and consistent, about what properties it aims to provide. (I do not believe that the "authenticity" property can be provided without DNSSEC, and Roman covers the cryptographic integrity case in his ballot position.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.2 The Transport Layer Security protocol suite also provides channel security. One can easily imagine the distribution of zones over HTTPS-enabled web servers, as well as DNS-over-HTTPS [RFC8484], and perhaps even a future version of DNS-over-TLS ([RFC7858]). I'm not sure I understand why a "future version" of DoT is needed -- while 7858 disclaims applicability outside of stub-to-recursive, is it know whether/what protocol changes would be needed, if any, to effectuate zone transfer? Section 1.2 been modified. Such modification could be the result of an accidental corruption of the file, or perhaps an incompletely saved file [disk-full-failure]. For these reasons, it is preferable to secure the data itself. "secure" is kind-of a catchall word; it would be better to use a more precise term if possible, perhaps "protect the integrity of". DNSSEC. Furthermore, zones that employ NSEC3 with opt-out are susceptible to the removal or addition of names between the signed nodes. Whereas DNSSEC is primarily protects consumers of DNS (nit) an RFC 5155 reference might be helpful here. Section 1.4.2 While I'm sure this is all true, I do wonder if there are any references available that go into more detail about the various possible setups and the problems that can arise with them. Section 1.4.3 RPZ is an individual draft that expired in 2018. Is the reference likely to have archival value? Secion 1.4.4 ICANN operates the Centralized Zone Data Service [CZDS], which is a repository of top-level domain zone files. Users that have been granted access are then able to download zone data. Adding a zone digest to these would provide CZDS users with assurances that the data has not been modified between origination and retrieval. ZONEMD could be added to CZDS zone data independently of the zone served by production name servers. I'm not entirely sure that I understand the relationship between the last two sentences. Giving (cryptographic) assurance of integrity between origination and retrieval requires that the ZONEMD be generated by the same entity doing the origination. Yet "added to the CZDS zone data independently of the zone served by the production name servers" seems to imply that there is a different entity adding ZONEMD than originating the data, which seems to contradict the previous statement. Is the intent just to say that the ZONEMD generation does not need to occur in-band with the production service even though it is managed by the same entity? Section 2 It may be better to reference RFC 7696 as BCP 201 directly. Section 3.1 If the ZONEMD contents other than digest (i.e., serial, scheme and hash algorithm) were included in the digest calculation, there are some classes of cross-algorithm attacks that would be made harder. That said, it is not entirely clear whether there will be cases where more than one digest with the same output size is defined, which is a prerequisite for this sort of cross-algorithm attack, so the risk from leaving things as-is is probably tolerable, and furthermore so since DNSSEC does protect these fields, and we seem to be strongly encouraging use of DNSSEC (see Roman's ballot position). (I assume that, given that the codepoint was allocated almost two years ago, this is already deployed and thus gratuitous wire-visible changes are ill-advised.) Section 3.3.1 "REQUIRES" is not a BCP 14 keyword. Section 3.3.1.1 o All records in the zone, including glue records, MUST be included. I suggest adding "unless excluded by a subsequent rule", so that this directive is not in conflict with all the subsequent exclusion rules. o If the zone is signed, DNSSEC RRs MUST be included, except: If the zone is not signed, there would not be any DNSSEC RRs to worry about, would there? It is not entirely clear to me how much value is added by this statement, that seems to just be repeating a subset of "all records in the zone ... MUST be included". Section 4 1. The verifier MUST first determine whether or not to expect DNSSEC records in the zone. This is done by examining locally configured trust anchors, or querying for (and validating) DS RRs in the parent zone. [...] This procedure is a bit puzzling to me. Finding valid DS RRs in the parent zone, of course, makes sense, but "examining locally configured trust anchors" I am less sure about. When would one trust anchor but not another imply that DNSSEC records should be expected? It seems to only be possible when there is additional metadata associated with locally configured trust anchors (not just the key material themself, but what zone it is associated with). Only if there is a configured trust anchor for the zone in question or a (possibly indirect) parent does querying for and validating the DS records make sense. So these two checks are not independent (as the "or" would imply) but rather, the latter is dependent on the former. A. The SOA Serial field MUST exactly match the ZONEMD Serial field. If the fields do not match, digest verification MUST NOT be considered successful with this ZONEMD RR. This step is occurring after ZONEMD RRSIG verification, so such a mismatch would seem to indicate misconfiguration on the signer. Is it wise to proceed at all (by just skipping this RR) vs considering verification to have failed? B. The Scheme field MUST be checked. If the verifier does not support the given scheme, verification MUST NOT be considered successful with this ZONEMD RR and it SHOULD report that the RR's digest could not be verified due to an unsupported scheme. This seems to be setting us up for lots of diagnostic spew whenever anyone starts publishing with a new scheme (or hash algorithm). Is the best condition for reporting that an unknown codepoint exists, or that verification failed overall and there was an unknown codepoint? (It would also feel a bit odd to report that the RR's digest could not be verified for a particular reason if/when the diget was actually verified just using a different scheme/hash-algorithm.) Section 6 Is there anything interesting to say about split-horizon DNS? Section 6.1 I suggest calling out more explicitly that "modifying the Digest field of the ZONEMD record" allows the attacker to make any zone contents appear to be valid (in the absence of DNSSEC validation). Some discussion of "cryptographic attacks only get better" and the expected need to implement algorithm agility on long timescales might also be appropriate here (I do see that we referenced RFC 7696 earlier already). Section 6.2 In security considerations, I'm used to "timing considerations" referring to time-based side-channel attacks, so it was slightly surprising to read on and discover that this is just the blunt progression of wall-clock time and signature expiration. Would "Time-Related Considerations" work? I think it might be worth adding a note that a consumer of ZONEMD might have some way of locally indicating that DNSSEC validation of a given ZONEMD record was performed successfully, so that the zone digest might still be used even if the signature is no longer validatable at some later point in time. On the other hand, this local indication would also potentially be subject to attacks, so perhaps the extra complexity of discussing those risks is not worth it. Section 6.4 I like that this was explicitly framed as a tradeoff. Section 9 Wouters, and other members of the DNS working group for their input. "DNS" seems to be a concluded working group (but "DNSOP" is currently active). Section 11.2 We seem to use RFC 5936 as the reference for "occluded data", which appears as part of "occluded data MUST be included" (ยง3.3.1.1). It's not really clear to me that the MUST implies you have to read the reference to know what occluded data is, so I don't see a huge need to move this reference to the normative section. Appendix A I trust that the digests in the ZONEMD records have been validated for all the examples (it's a bit more complicated than I want to set up from scratch, myself). I do appreciate the variety of examples and their utility as unit tests ("I'm occluded but must be digested", "I must be digested just once", etc.)! (I am a bit curious if the private-use hash algorithm 241 in A.3 is SHA-1, though ... not too many choices for native 20-octet output, though I suppose it could be truncated.) Appendix A.4, A.5 [Sometimes I ask people to update the examples to use times closer to the time of publication. This is not one of those times; these examples seem to stand just fine as-is.] _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop