Message Digest for DNS Zones
draft-ietf-dnsop-dns-zone-digest-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
14 | Gunter Van de Velde | Request closed, assignment withdrawn: Jon Mitchell Last Call OPSDIR review |
2024-01-26
|
14 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2021-02-01
|
14 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-01-11
|
14 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-12-15
|
14 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-11-20
|
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-11-20
|
14 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-11-20
|
14 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-11-19
|
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-11-19
|
14 | (System) | RFC Editor state changed to EDIT |
2020-11-19
|
14 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-11-19
|
14 | (System) | Announcement was received by RFC Editor |
2020-11-19
|
14 | (System) | IANA Action state changed to In Progress |
2020-11-19
|
14 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-11-19
|
14 | Cindy Morgan | IESG has approved the document |
2020-11-19
|
14 | Cindy Morgan | Closed "Approve" ballot |
2020-11-19
|
14 | Cindy Morgan | Ballot approval text was generated |
2020-11-18
|
14 | Barry Leiba | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-10-17
|
14 | Bernie Volz | Assignment of request for Telechat review by INTDIR to David Lamparter was marked no-response |
2020-10-15
|
14 | Roman Danyliw | [Ballot comment] Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). Thanks for addressing my DISCUSS and … [Ballot comment] Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). Thanks for addressing my DISCUSS and COMMENTs. |
2020-10-15
|
14 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2020-10-15
|
14 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-14.txt |
2020-10-15
|
14 | (System) | New version approved |
2020-10-15
|
14 | (System) | Request for posting confirmation emailed to previous authors: Warren Kumari , Piet Barber , Matt Weinberg , Duane Wessels , Wes Hardaker |
2020-10-15
|
14 | Duane Wessels | Uploaded new revision |
2020-10-12
|
13 | Roman Danyliw | [Ballot comment] Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). Thanks for addressing my DISCUSS and … [Ballot comment] Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). Thanks for addressing my DISCUSS and my earlier COMMENTs. --- ** Section 4. The numbered list calls zones “provably insecure” and “provable secure”. As was explained in our email exchange, this wording comes from RFC 4033. Given that "provable" means different things depending on the community, I would recommend citing the source. |
2020-10-12
|
13 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-10-11
|
13 | Benjamin Kaduk | [Ballot comment] Thanks for addressing my discuss (and comment!) points. There are still a few more threads to tidy up, but I'm happy with the … [Ballot comment] Thanks for addressing my discuss (and comment!) points. There are still a few more threads to tidy up, but I'm happy with the direction we're going. Section 1 We (implicitly) mention "integrity" here as provided in the absence of DNSSEC, but later in Section 1.1 we say that integrity can only be assured when the zone is signed. I leave it to Roman to say when his discuss is resolved, but it seems likely that we should be consistent about which way we go with it. Section 1.1 It's perhaps unusual to follow "the motivation for this protocol" with "a secondary motivation"; instead writing "the primary motivation" would reduce the surprise at seeing a secondary motivation added later. Section 2.2.2 This change seems to be a regression? The value 1 in question is the scheme value, not a Hash Algorithm value. (I would make this a Discuss point but I am sure we will get it resolved quickly.) Section 3 (nit) Right now the literal reading of "identical" is that the ZONEMD and the signature and the denial-of-existence records are identical, which is of course nonsensical. Perhaps adding "to the ones produced by this procedure" or similar would reduce the stress for people who habitually make sentence diagrams. Section 4 I can't tell if there's a duplicate line in the XML source or not, here (as an editing leftover), but that's my guess as to what happened. In particular, I'm not sure how one would query for a DS RR *in the anchor*. If I'm reading the previous thread correctly we were only proposing to talk about querying for (and validating) DS RRs in the parent zone, not the anchor (whatever that means). Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD report" above and just say this:]"? (I'd be fine with it, for what little it's worth, but I don't think my opinion is anywhere close to the most relevant one.) |
2020-10-11
|
13 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss |
2020-10-09
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-09
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-10-09
|
13 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-13.txt |
2020-10-09
|
13 | (System) | New version approved |
2020-10-09
|
13 | (System) | Request for posting confirmation emailed to previous authors: Warren Kumari , Wes Hardaker , Duane Wessels , Piet Barber , Matt Weinberg |
2020-10-09
|
13 | Duane Wessels | Uploaded new revision |
2020-10-08
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-10-08
|
12 | Robert Wilton | [Ballot comment] Thank for you this document. I found it interesting and it looks useful. I have a few comments that may improve this document … [Ballot comment] Thank for you this document. I found it interesting and it looks useful. I have a few comments that may improve this document for you to please consider: Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash Algorithm defined for ZONEMD records that MUST be implemented. When SHA384 is used, the size of the Digest field is 48 octets. The result of the SHA384 digest algorithm MUST NOT be truncated, and the entire 48 octet digest is published in the ZONEMD record. SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for ZONEMD records, and SHOULD be implemented. When SHA512 is used, the size of the Digest field is 64 octets. The result of the SHA512 digest algorithm MUST NOT be truncated, and the entire 64 octet digest is published in the ZONEMD record. For consistency, perhaps change "with value 1" to "with Hash Algorithm value 1"? 2.2.4. The Digest Field The Digest field MUST NOT be shorter than 12 octets. Digests for the SHA384 and SHA512 hash algorithms specified herein are never truncated. Digests for future hash algorithms MAY be truncated, but MUST NOT be truncated to a length that results in less than 96-bits (12 octets) of equivalent strength. When I read this, I wonder why the limit of 12 bytes was chosen. Possibly a sentence that justifies why this value was chosen might be useful, noting that the two suggested algorithms have significantly longer digests. 2. The ZONEMD Resource Record It is RECOMMENDED that a zone include only one ZONEMD RR, unless the zone publisher is in the process of transitioning to a new Scheme or Hash Algorithm. I'm not quite sure how well this fits with sections 2.2.3 restriction that SHA384 MUST be implemented, and SHA512 SHOULD be implemented. As a recipient of the zone info I understand that I would need to implement both, but as a sender am I allowed to only send SHA512, or both, or must I always send SHA384? 3.1. Add ZONEMD Placeholder In preparation for calculating the zone digest, any existing ZONEMD records (and covering RRSIGs) at the zone apex are first deleted. I think that this places a requirement that all zone digests must be constructed at the same time. I suggest at least changing "zone digest" to "zone digest(s)", but it might also be worth adding a sentence to highlight that. I was also left wondering whether it is strictly required that the zone digests must be deleted, or just that placeholder zone digests must be used in their place during the calculation. E.g. what happens if a request is received to fetch the ZONEMD record at the same time that it is being reconstructed? 4. Verifying Zone Digest 5. Loop over all apex ZONEMD RRs and perform the following steps: ... My, perhaps mistaken, interpretation of these error reporting instructions in this loop is that they really assume only a single ZONEMD RR. I.e., I wouldn't expect the recipient to generate/return these errors if there were two ZONEMD RR's and only one scheme/algorithm was was supported. Yes, there is some text at the beginning of the entire algorithm that suggests what to do here, but further guidance here may also be helpful. E.g. what does the server return if there are two ZONEMD records and neither of them are acceptable for different reasons? I'm presuming, perhaps incorrectly, that only a single error can/should be returned. Regards, Rob |
2020-10-08
|
12 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-10-07
|
12 | Murray Kucherawy | [Ballot comment] I support Benjamin's DISCUSS about the IANA issues. I'd also suggest adding text about what the possible values of the "Implementation Requirement" column … [Ballot comment] I support Benjamin's DISCUSS about the IANA issues. I'd also suggest adding text about what the possible values of the "Implementation Requirement" column are and what they mean. Further, what's the "Mnemonic" used for? That word appears nowhere in the document other than in the column headings in this section. Roman made some other good editorial suggestions. Please check those out. Section 3.3.1 says: "SIMPLE is a good choice for zones that are small and/or stable, but probably not good for zones that are large and/or dynamic." There's no alternative presented for large/dynamic zones. Are there plans to develop such a thing? |
2020-10-07
|
12 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-10-07
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-10-07
|
12 | Alissa Cooper | [Ballot comment] I support Benjamin's DISCUSS. |
2020-10-07
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-10-07
|
12 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. I really like the idea of protecting the zone integrity even at rest. Please … [Ballot comment] Thank you for the work put into this document. I really like the idea of protecting the zone integrity even at rest. Please find below one non-blocking COMMENT points and one nit. I would really appreciate a reply for my comment about section 1.2. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1.2 -- Why is draft-ietf-dprive-xfr-over-tls not mentioned in this section as an alternative for data on the move? == NITS == -- Section 1.4.3 -- Suggest to add "(RPZ)" after the first use of the expansion. |
2020-10-07
|
12 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-10-06
|
12 | Erik Kline | [Ballot comment] [[ nits ]] [ section 1.2 ] * "Whereas DNSSEC is primarily protects" -> "Whereas DNSSEC primarily protects" [ section 6.2 ] … [Ballot comment] [[ nits ]] [ section 1.2 ] * "Whereas DNSSEC is primarily protects" -> "Whereas DNSSEC primarily protects" [ section 6.2 ] * "DNSSESC" -> "DNSSEC" |
2020-10-06
|
12 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2020-10-06
|
12 | Benjamin Kaduk | [Ballot discuss] Inclusion of an "implementation requirement" column in the IANA registries implies a need for a defined procedure to make changes to existing registrations. … [Ballot 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.) |
2020-10-06
|
12 | Benjamin Kaduk | [Ballot comment] Section 1.2 The Transport Layer Security protocol suite also provides channel security. One can easily imagine the distribution of zones over … [Ballot 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.] |
2020-10-06
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-10-05
|
12 | Roman Danyliw | [Ballot discuss] Section 6.1. My read of the text is that the security properties are intended to be independent of the transport protocol. With that … [Ballot discuss] Section 6.1. My read of the text is that the security properties are intended to be independent of the transport protocol. With that assumption and the validation procedures in Section 4, I need help understanding the security properties the client can rely on in the absence of DNSSEC. Consider the following scenarios and attacker types; and the assurances a client could have when retrieving the zone file from the server: With an on-path attacker (and trusted server hosting the zone file) ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO ** No DNSSEC; Secure transport = integrity: YES (from the on-path attacker); authenticity = NO ** DNSSEC = integrity: YES; authenticity = YES With a rogue server hosting the zone file (but is not the operator of the zone) ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO ** No DNSSEC/Secure transport = integrity: NO; authenticity = NO ** DNSSEC = integrity: YES; authenticity = YES The text states that: The zone digest allows the recipient of a zone to verify its integrity. In conjunction with DNSSEC, the recipient can authenticate that it is as published by the zone originator. Can the means to realize integrity without DNSSEC unless there is a reliance on transport security of some form be clarified. Minimally, it seems like this section needs cautionary text (likely with normative language) to the effect of “ZONEMD information from zone files lacking DNSSEC support or that were shared over ‘unsecure transport’ cannot be relied upon for cryptographic integrity assurance.” |
2020-10-05
|
12 | Roman Danyliw | [Ballot comment] Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). ** Section 1. s/allowing verification of … [Ballot comment] Thank you for addressing the SECDIR review (and thank you to Donald Eastlake for performing the review). ** Section 1. s/allowing verification of the zone/allowing verification of the integrity of the zone/ ** Section 1.2. In the discussion about alternatives, it seems like the two competing designs are “channel security” vs. “data security”? Is the latter the equivalent to “object security”, a term with which I’m more familiar? That is, the data itself carries a set of security properties independent of the channel or session exchanging it. ** Section 1.3. Clarifying language. OLD As specified herein, the digest is re-calculated over the entire zone content each time NEW As specified herein, the digest is re-calculated over the entire zone content each time the zone is updated. ** Section 1.3. Editorial. The sentence “It is, however, extensible so future schemes to support incremental zone digest algorithms (e.g. using Merkle trees) can be accommodated” didn’t parse for me. ** Section 2. Per the support of multiple ZONEMD RRs, what is meant by “rollovers”? There are no keys here. It seems like multiple ZONEMD would be there for algorithm agility (mentioned) and scheme agility. ** Section 2.0. When multiple ZONEMD RRs are present, each must specify a unique Scheme and Hash Algorithm tuple Would a normative MUST be more appropriate here? ** Section 4. The numbered list calls zones “provably insecure” and “provable secure”. What is the precise definition of those terms. Unless there were formal methods involved, I’d recommend against using those words. ** Section 4. If multiple ZONEMD RRs are present in the zone, e.g., during an algorithm rollover, a match using any one of the recipient's supported Schemes and Hash Algorithms is sufficient to verify the zone. It would likely be worth mentioning in Section 6 that when multiple algorithms are used, the overall security rests with the weakest one. ** Section 5.2 and 5.3 Shouldn’t there be a request for a sub-registry, not a web page? For Section 5.2: OLD IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: NEW IANA is requested to create a new sub-registry in the "Domain Name System (DNS) Parameters" registry as follows: ** Section 5.2. It would likely be helpful to clarify the purpose of the fields (e.g., it wasn’t obvious to me initially that “Implementation Requirement” means MTI) |
2020-10-05
|
12 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-10-05
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-10-02
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-10-01
|
12 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Donald Eastlake. Submission of review completed at an earlier date. |
2020-09-29
|
12 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-12.txt |
2020-09-29
|
12 | (System) | New version approved |
2020-09-29
|
12 | (System) | Request for posting confirmation emailed to previous authors: Warren Kumari , Wes Hardaker , Piet Barber , Duane Wessels , Matt Weinberg |
2020-09-29
|
12 | Duane Wessels | Uploaded new revision |
2020-09-28
|
11 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-09-27
|
12 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Donald Eastlake. |
2020-09-25
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-09-25
|
11 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-11.txt |
2020-09-25
|
11 | (System) | New version approved |
2020-09-25
|
11 | (System) | Request for posting confirmation emailed to previous authors: Duane Wessels , Wes Hardaker , Warren Kumari , Piet Barber , Matt Weinberg |
2020-09-25
|
11 | Duane Wessels | Uploaded new revision |
2020-09-24
|
10 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Donald Eastlake |
2020-09-24
|
10 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Donald Eastlake |
2020-09-23
|
10 | Warren Kumari | [Ballot comment] 'm a'norther |
2020-09-23
|
10 | Warren Kumari | [Ballot Position Update] New position, Recuse, has been recorded for Warren Kumari |
2020-09-23
|
10 | Bernie Volz | Request for Telechat review by INTDIR is assigned to David Lamparter |
2020-09-23
|
10 | Bernie Volz | Request for Telechat review by INTDIR is assigned to David Lamparter |
2020-09-22
|
10 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-09-21
|
10 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-09-21
|
10 | Cindy Morgan | Placed on agenda for telechat - 2020-10-08 |
2020-09-21
|
10 | Barry Leiba | Ballot has been issued |
2020-09-21
|
10 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2020-09-21
|
10 | Barry Leiba | Created "Approve" ballot |
2020-09-21
|
10 | Barry Leiba | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2020-09-21
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-09-21
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-09-21
|
10 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-10.txt |
2020-09-21
|
10 | (System) | New version approved |
2020-09-21
|
10 | (System) | Request for posting confirmation emailed to previous authors: Matt Weinberg , Piet Barber , Wes Hardaker , Warren Kumari , Duane Wessels |
2020-09-21
|
10 | Duane Wessels | Uploaded new revision |
2020-09-17
|
09 | Barry Leiba | Duane is addressing Donald's SecDir review. |
2020-09-17
|
09 | Barry Leiba | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2020-09-17
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake. |
2020-09-14
|
09 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2020-09-14
|
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2020-09-12
|
09 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Review has been revised by Elwyn Davies. |
2020-09-12
|
09 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Review has been revised by Elwyn Davies. |
2020-09-12
|
09 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list. |
2020-09-11
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-09-11
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-dns-zone-digest-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dnsop-dns-zone-digest-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at: https://www.iana.org/assignments/dns-parameters/ the early registration for RR type ZONEMD, decimal 63 will have its reference changed to [ RFC-to-be ]. Second, a new registry is to be created called the ZONEMD Scheme registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The new registry will be managed through Specification Required as defined by RFC8126. There are initial registrations in the new registry as follows: +---------+--------------------+----------+-----------+---------------+ | Value | Description | Mnemonic | Status | Reference | +---------+--------------------+----------+-----------+---------------+ | 0 | Reserved | RESERVED | N/A | N/A | | 1 | Simple ZONEMD | SIMPLE | Mandatory | [ RFC-to-be ] | | | collation | | | | | 240-254 | Private Use | N/A | N/A | | +---------+--------------------+----------+-----------+---------------+ Third, a new registry is to be created called the ZONEMD Hash Algorithm registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The new registry will be managed through Specification Required as defined by RFC8126. There are initial registrations in the new registry as follows: +---------+----------------------+----------+-----------+-----------+ | Value | Description | Mnemonic | Status | Reference | +---------+----------------------+----------+-----------+-----------+ | 0 | Reserved | RESERVED | | | | 1 | The SHA-384 hash algorithm | SHA384 | Mandatory | [RFC6234] | | 240-254 | Private Use | | | | +---------+----------------------+----------+-----------+-----------+ The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-09-03
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2020-09-03
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2020-09-03
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2020-09-03
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2020-09-03
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2020-09-03
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2020-08-31
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-08-31
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-09-14): From: The IESG To: IETF-Announce CC: barryleiba@gmail.com, dnsop@ietf.org, tjw.ietf@gmail.com, Tim Wicinski , … The following Last Call announcement was sent out (ends 2020-09-14): From: The IESG To: IETF-Announce CC: barryleiba@gmail.com, dnsop@ietf.org, tjw.ietf@gmail.com, Tim Wicinski , draft-ietf-dnsop-dns-zone-digest@ietf.org, dnsop-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Message Digest for DNS Zones) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Message Digest for DNS Zones' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-09-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a protocol and new DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the 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 protects individual RRSets (DNS data with fine granularity), ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. 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 is designed so that new digest schemes may be developed in the future to support large, dynamic zones. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ No IPR declarations have been submitted directly on this I-D. |
2020-08-31
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-08-31
|
09 | Cindy Morgan | Last call announcement was generated |
2020-08-29
|
09 | Barry Leiba | Last call was requested |
2020-08-29
|
09 | Barry Leiba | Last call announcement was generated |
2020-08-29
|
09 | Barry Leiba | Ballot approval text was generated |
2020-08-29
|
09 | Barry Leiba | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-08-28
|
09 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-09.txt |
2020-08-28
|
09 | (System) | New version approved |
2020-08-28
|
09 | (System) | Request for posting confirmation emailed to previous authors: Warren Kumari , Matt Weinberg , Duane Wessels , Wes Hardaker , Piet Barber |
2020-08-28
|
09 | Duane Wessels | Uploaded new revision |
2020-07-24
|
08 | Barry Leiba | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2020-07-24
|
08 | Barry Leiba | 1) RFC type is Proposed Standard, and this will be discussed further down. 2) Technical Summary: This document describes a protocol and new DNS … 1) RFC type is Proposed Standard, and this will be discussed further down. 2) Technical Summary: This document describes a protocol and new DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the 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. Working Group Summary: There were several discussions during the working group process, but they were all resolved. The only other point raised was with the intended document status (currently Standards Track). Please see comments in Section 6 Document Quality: There has been implementations of the DNS record in several public domain DNS servers. However, because of the narrow use for this resource record, the shepherd does not feel that vendors will see the need to implement. More than one managed DNS vendor has indicated they see no need to implement. Document Shepherd: Tim Wicinski Responsible Area Director: Barry Leiba (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) The only concern the document shepherd has is of the intended RFC status. While this draft creates a new RRType, the use case appears to be quite narrow, primarily for TLDs. Because of this, there doesn't appear to be any interest with Managed DNS Vendors from supporting this RRType. Because of this narrow scope, the shepherd felt the status of Informational was more appropriate. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is very good, the authors ma (10) There has been no appeals. (11) All nits found have been addressed by the authors. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This RFC will not change any existing RFCs. (17)The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) There are two IANA registries created: 1) ZONEMD Scheme Registry 2) ZONEMD Hash Algorithm Registry Additions to both registries adopt the IANA policy of Specification Required, per RFC8216. There should be no requirement for expert reviews. (19) N/A (20) No Yang Necessary |
2020-07-24
|
08 | Barry Leiba | Ballot writeup was changed |
2020-07-24
|
08 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2020-07-01
|
08 | Tim Wicinski | 1) RFC type is Proposed Standard, and this will be discussed further down. 2) Technical Summary: DNS Resource Record that can be used … 1) RFC type is Proposed Standard, and this will be discussed further down. 2) Technical Summary: DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the 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. Working Group Summary: There were several discussions during the working group process, but they were all resolved. The only other point raised was with the intended document status (currently Standards Track). Please see comments in Section 6 Document Quality: There has been implementations of the DNS record in several public domain DNS servers. However, because of the narrow use for this resource record, the shepherd does not feel that vendors will see the need to implement. More than one managed DNS vendor has indicated they see no need to implement. Document Shepherd: Tim Wicinski Responsible Area Director: Barry Leiba (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) The only concern the document shepherd has is of the intended RFC status. While this draft creates a new RRType, the use case appears to be quite narrow, primarily for TLDs. Because of this, there doesn't appear to be any interest with Managed DNS Vendors from supporting this RRType. Because of this narrow scope, the shepherd felt the status of Informational was more appropriate. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is very good, the authors ma (10) There has been no appeals. (11) All nits found have been addressed by the authors. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This RFC will not change any existing RFCs. (17)The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) There are two IANA registries created: 1) ZONEMD Scheme Registry 2) ZONEMD Hash Algorithm Registry Additions to both registries adopt the IANA policy of Specification Required, per RFC8216. There should be no requirement for expert reviews. (19) N/A (20) No Yang Necessary |
2020-07-01
|
08 | Tim Wicinski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-07-01
|
08 | Tim Wicinski | IESG state changed to Publication Requested from I-D Exists |
2020-07-01
|
08 | Tim Wicinski | IESG process started in state Publication Requested |
2020-07-01
|
08 | Tim Wicinski | 1) RFC type is Proposed Standard, and this will be discussed further down. 2) Technical Summary: DNS Resource Record that can be used … 1) RFC type is Proposed Standard, and this will be discussed further down. 2) Technical Summary: DNS Resource Record that can be used to provide a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the 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. Working Group Summary: There were several discussions during the working group process, but they were all resolved. The only other point raised was with the intended document status (currently Standards Track). Please see comments in Section 6 Document Quality: There has been implementations of the DNS record in several public domain DNS servers. However, because of the narrow use for this resource record, the shepherd does not feel that vendors will see the need to implement. More than one managed DNS vendor has indicated they see no need to implement. Document Shepherd: Tim Wicinski Responsible Area Director: Barry Leiba (3) The Document Shepherd did a detailed review of the document for content as well as simple editorial checks (spelling/grammar). The shepherd feels the document is ready for publication. (4) The Document Shepherd has no concerns on the depth or breadth of the reviews. (5) There is no need for broader review. (6) The only concern the document shepherd has is of the intended RFC status. While this draft creates a new RRType, the use case appears to be quite narrow, primarily for TLDs. Because of this, there doesn't appear to be any interest with Managed DNS Vendors from supporting this RRType. Because of this narrow scope, the shepherd felt the status of Informational was more appropriate. (7) No IPR disclosures (8) There is no IPR (9) The WG Consensus on this document is very good, the authors ma (10) There has been no appeals. (11) All nits found have been addressed by the authors. (12) No formal review needed (13) All references have been identified as normative or informative. (14) All normative references are in a clear state. (15) There are no downward normative references (16) This RFC will not change any existing RFCs. (17)The document shepherd confirmed the consistency and references of the IANA Considerations section are accurate. (18) There are two IANA registries created: 1) ZONEMD Scheme Registry 2) ZONEMD Hash Algorithm Registry Additions to both registries adopt the IANA policy of Specification Required, per RFC8216. There should be no requirement for expert reviews. (19) N/A (20) No Yang Necessary |
2020-06-12
|
08 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-08.txt |
2020-06-12
|
08 | (System) | New version approved |
2020-06-12
|
08 | (System) | Request for posting confirmation emailed to previous authors: Piet Barber , Duane Wessels , Wes Hardaker , Matt Weinberg , dnsop-chairs@ietf.org, Warren Kumari |
2020-06-12
|
08 | Duane Wessels | Uploaded new revision |
2020-06-05
|
07 | Tim Wicinski | Still an open issue around the RFC Status |
2020-06-05
|
07 | Tim Wicinski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2020-04-28
|
07 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-07.txt |
2020-04-28
|
07 | (System) | New version approved |
2020-04-28
|
07 | (System) | Request for posting confirmation emailed to previous authors: Warren Kumari , Piet Barber , Matt Weinberg , Wes Hardaker , Duane Wessels |
2020-04-28
|
07 | Duane Wessels | Uploaded new revision |
2020-04-08
|
06 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-06.txt |
2020-04-08
|
06 | (System) | New version approved |
2020-04-08
|
06 | (System) | Request for posting confirmation emailed to previous authors: Warren Kumari , Duane Wessels , Piet Barber , Wes Hardaker , Matt Weinberg |
2020-04-08
|
06 | Duane Wessels | Uploaded new revision |
2020-03-09
|
05 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-05.txt |
2020-03-09
|
05 | (System) | New version approved |
2020-03-09
|
05 | (System) | Request for posting confirmation emailed to previous authors: Matt Weinberg , Warren Kumari , Duane Wessels , Wes Hardaker , Piet Barber |
2020-03-09
|
05 | Duane Wessels | Uploaded new revision |
2020-02-28
|
04 | Warren Kumari | Shepherding AD changed to Barry Leiba |
2020-02-24
|
04 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-04.txt |
2020-02-24
|
04 | (System) | New version approved |
2020-02-24
|
04 | (System) | Request for posting confirmation emailed to previous authors: Duane Wessels , Piet Barber , Wes Hardaker , Matt Weinberg , Warren Kumari |
2020-02-24
|
04 | Duane Wessels | Uploaded new revision |
2020-01-04
|
03 | Tim Wicinski | Changed consensus to Yes from Unknown |
2020-01-04
|
03 | Tim Wicinski | Intended Status changed to Proposed Standard from Experimental |
2020-01-04
|
03 | Tim Wicinski | Notification list changed to Tim Wicinski <tjw.ietf@gmail.com> |
2020-01-04
|
03 | Tim Wicinski | Document shepherd changed to Tim Wicinski |
2020-01-04
|
03 | Tim Wicinski | IETF WG state changed to In WG Last Call from WG Document |
2019-12-03
|
03 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-03.txt |
2019-12-03
|
03 | (System) | New version approved |
2019-12-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Piet Barber , Duane Wessels , Wes Hardaker , Warren Kumari , Matt Weinberg |
2019-12-03
|
03 | Duane Wessels | Uploaded new revision |
2019-11-09
|
02 | Tim Wicinski | Added to session: IETF-106: dnsop Tue-1710 |
2019-10-28
|
02 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-02.txt |
2019-10-28
|
02 | (System) | New version approved |
2019-10-28
|
02 | (System) | Request for posting confirmation emailed to previous authors: Piet Barber , Duane Wessels , Wes Hardaker , Warren Kumari , Matt Weinberg |
2019-10-28
|
02 | Duane Wessels | Uploaded new revision |
2019-09-05
|
01 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-01.txt |
2019-09-05
|
01 | (System) | New version approved |
2019-09-05
|
01 | (System) | Request for posting confirmation emailed to previous authors: Piet Barber , Duane Wessels , Wes Hardaker , Warren Kumari , Matt Weinberg |
2019-09-05
|
01 | Duane Wessels | Uploaded new revision |
2019-06-24
|
00 | Benno Overeinder | Intended Status changed to Experimental from None |
2019-06-24
|
00 | Benno Overeinder | This document now replaces draft-wessels-dns-zone-digest instead of None |
2019-06-24
|
00 | Duane Wessels | New version available: draft-ietf-dnsop-dns-zone-digest-00.txt |
2019-06-24
|
00 | (System) | WG -00 approved |
2019-06-23
|
00 | Duane Wessels | Set submitter to "Duane Wessels ", replaces to (none) and sent approval email to group chairs: dnsop-chairs@ietf.org |
2019-06-23
|
00 | Duane Wessels | Uploaded new revision |