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

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 10 Sep 2020 20:30:35 +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

This is not really part of the Last Call (I have no problem with the
document in its current form), it's more about two "philosophical"
questions I have about zone digests.

One is small: the draft claims "a name server loading saved zone data
upon restart cannot guarantee that the on-disk data has not been
modified". This argument seems weak. Can we really imagine attacks
where the attacker can modify the zone file on the disk, but cannot
modify the verifier, for instance its code, or its trust anchors? 

The other is more complicated. The draft says "Unfortunately, the
protections [TLS, SSH, etc] provided by these channel security
techniques are (in practice) ephemeral and are not retained after the
data transfer is complete. [they] not provide any methods to verify
data that is read after transmission is complete." In the DNSSEC cas,
zone digest provide such a method but only for a time. Once the keys
are rolled over, the verification is no longer possible. Since most
(all?) DNSSEC tools assume they can delete a key once the RRSIG which
use it have been removed from all caches, you can have a zone file
whose signatures are still valid (not expired) but the DS and/or keys
are no longer available online. Unless I'm wrong, this limit is not
mentioned. (Not sure it is important in practice, as I said, it is
more a philosophical question.)

---

From: Warren Kumari <[email-masked]>
Date: Thu, 10 Sep 2020 15:03:45 -0400

> modify the verifier, for instance its code, or its trust anchors?

Ah, this wasn't intended to deal with *attacks*, but rather accidental
zone corruption; for example, copying the zone file to an (almost)
full disk, and ending up with a truncated zonefile (this has bitten a
few TLD/ccTLDs), or a transfer dying midway through a copy, etc.

> more a philosophical question.)

Hmmmm. Yes, I suspect that you are right, and that this isn't
mentioned. Do you have any suggested text? If so, could you send it to
the IETF LC so it gets captured?

W

>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

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

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://mailarchive.ietf.org/arch/msg/last-call/7sl2rC8ql9Faj4aKVfOJSiT79n4>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Sep 2020 12:43:46 -0400

Thank you.
W

---

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:
> 
> <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>