Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

"Wessels, Duane" <dwessels@verisign.com> Fri, 09 October 2020 18: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 5B48B3A117A; Fri, 9 Oct 2020 11:40:05 -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 NMvxhWtOxqXE; Fri, 9 Oct 2020 11:40:04 -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 75DD23A117B; Fri, 9 Oct 2020 11:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9042; q=dns/txt; s=VRSN; t=1602268804; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=jcVy6TIScjucv3arQNlFCyoTIZUpclikZ/LVQQDrZuA=; b=C942eNINVUoRLGoB2KC0qTpdLPLWiVzhHA2NuHIXaBWMP/ctYI3SqA0b SjMN00MXZCp6SIzsOnspwWvDQKBOkMzuWtjd43+LC8tYdZUE6WsZKKBOD kfOuB98QJ1i7QcyXj3G3sq1WMn9Hwclt4Hm//MwlVqgzLuAl9Je3VKteg 2SHME/STvP3FGVM6AwX05RzNHPVvkTZcGL4iIt0sWxh55AHKmSJq/A1rp nKYeHdMR0MlEG86mptEYCdWxu6pQ5QGCx8OanD/X7Zi20JAvwBzY2aHhK mB6GmRaSp2cfhVBypTGTTSV2sFgSsTpGH8UdJiTFeoFpFL60VEU8NKLnp Q==;
IronPort-SDR: Oh2zioMexvEXyP7ufCteu/A+kGamaI6I0DObVIv2OiR8aALxw9FfAdD+AwTeeRjev7w3Mt72tN MjsD8WOxzeBuzRqIb7VhrI7WzrAm+ly5zz1HH+UjEEfKClIvNlgav6lj1nTMm2alXIMScGO7y4 pwUohtNbd8s9+7x9Tz2fSh2vV3zuyScg4Cmwtm2OjI1nBbUfYFtmX8BZ3rCT+zAVAn9gDlTYR8 U8eKt6iqF13KI4h3eOOczLoGdGtE3CTRkrxIdRuTGcWbxWfVUXYAdsp8LvhYGoGXrKXR6sWquj +fI=
X-IronPort-AV: E=Sophos; i="5.77,355,1596513600"; d="p7s'?scan'208"; a="3210311"
IronPort-PHdr: 9a23:58594BCZ5EFGLHpAIrglUyQJP3N1i/DPJgcQr6AfoPdwSP35rs+wAkXT6L1XgUPTWs2DsrQY0rWQ7vmrCDxIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSizexfLF/IA+2oAnMucUbhYhvIbstxxXUpXdFZ/5Yzn5yK1KJmBb86Maw/Jp9/ClVpvks6c1OX7jkcqohVbBXAygoPG4z5M3wqBnMVhCP6WcGUmUXiRVHHQ7I5wznU5jrsyv6su192DSGPcDzULs5Vyiu47ttRRT1kyoMKSI3/3/LhcxxlKJboQyupxpjw47PfYqZMONycr7Bcd8GQGZMWNtaWS5cDYOmd4YBD/QPM/tEr4fzpFUOoxmxCw6tBOzzxTBFnXD20bE/0+k7EQHKwBIsEtQTu3rUttX1M6ISXPi7wKbI0zrDdOhW1in56IjTahwqvP+CXa9qfsrX10YjGR7Og1KNpo3rITyVzf8NvHaf7+p7Tu+vlXAoqxtwoji0x8cshY/JipgJxVDD8CV02YA4LsC3R0Bne9CrCodQtz2EOItsRMMvW29ltTg6x7MGp5O2fzQHxZokyhPCa/GJc5aF7BztWuiRIDp0mn1rdayiixi9/0as1/HwWMao3VtXsidIkNnCu3QL2hfO6caHUuNw8lq91TqVygze6O9JLVopmafbJZMt2LE9m54LvUjeAiP6glj6ga2Kekk+5+Sl5Ofqbq/7qpKfMYJ/lxvwPb40msOlBOQ1Kg0OX2+G9uuizLDj5kj5QKlSjv0xj6nZrIjWJcQFqa69BA9Yypsu5QqnATu70NsWhXYJI1NZdB6ZlYTpJU3BIPfiDfenmVijiipky+rYPr37GZXNKGLPn6vmfbZ480JcyQwzws5D559MF70NPOj/VlLzudHWFBM1Lgy5zuj9BNhy0o4SQWePDbWYMKPWv1+I/OUvI+yUaYAItjfyNeMl5+Xwgn89gl8QZrep0oUNaHC5BfRmIkqZYXz2jtgdFmcKuxIyTPb2h12aTT5Te3GyUrom5j4mFY2rFpvMSZ63gLydxiu7GYdWZm9eAFCWDXjob5mEW+sLaC+KP8BgnCILVaO6S4A/0RGurxf3xrV7IurK5CIYr5Pj1MN05+3ckxE+7yB7D8OY02yWUm50m3kHRyUq06xloExy1EuD0aZij/xfD9xT6OtDUh0mOp7E0+x6F9fyVxrccdeTUlmmTMmmDSgwTt0v398ObV9xFMikjhDY2CqqG6YZmKGNBJwv667d3n/xJ8BjxHrfyaYhjlYmTdVUNW26naN/9hbcB5LHk0mDkKaqb6sc1jbX9Gif1WqOoF1YUAloXKXZX3AeaFHardXn6UPeQb+jErsnMg5bxs6DLqtGcMHmjVJDRP37ItTRf3qxm3usBRaP3r6DcYzqe34a3CXFE0UEkh4c/WqINQQkASehuW3eBiR0FV3ze0Ps7fV+qHSjQ0ApyQGKdEph16Ks9hEJhfyTUfIT3qgfuCo6qjV7Akq939zMB9qHvQphc71WYckh71dfyWLZqwt9M4ShL698nV4efB96v0Lw2BVrBIVMi88qrGklzFk6FaXN6lREfjXQ8Zn2K7nWNSGm5hyjQ6XbwE2Y18yZrPQh8vM9/h/csRqyG045tz1LztBT3jHUspnVAREJXJbqelg67Rlhpr7cJCI64tWHhjVXLaCov2qaiJoSD+w/x0PlJo8HPQ==
X-IPAS-Result: A2EcAAAdroBf/zGZrQpgHAEBAQEBAQcBARIBAQQEAQFAgTsHAQELAYNFgQgKjFWIeIN6li+BfQQHAQEBAQEBAQEBBAQBLwQBAYRKAoIVJjQJDgIDAQELAQEBBQEBAQEBBgMBAQEChlGCNykBg2oBAQEBAgF5BQsCAQgOCiMLAjAlAgQOBQ6DGAGCXBGoZ3SBNIpfEIE4AYFSi32BQj6BESccgk0+hCUXg0uCLQSQUYIzAaRVAweCaIRLgl+TQB+DE49JjlqvXYNgAgQCBAUCFYFUghJwFTsqAYI+PhIXAg2OVo4QdDcCBgoBAQMJjTeBEQEB
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; Fri, 9 Oct 2020 14:40:01 -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; Fri, 9 Oct 2020 14:40:01 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Roman Danyliw <rdd@cert.org>
CC: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>, "draft-ietf-dnsop-dns-zone-digest@ietf.org" <draft-ietf-dnsop-dns-zone-digest@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: [EXTERNAL] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
Thread-Index: AQHWnOu+bwH+/pTMmUuTtu3k6kBafqmP4GYA
Date: Fri, 09 Oct 2020 18:40:01 +0000
Message-ID: <51CC3897-1A88-41F7-A56C-0BB4E69EBBC9@verisign.com>
References: <160195246471.4620.11112787341926255318@ietfa.amsl.com> <514C2BA5-37C3-48E5-B1FE-DCA96C7F37B3@verisign.com> <5fbeea49742e4866878af08d9681c8fe@cert.org>
In-Reply-To: <5fbeea49742e4866878af08d9681c8fe@cert.org>
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=_ADCF0114-820B-4E1F-AD13-D9359C56106C"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/N_GGiTxMGWbJV4wq16dtypt9qUs>
Subject: Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)
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: Fri, 09 Oct 2020 18:40:05 -0000


> On Oct 7, 2020, at 1:52 PM, Roman Danyliw <rdd@cert.org> wrote:
> 
> 
> In that case (where no assumptions are made about the transport), it seems that only these scenarios from the list above apply:
> 
> With an on-path attacker (and trusted server hosting the zone file)
> 
> ** No DNSSEC  = integrity: NO; 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 = integrity: NO; authenticity = NO
> ** DNSSEC = integrity: YES; authenticity = YES
> 
> Or more succinctly, without DNSSEC, the two stated security properties aren't provided.  
> 
> I'm not sure of what the best way is to resolve this mismatch based on the use cases.  I can see (at least) two paths to resolution:
> 
> (1) Specify that ZONEMD records MUST only be used with DNSSEC -- this will preserve the authenticity and integrity properties described in Section 1.1. and 6.  An additional step or two might be needed to the verification process in Section 4.  Does this impact the planned use cases or workflows?
> 
> (2) Provide appropriate caveats that ZONEMD information may not mean what you think it means depending on whether DNSSEC is used.  This likely means: the motivational goal in Section 1.1 may need to be weakened; the analysis of alternatives in Section 1.2 won't make sense (for the non-DNSSEC case); and an appropriate applicability-like statement might also be necessary to describe how to use an insecure checksum.  Section 6 would needs additional language to capture the difference between the DNSSEC vs. non-DNSSEC deployment.  Editorially, clearer words like checksum might also help.

Thanks Roman, I see your point.  With the help of my coauthors we have made some edits that I think will address your concerns. 
Rather than try to include them all here, it will probably be easier to read the diff of the next revision that we hope to
submit later today.  Alternatively I can give you a github pull request link showing the changes if that would be helpful.

DW