Re: [DNSOP] zone contents digest and DNSSEC stuff

"Wessels, Duane" <dwessels@verisign.com> Tue, 29 September 2020 17:16 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 0A6AC3A0F25 for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2020 10:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 7Dj5qdpgZmlB for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2020 10:16:41 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 3C1003A0F24 for <dnsop@ietf.org>; Tue, 29 Sep 2020 10:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9093; q=dns/txt; s=VRSN; t=1601399802; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=6F+NXuF4CngYmi29yruB2tXW4esIwW4xegI5fR+0VYQ=; b=Mi+wPVB+enMZzn2r5Ckk7ggkc4JIVwpNVDT+XAJZq0v47blDtYT4ZrfR m59hdTBa/QYesr4k+GkFTB0ewVMCyFU+t66OspILBQbXe275HrpRYHzih I2YMgUHmrDrWbCQtqOYJya5+b9EvvDCTZRxZFOi4TVC1juGWStL17nNzv 6DFBywqchmUNHKIxZ3Up0uvXENzm09lGwfvm/O83HcWBOAIjtoemiXNb7 pRB0Ee5xnLfUuLiM6LpHCnwFtNPsV3l4hq5/kmfWgSLCNgnzMnLYyqyJF aWWYgxelwTvrpbfA9zdCVsdhFNEXVfaMT8//1RBDgq/k0dr09KY7H54am A==;
IronPort-SDR: atoZawl6lJIOq4uxrDE7RYuF9P2vGZX0dVRnqaFNbZ8w61W2EglQYxuTUf71h0I1tiJRSCRhio oZRehErP7+DSPcRaiiCeQAPTOWjn2fqZ2hKmUeNVsUtxv6mrwXbTXGJkRl054yIjK+bCovoSrN 14cyj6Ye/u0ROMCDpFseH5INvyBrVGjGiAZQ/8UZKgccFxPYXXzJL04gE1TdxaH16M/hqPXdmw DNZRVvvZqldEq5w4dLmt96mkl/akFQJYVeSQpH/F2U14C6/O5ynNrkiTIiQf7dDfTAe4McEYo/ HK8=
X-IronPort-AV: E=Sophos; i="5.77,319,1596513600"; d="p7s'?scan'208"; a="3081671"
IronPort-PHdr: 9a23:ZYJTghbiAvm26G3e95OfjiX/LSx+4OfEezUN459isYplN5qZpsy4Yh7h7PlgxGXEQZ/co6odzbaP7Oa6CSdZucfJmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRe7oR/PusQVjoduN7o9xx/UqXZUZupawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2866tHluhnFVguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXDmp8qlmRAP0hCoBKjU063/chNBug61HoRKhvx1/zJDSYIGJL/p1Y6fRccoHSWZdQspdUipMCZ6+YYQSFeoMJeZWoZfgqVsSoxWwBgesC+HoxD9JmnD50rY30+s9HQHDxgEgH84CvGrSod7oNKkSS+e1zKzQwDnNb/xZxyz96JPWfRAluvGARa97f8TMyUY1EQPKkFucopHiMjyI2OUCrXOb7/F+WuKrkG4qsB9xrSa1xsctkYnJh40Vylbe+Splx4Y1IMS1RUhmatGrDJVerTuVN5dqQsw8WWFovj43x7MYtJO7fCYH1pcqygLRZvGEboWF4hLtWfifLzl2hHxoeayziRms/ES9xePyWNS43EpFoCdZj9TBqnIA2RzX58WBV/Bz/V+h1C6S2wzP8O1IPEI5mKTBJ5I8wrM9mIAfvEvHEyPuhUn6kLWaelgm9+S08ejrf7rrq5yGO4NpiQzzNLkllNalDuQiKAcOWnCW+eG71LL+40L0WK5KjvgqkqnBt5DaONgbqra5AwBL1oYj7A6yAiq63toAgHUILEpLdh2GgIT1JV3COu74Auu4g1S2iDdn3erJMaD7DpXTNHjDi7Hhcaxh5E5bzQo/1dFf55RKBbEdOP//R1P9uMbFAhI7PQG42fvrBdVz248EVm+CBreVMKbIvl+J4uIvLfOMZIgQuDvlNvck6eDhjWQimVADeampxoAaaG6mEfR8IkWZenvsgtgHEWsQogU+S+nqhEWYUTFPf3ayQ7485jYjBYKiDIfMXYetgKab0CejAJJWYnxGBUqKEXrzcYWEWusDZDiOLc5gijYET6SuS5c91RGysw/307hnIfDP9S0cq53i1MN45+3UlREq6TN0CNmd02eRT21ugmwHXSc83Lpjrkxl1leDza94juRFGtxV/PNJVR86OIXdz+NkF9DyVBjNftCTSFapEZ2aBmQ1T9g22ZkWbkJhEtPq2hTC1S2wRacYk6CCArQy86ma1GqndOhnzHOTnpYslEIrRtALfUG7j6hyvUCHC5HEiF6Uk72Ca6kG3TXM+2HFxm2L6hILGDVsWLnICChMLnDdqs70swabF+ej
X-IPAS-Result: A2FFAACtanNf/zGZrQpgHQEBAQEJARIBBQUBQIE8BwELAYNFgQgKlVQmg3qWK4F9BAcBAQEBAQEBAQEEBAEvBAEBgVaCdQKCMSY1CA4CAwEBCwEBAQUBAQEBAQYDAQEBAoZRgjcpAYNqAQEBAQIBeQULAgEIGC4CMCUCBA4FDoMYAYJcEbRndIE0hVOEXxCBOAGBUot2gUI+gTgMEIJNPoQ8g0uCLQS3QgMHgmeESIJfkzMWCYMNngaVAZo5g10CBAIEBQIVgVYBgg9wFWUBgj4+EhcCDZxmdDcCBgoBAQMJjV2BEQEB
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; Tue, 29 Sep 2020 13:16:38 -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; Tue, 29 Sep 2020 13:16:38 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: "libor.peltan" <libor.peltan@nic.cz>
CC: Joe Abley <jabley@hopcount.ca>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] zone contents digest and DNSSEC stuff
Thread-Index: AQHWloRKCCtdyau6YkWZm5Deecnnew==
Date: Tue, 29 Sep 2020 17:16:38 +0000
Message-ID: <E95FA596-D81B-44D0-8407-55286479D5E4@verisign.com>
References: <4553c77e-9333-1002-d06e-e9ad10857290@nic.cz> <72D9D13F-15E2-4E99-84E7-305CDC5923BA@hopcount.ca> <f44f2ead-27b8-2dc1-807d-007e216c278f@nic.cz>
In-Reply-To: <f44f2ead-27b8-2dc1-807d-007e216c278f@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.4)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_993C0DBE-7FDF-4002-B5C5-C0613147CC3F"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Xf7Le6hY9_zoyUyajCukkaLWvnk>
Subject: Re: [DNSOP] zone contents digest and DNSSEC stuff
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: Tue, 29 Sep 2020 17:16:43 -0000


> On Sep 29, 2020, at 6:42 AM, libor.peltan <libor.peltan@nic.cz> wrote:
> 
> Hi Joe,
> 
> Dne 29.09.20 v 15:03 Joe Abley napsal(a):
>> The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate representation of the unsigned zone using the unsigned-zone ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm just not thinking hard enough?
>> 
>> 
>> Joe
> 
> yes, something like this.
> 
> My initial thought was that the signer, which converts the un-signed zone by adding signatures and keys, might not be able to compute/update the ZONEMD record.
> 
> It might also be useful, when the zone is only re-signed and otherwise unchanged, if the zone checksum was unchanged.
> 
> I'm not sure. This is just a thing to be thought of.
> 
> I would love if there was a bit flag indicating if the checksum has been computed including DNSSEC records, or without them. This would let the freedom of choice on the users, while adding some complexity to software implementation.
> 
> Thanks for consideration,
> 
> Libor


Joe's response was very good, especially with respect to signed and unsigned being two different zones. 

During the working group discussions, we often heard the opinion that ZONEMD is not reliable without DNSSEC signatures.  Without a signature on the ZONEMD record, an adversary can easily change the digest to match changes to zone content.  I expect in most cases digest calculation will be done at the same time as zone signing.

There is no flags field, but you could probably accomplish your goal with a new or private use scheme code point.  That is, you could define a collation scheme that excludes DNSSEC RR types during digest calculation.

If there were a proposal to standardize such a scheme, the concern I would have is that it complicates the meaning of zone digest verification.  It would essentially be verifying a subset of the zone, which is not as strong as verifying the full zone.

DW