Skip to main content

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