IETF Logo Mail Archive

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

"Wessels, Duane" <dwessels@verisign.com> Mon, 14 September 2020 22:40 UTC

Return-Path: <dwessels@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5700D3A0B84; Mon, 14 Sep 2020 15:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecr1_CT7gvvu; Mon, 14 Sep 2020 15:40:21 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8FB3A09AF; Mon, 14 Sep 2020 15:40:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9119; q=dns/txt; s=VRSN; t=1600123221; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=lOa4QCNYPg3ef3Jd9gtenah6M1ApHX/z2+esT2w6SJ8=; b=KfY+wfc/bKJtockpe6Ohg0yUJPJlxPeLYbPhBmEYicfNaEhZ7BNKrI+W dx73nFCCdnvjyw9N1HBRzPIx1ndcDEl75VsNumkD4O53x+JYqiOqU/pg2 iibhK1qsLo7z2x4L6BXOlq1kWkip7drhTmiuXqML12hqstS6fIJtXAH6G dd94mLrJuqMiDegrMq+cTs4FQsu1NsLvrTbP1LuS+SSVXVwJgfTBaTsmU kw1F4FsdxYyutMBRZk/HUgblhsY/IjgVolq/SaF98FBXzXI0uZvumfwyf NLcEJOS5wpZBD34Hy36z7D/trEOjNAlEvRjPoWnh70I9F2d4Df8YFAQ9i A==;
IronPort-SDR: RkGJfnk8uhf6kkGnMBEZMq9R/fD8t1ysIHU85/Oea9QirAAO3PSn2+7Sph09qhWJcm3++zEM/b 1661bJHd5hfrZoAXBg2tKZHmBLfrD4kZS26xhQMQ8QYO3OiM+rFaPpot5thOWq46LONSHAawIs +KkpWdzwxzF36v1Dsj2joH4uM9tD7CecHOoSXNJhzX/qVPOz9MxX/iU3Ur8MgHi7LHuLp2XjJp tfUb+9TJRUuW8XB3GV1PBfvZNFE5RVONcFVkenqlH6wdXLXCZLzSFRfKHidRGmDowTq5mL81Vs Gtc=
X-IronPort-AV: E=Sophos; i="5.76,427,1592884800"; d="p7s'?scan'208"; a="2819405"
IronPort-PHdr: 9a23:PoeXKRbFj78dVlXHjqdfMun/LSx+4OfEezUN459isYplN5qZps25ZR7h7PlgxGXEQZ/co6odzbaP7ea5BzNLucnJmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRS7oR/MusQXg4ZuJbo9xxnUqXZUZupawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2866tHluhnFVguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXDmp8qlmRAP0hCoBKjU063/chNBug61HoRKhvx1/zJDSYIGJL/p1Y6fRccoHSWZdQspdUipMCZ6+YYQSFeoMJeZWoZfgqVsSoxWwBgesC+HoxD9JmnD50rY30+s9HQHDxgEgH84CvGrSod7oNKkSS+e1zKzQwDnNb/xZxyz96JPWfRAluvGARa97f8TMyUY1EQPKkFucopHiMjyI2OUCrXOb7/F+WuKrkG4qsB9xrSa1xsctkYnJh40Vylbe+Splx4Y1IMS1RUhmatGrDJVerTuVN5dqQsw8WWFovj43x6MGtJOnfiUHyZYqyRDcZvGGboSG7RztWuiTLDp6gH9oeLyxihKx/EWi1ODxVMm63lZUoydZktfBsn4D2hLQ58WBV/Bz8ECh2TOV2ADS7OFJOVw7lavAK5E9xb48jIYcsUPGHiPumUX5krOWdks+9uiv8eTnbbPrrYKfOY9skgzyL7giltaiDek6PAUCRXWX9OSy2bH58kD0RK1GguAqnqXDrZzXJ9gXqrSkDwJa0Ysv8QuzAjSg3d8Fh3cINkhFdwiCj4XxPlHOJ+33AumnjlS3lTdr2+jGPrr8ApXRNnTDkKnufbJ660NE1Qc90chR649UBb8ZL/z8W1P9uMLCAh8nLwO0xPznCM1n2owERG2DGLGZMLnJsV+O/O4gP+6MZIoNtDb8Lfgq+eLugGcklVMBZ6WlwJkaZX6iEvh7I0iUb2Dgj9gFHGsSuwoxVu3qiFmMUT5JYHayWrox6Sw1CY24FofDXZ6igLia3CqgAJ1ZeHpGClGXEXfpeIWEXe0AZz6VIs9kijAET6SuS5c91RGysw/306FoLu3O+i0EtJPj0cZ65u3NmhEo7jF0CcWd3H2XQ2F6hGMCXyU207xnoUxh1leD1rB1gvJCGtxJ/fNGTAE6OIXfz+xnDtD9QBjBftaTRFagXNqmHSk7TsgtzN8Wf0Z9B9Kigwje0CqsGL8VkKSLCYc18q3Cw3jxKdxxy3Hc1Kkul1MmWNdANXW6hq5j8AjeH4rJnF+Cl6a2bKgTwDTC9GOHzWeVvUFXThJwUavfUXAYfEvWooex2kSXdKOjEbQuNAYJ48mYNrlPZ8zklx0STvD5JMbbbnO8gU+2BB3OyKnaP6TwfGBIlhrQE1MJlxtXtVqbPA4zTG/1r33TFydjEUnHfU728PJ/p3X9RUgxmVLZJ3Z93qa4r0ZGzceXTOkei/dd4H8s
X-IPAS-Result: A2E5AAAO8V9f/zGZrQpgGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgU+DGiyBCAqVQSaDepgjBAcBAQEBAQEBAQEEBAEvBAEBhEsCgiolOBMCAwEBCwEBAQUBAQEBAQYDAQEBAoZRgjcpAYNqAQEBAQIBeQULAgEIGCMLAjAlAgQOBQ6DGAGCXBG2LXSBNIpcCgaBOIFTi3SBQj6BOAwQghg1PoQUEReDS4ItBI92ikOCfJhJgQgDB4JlhECCX5MhHoMJjyyON65og1kCBAIEBQIVgWuBe3AVGksBgj4+EhcCDY4rFxSOEHQ3AgYKAQEDCY4KAi2BBjJfAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 14 Sep 2020 18:39:44 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.1979.003; Mon, 14 Sep 2020 18:39:44 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
CC: Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] Last Call: <draft-ietf-dnsop-dns-zone-digest-09.txt> (Message Digest for DNS Zones) to Proposed Standard
Thread-Index: AQHWiufxN2MZaOxKFUe9zPVnJp+m9w==
Date: Mon, 14 Sep 2020 22:39:44 +0000
Message-ID: <C13667A4-8367-4A33-9C27-7790192F327B@verisign.com>
References: <159888994126.9753.15824019164711415199@ietfa.amsl.com> <20200910183035.GA6937@sources.org> <CAHw9_iJNPAyZFt2orSHvzT5gUPFRhsWvzQ=nT6-nrWfcjs84hQ@mail.gmail.com> <20200911084508.GA23823@nic.fr>
In-Reply-To: <20200911084508.GA23823@nic.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.15)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_742ADE8D-1671-40ED-8F34-94CBD423223E"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_G334NYTzX8PTie5ElK49H7vkQE>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-dns-zone-digest-09.txt> (Message Digest for DNS Zones) to Proposed Standard
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 22:40:22 -0000


> On Sep 11, 2020, at 1:45 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
> On Thu, Sep 10, 2020 at 03:03:45PM -0400,
> Warren Kumari <warren@kumari.net> 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>

v2.23.0 | Report a Bug | By Email