Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

"Wessels, Duane" <dwessels@verisign.com> Tue, 19 June 2018 18:56 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 CFFEF130DED for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 11:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XznEqBozzy3f for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 11:56:45 -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 60C6D1294D0 for <dnsop@ietf.org>; Tue, 19 Jun 2018 11:56:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9867; q=dns/txt; s=VRSN; t=1529434605; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=uCw13cCh6ZlYAl4lLwaR5gDtscbsdD45JyiuXc6OZNo=; b=Jiiz71vuoJ1mPet+f2/0KqyXFrCP9sR99ZTFlA5cH6i8kRaCktQh13Wz P0vRrel3gJrxx5WKGU/CnfRCdq9mnB+wtciq3gX1CrxXXJZV8+n/uRqfJ ABm42xEpkZR3LFt+eR/d2wjc0ZOio3N9aaPWXBP63zt9PxQDF1d/wjLgv +8YQfyNdGbAiNAQa1S9NFvH4Zsdu030onRhEKAW5nua8cif8ssI6sGs2l WzXXVW8mBrTf78LWv3F8ZTATdPqVtG+g1v9GURd57BoFAu6Bu+32uD3qM tDxqm20+2CfAp8ZU84Et6w/zQxVT0zFnpGQuQ5yOZ2uQiTybr0mDvFvcv w==;
X-IronPort-AV: E=Sophos; i="5.51,244,1526356800"; d="p7s'?scan'208"; a="5019586"
IronPort-PHdr: =?us-ascii?q?9a23=3AU2jfHxRTbisoYN1kPy+u1FdU5tpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67ZBSOt8tkgFKBZ4jH8fUM07OQ7/i9HzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjWwba9yIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAo2y?= =?us-ascii?q?cZYBD/YPM+hboYnypVoOogexCgS3C+Pj1jpIi2Xq0aEm0eksFxzN0gw6H9IJtX?= =?us-ascii?q?TZtNv5O6cMXuCu16nH0zHDb+hO1Tzg5obIbwouofeSUr5+bMHczlQgFg3bgVWL?= =?us-ascii?q?sozqITeV1v8WvmiF8eVgT+Ovi3UmqwF+pDij3Nsjio7Mho8MzF3P6Ct3wIEwJd?= =?us-ascii?q?KiSU57Z8apEJpWtyGGKYR2WMUiQ2B0tyogzL0Jp4K7cS4Xw5ok3x7Sc+GLf5SS?= =?us-ascii?q?7h7+VuucLy10iG9ldb+xnRq//kytxvXhWsWoylpGsyhInsXWunwQ2BHe6dKLRu?= =?us-ascii?q?Z+80u51zaAyQPe5v1BLE0xj6XWKJoszaU1m5cdr0jMAy77lUDtg6KSd0gp+O2l?= =?us-ascii?q?5urpb7jku5CRMZJ/hBvkPaQ0gMO/BPw1Mg0JX2eG5+uxzKbj/UjlQLVSif02j7?= =?us-ascii?q?XZvIjaJcsFoq65BBdY35s/5RinEjup0MwWk3YGI15ZZh6LlZbpNE3JIPDiFfez?= =?us-ascii?q?mU6jnypxy/DYJL3hGZPNImLfn7fmeLZx809cyAwtwtBD/59YF60NLOjuVkLzut?= =?us-ascii?q?HUFAI1Pgy6zur9B9hw0psSWWeVDa+YNKPSv0WI5uUqI+SUeYAUtijyK+M+5/Hw?= =?us-ascii?q?iX85gkQQfbe30psNaXC4BfVmI0qfYXb2ntgBFmIKshIkTOP2kF2CTSJTZ3GqUq?= =?us-ascii?q?In5jE7FZumDZrdSY22j7yB2T20HpxSZmxcFl+MFnLofZ2eW/gQcCKSPtNhkjsc?= =?us-ascii?q?WLi5VYAhyQuuuBXhy7p/NOXb5jMXtZH42dhz5u3ciQs++iB1Ds6FyWGCU3l0nn?= =?us-ascii?q?8URz8xxK1wvEp9ykyE0ahgmPFYFMJc5+9HUgsgMp7c1eN6WJjOXVf6fsqMT1Du?= =?us-ascii?q?Ysi/HDx5Gskx3sYTbm5yHtyjilbI2C/8UJEPkLneTqM56bnR22O1b+pgwnDLnu?= =?us-ascii?q?F1g0YrWdBCMXaOmKNl9hPSCIiPmEKcwfX5PZ8A1TLAoT/QhVGFu1tVBUspCf3I?=
X-IPAS-Result: =?us-ascii?q?A2FnAQDiUClb/zGZrQpdGQEBAQEBAQEBAQEBAQcBAQEBAYQ?= =?us-ascii?q?rgScKg2+WNSGIIo5RCAMbE4ECR4J1AoMQOBQBAgEBAQEBAQIBAQKBBQyCNSQBD?= =?us-ascii?q?ktbAQEBAQEBASMCDSY9AQEBAQIBI1QCBQsCAQgOCioCAgIfESUCBAoEBQ4Ngwo?= =?us-ascii?q?BgWcDDawmghyHDQ2BLF4Piik+gQ8kDIJcglGCDlSCQzGCJAKYcywDBgKDUYFYU?= =?us-ascii?q?oYJhEhBiz2HcoJwg28BgloCBAIEBQIUgViBdHAVZQGCGAmCGRYRiA2FM0Zviza?= =?us-ascii?q?BGgEB?=
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.1466.3; Tue, 19 Jun 2018 14:56:43 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1466.003; Tue, 19 Jun 2018 14:56:43 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Shumon Huque <shuque@gmail.com>
CC: "petr.spacek@nic.cz" <petr.spacek@nic.cz>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
Thread-Index: AQHT+ZaLNg8WxOT4q0yAjDmobvSEj6RoBGuAgAA9OQCAAAzCAA==
Date: Tue, 19 Jun 2018 18:56:43 +0000
Message-ID: <688A6AE8-7990-4E76-BD56-5AFE27467A7D@verisign.com>
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <CAJE_bqcELQbQeHPvvEBHOxpRyWYL76BmT_-G4jW4pTnUUXFMUw@mail.gmail.com> <27C44216-581A-4991-A739-ECE8B7F8AA35@verisign.com> <884c2d11-9db0-7668-59c9-baa8574a03f7@time-travellers.org> <37873808-8354-b26b-34f4-880ea7a5f0da@nic.cz> <CAHPuVdWXBDHdiQ2Z1uFx=mZFRBpjndiki+6Eno-2qFoe6hAovw@mail.gmail.com>
In-Reply-To: <CAHPuVdWXBDHdiQ2Z1uFx=mZFRBpjndiki+6Eno-2qFoe6hAovw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_315C92A6-C49C-4375-AEE3-41027F9F1D07"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/C-xmdEqtN4h_8Cc2PVRigwW1Q54>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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, 19 Jun 2018 18:56:49 -0000

> On Jun 19, 2018, at 11:11 AM, Shumon Huque <shuque@gmail.com> wrote:
> 
> 
> On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček <petr.spacek@nic.cz> wrote:
> 
> I think we need to first answer question why existing technologies do 
> not fit the purpose.
> 
> This is a reasonable question.
> 
> I noticed that the draft doesn't mention SIG(0) at all.

I suppose this is happened because, as you say it isn't widely implemented or used.

> One of the main motivators of the draft is stated to be secure, wide scale distribution of the root zone. To me, SIG(0) would have been an obvious candidate solution for this problem. The zone owner can publish one public key to the world,

My reading of RFC 2931 contradicts this.  For example:

2.3 Keying

   The private keys used in transaction security belong to the host
   composing the DNS response message, not to the zone involved.
   
In other words, SIG(0), like TSIG, is about asserting the security of an individual transaction from a particular server, not the contents of zone data.

Also:

   The corresponding public key(s) are normally stored in and retrieved
   from the DNS for verification as KEY RRs ...  Thus it will be necessary
   to keep the private key on-line, for example in software or in a directly
   connected piece of hardware.

It doesn't make sense to me to consider using KEY RRs and online private keys when we already have working DNSSEC infrastructure.

> and signs zone transfers messages with the corresponding secret key. If the zone owner supports IXFR, the incremental cost of these message signatures is also quite small.
> 
> Possible issues with SIG(0):
> 
> * Although it is an existing technology, it isn't widely implemented or used. I just learned on DNS twitter that BIND only supports SIG(0) for UPDATE for example, and not XFR.
> 
> * If the goal is to support secure acquisition of the zone outside the DNS protocol, then it can't do that. But neither is ZONEMD needed for that - we can use an out of band signature using a variety of methods.

Yes, this is the crux of it for me and the other authors as well I believe.  In my opinion, detached signatures/checksums are not good enough.  Our not-yet-released -02 draft has this new text:

1.1.2.  Detached Signatures

   Sometimes, detached checksums and signatures can be found adjacent to
   zone files.  This is the case for the root and other zone files
   published on the internic.net sites [InterNIC].  For example, the
   files root.zone.md5 and root.zone.sig are in the same directory as
   the root.zone file.  Unfortunately, since the checksum and signature
   are in separate files, they are only weakly associated with the zone
   file.  They remain associated only if the recipient is careful to
   keep them together.  Nothing in these files, other than their names
   and timestamps, ties them to a specific revision of the root.zone
   file.

DW