Subject: Re: [Last-Call] Last Call: <draft-ietf-dnsop-dns-zone-digest-09.txt> (Message Digest for DNS Zones) to Proposed Standard

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 11 Sep 2020 10:42:04 +0200

On Mon, Aug 31, 2020 at 09:05:41AM -0700,
 The IESG <[email-masked]> wrote 
 a message of 51 lines which said:

> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Message Digest for DNS Zones'
>   <draft-ietf-dnsop-dns-zone-digest-09.txt> as Proposed Standard

No objection to the draft but I suggest two add two things, to precise
the applicability of this technique.

1) In 1.1, after "For example, a name server loading saved zone data
upon restart cannot guarantee that the on-disk data has not been
modified.", add "Such modification could be for instance the result of
an accidental corruption of the file, may be because a disk was full
[and add the reference to
<http://web.archive.org/web/20100618032705/https://www.denic.de/en/denic-in-dialogue/news/2733.html>]

2) In 1.1 (or may be in the Security Considerations), after "not
provide any methods to verify data that is read after transmission is
complete.", add "The ability to verify a signed zone after its
transfer is limited in time. If the keys or DS records are no longer
in the public DNS, the verifier cannot check the authenticity of the
ZONEMD record. This can happen even if signatures in the zone are
still current (not expired), keys and DS records may have been
withdrawn following a key rollover. Therefore, verification must be
timely."

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 14 Sep 2020 22:39:44 +0000

> On Sep 11, 2020, at 1:45 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> On Thu, Sep 10, 2020 at 03:03:45PM -0400,
> Warren Kumari <[email-masked]> wrote 
> a message of 62 lines which said:
> 
>> Do you have any suggested text? If so, could you send it to the IETF
>> LC so it gets captured?
> 
> Done
> <https://secure-web.cisco.com/17dROtVCd8LPL7t02N7Td4TOI39uyGsdze_s6JTNPnNaX4tHIhjcs759W3j529_Py472Amqs5SXKLC5Nd_MTcJeR5PVobHvYL8yIVl_ckr9X2yFD-IE29Tg4tnmJxkdIACLzV3v0vuzCtPHg8O4MxXpQckHEIEw3ujqtvpPPWiZjt8fNMrd4dNGfALY0xk_VmBsRyjZM-dSvtuzPx3CdFLkAtORWvdiHaEtedIUgmKxcR5-YnVhgUHNObIK4ixjEcXjeUAZQAhOFPdwASB83d3l_jAVACGhC0tsmMjduyshY/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flast-call%2F7sl2rC8ql9Faj4aKVfOJSiT79n4>

Stephane,

Thank you.  We've added the following to the draft based on your feedback:

           to verify data that is read after transmission is complete.
           For example, a name server loading saved zone data upon restart
           cannot guarantee that the on-disk data has not been modified.
+          Such modification could be the result of
+          an accidental corruption of the file, or perhaps an incompletely
+          saved file <xref target="disk-full-failure"/>.
           For these reasons, it is preferable to secure the data itself.

+      <section title="DNSSESC Timing Considerations">
+        <t>
+          As with all DNSSEC signatures, the ability to perform signature
+          validation of a ZONEMD record is limited in time.
+          If the DS record(s) or trust anchors for the zone to be verified
+          are no longer available, the recipient cannot validate
+          the ZONEMD RRSet.
+          This could happen even if the ZONEMD signature is still current
+          (not expired), since the zone's DS record(s)
+          may have been withdrawn following a KSK rollover.
+        </t>
+        <t>
+          For zones where it may be important to validate a ZONEMD
+          RRset through its entire signature validity period, the zone
+          operator should ensure that KSK rollover timing takes this
+          into consideration.
+        </t>
+      </section>