Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

"Wessels, Duane" <dwessels@verisign.com> Tue, 10 September 2019 23:18 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 6558412006B for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 16:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 oo6zRqOo9v4R for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 16:18:12 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.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 DDED1120013 for <dnsop@ietf.org>; Tue, 10 Sep 2019 16:18:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=11246; q=dns/txt; s=VRSN; t=1568157491; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=Zv1rv4zg/JgGTUxG00jlIfNgq2nsQ+nlaKEfqCeSeCo=; b=BWYh8GDKDwsRT+w5dzbDyzN+3CokpMFhQ70AbC0NreuYfFsnb4b7r122 AafFrE8bopvCzE7vnahsMb5SvlkeblnGzM8voCXqARZdn64aqhwEo6wRV vdJpFxe/A7sqWrmjqM8matG4hR7zdHx6wao5NALqAEOGoCsijVO/jAm0b 121LeDxImrwvqtgYZ1O8hciyXhnj9gPxlkineFo5mvUQ4/UO/yCtcBAfw 6NJUGG6J8zFd7A7U1o0QOVO/YrwnZiFSXlZ9aLYngXLy1DYi5xHg93FG9 /8pF3DH8aL2Cl0QiFzopNoBSkaQ86e9+nPTmwRvj79IxLeqPium+M1JGp Q==;
X-IronPort-AV: E=Sophos; i="5.64,491,1559520000"; d="p7s'?scan'208"; a="8513950"
IronPort-PHdr: =?us-ascii?q?9a23=3AayU6BRG0nF0foYxfGlGcjp1GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ76psy9bnLW6fgltlLVR4KTs6sC17ON9fi5EjVQqdbZ6TZeKcYKD0?= =?us-ascii?q?dEwewt3CUYSPafDkP6KPO4JwcbJ+9lEGFfwnegLEJOE9z/bVCB6le77DoVBw?= =?us-ascii?q?mtfVEtfre9FYHdldm42P6v8JPPfQpImCC9YbRvJxmqsAndrMYbjZZsJ6or1h?= =?us-ascii?q?fFv3REd/lVyGh1IV6fgwvw6t2/8ZJ+7Shcoe4t+9JFXa7nY6k2ULtUASg8PW?= =?us-ascii?q?so/sPrrx7DTQWO5nsYTGoblwdDDhbG4h/nQJr/qzP2ueVh1iaUO832Vq00Vi?= =?us-ascii?q?+576h3Uh/oiTwIOCA//WrKl8F/lqNboBampxxi347ZZZyeOfRicq/Be94RWH?= =?us-ascii?q?FMVdhNWSNfHoy8bpMPD+sfMuZes4n9vEYFoR+nCQWxGO/j1jpEi3nr1qM4zu?= =?us-ascii?q?shCxnL0gw+EdwTrHTaotb7NKkQXu6yzanH0TrMYuhZ2Tvh7YjFaBAhre2OUL?= =?us-ascii?q?92bMHfyVMvFwTAjliIp4DqPy2a1v8Ws2eF6+pgTvqjgHMppQFsuDevwNkjho?= =?us-ascii?q?fUjY8S11/F+zt2wJ0uJdKmTE57esWpEIVOuCGANot2WcIiQ25uuCog1rIGvp?= =?us-ascii?q?u7cTEMxZ86yRDfbPmHfJKJ4hLlTOuRICl3hG5reL6lgBay60egx+vhXce3yF?= =?us-ascii?q?ZHtjdJnsXWunwQ1RHe5NKLRuZ980qvwzqC2APe5vlZLUwoj6bXNpwszqIqmp?= =?us-ascii?q?YOvknOHTX6lFj1gaOOeEUr5Oul5/jib7jjvJCRNIt5hRr7P6kghMCwHOU1Pw?= =?us-ascii?q?0VUGWf+Omx1rju8EP3TbhIk/I7lLTSvorAKsQBvKG5BhdY0oMk6xmiETiryM?= =?us-ascii?q?8YnXwbLFJdfxKHkpTpN0nOIP/mCfe/hEyhnSp3yf7eI7HuAo3DIHfCn7v9YL?= =?us-ascii?q?px8VBcxxY0zdBF/5JYEKsOL+/pVk/vrtzYFRk5PxaozObgDdVxzoIeWWSRDa?= =?us-ascii?q?+FKK7erEOE6vgyL+SOaoIZoivxJvgr6vL0gnI0mkcRfayz0psWbHC4EO5mI0?= =?us-ascii?q?KcYXf0n9gAH3kFvhElTOP0jF2CSiVeZ2isUKIm5zE7E4OmDYjFRoy3nLOB2y?= =?us-ascii?q?K7EoVMZm9aElCMDWvod4KcVvcDZyKSJ9RsnSYAVbiuVYAuzguuuxXhy7Z9Ke?= =?us-ascii?q?rU4CIYv4r51Ndp/+3TiQ0y9TtsAsSG02GCVWd0kX0TSj8q3aB/pFJyxk6f0a?= =?us-ascii?q?himfNYC8Jc5/dNUggkL57c1PZ2C9foWgLOZt2JUkqpQs26ATEtSdI828IBY0?= =?us-ascii?q?BmG9WllhDOxCuqDKEJl7yFHpA09bjc33eib/p6nlnL07MughEDQ8BPPGCina?= =?us-ascii?q?l5v1zcCIvhmkGWmqywfL9a2zTCoiPL9mqHukwQcwNqS+2RRnAWYEb+sdX86w?= =?us-ascii?q?beVbawBLAjPxFaj8mYJf0ZRMfuiAAMe/r4I9naeCb5t3q5AxvCjueAc4fxYG?= =?us-ascii?q?gZxw3DBVIFiAEc+zCNMg1oVXTpmH7XEDE7TQGnWEjr6+Qr7SrjFkI=3D?=
X-IPAS-Result: =?us-ascii?q?A2FFAABsLnhd/zCZrQplGgEBAQEBAgEBAQEHAgEBAQGBZ?= =?us-ascii?q?4FpgRyBLwqEF5Ehg2yXJQgJAQEBAQEBAQEBAwQBGAsMAQEChD0Cgm04EwIMA?= =?us-ascii?q?QEBBAEBAQEBBgMBAQEChhcMgjopAWFrAQEBAQEBAQEBAQEBAQEBAQEBARYCR?= =?us-ascii?q?BIBARgBAQEBAgEBASFLCwULAgEGAg4KKgICAiULJQIEAQ0FDoMUAYF7Hoxqm?= =?us-ascii?q?2+BMoVLhGYKBoE0gVGKP4FBPoERJx+CTD6CYQEBgWAYgnQygiYErEcDB4Ihg?= =?us-ascii?q?z6CLY8ngjSLYYp1jX+VXYMRAgQCBAUCFYFpgXpwFTsqAYJBPoIPGIhjhT9zj?= =?us-ascii?q?VYrgQSBIwEB?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 10 Sep 2019 19:18:08 -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.1713.004; Tue, 10 Sep 2019 19:18:08 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: George Michaelson <ggm@algebras.org>, Shane Kerr <shane@time-travellers.org>
CC: dnsop WG <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt
Thread-Index: AQHVaC4BnT24qAwvqkecnmp50RK0EA==
Date: Tue, 10 Sep 2019 23:18:08 +0000
Message-ID: <915D04B3-7C54-4DA7-B6E2-A21B27B20B51@verisign.com>
References: <156772626756.24320.17129416326124710273@ietfa.amsl.com> <F32CBA84-2D35-4AA6-AB37-BA24D6F023E2@verisign.com> <40f9c8ae-d7bf-225f-665d-878733b482b4@time-travellers.org> <CAKr6gn2ym7JauyJBaxjKACJPQ64+5gK5yzMgY7qZggqjsJdbgg@mail.gmail.com>
In-Reply-To: <CAKr6gn2ym7JauyJBaxjKACJPQ64+5gK5yzMgY7qZggqjsJdbgg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.9.1)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_0571CA81-F927-4B04-943C-F27D2706A750"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m9BjB7QlT1817tWJ6WEEdRyiY5E>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt
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, 10 Sep 2019 23:18:14 -0000

Thanks Shane & George, I agree this needs some clarification.

Something thats probably missing from the document is that in any future revision of ZONEMD we expect backwards compatibility.  For this version, it is expected that Reserved is set to zero.  In a future version, if the formerly reserved field can have non-zero values, then a value of zero there should produce the exact same hashes as it does in this version.

I gave a presentation at DNS-OARC last year with some experiments in making large dynamic zones more efficient.  There I used the reserved field to encode the depth of a Merkle tree.  A depth of zero corresponds to effectively no tree which is the same as described in the current version.

Recently Mukund posted here a proposal of his for how to store zone data in memory in a ZONEMD-compatible way.  While slightly different than my idea, I believe his also could be implemented in a way such that the reserved field encodes what the consumer needs to know about how the data should be stored and the hash computed for interoperation.

If we agree that a value of zero in this field produces the same hash value in this version and future versions of ZONEMD, then shouldn't we say that it is an error to have non-zero values at this time?  If we say it is acceptable to ignore non-zero values at this time, then it would lead to incompatible hash values in the future version.

DW

> On Sep 9, 2019, at 2:13 AM, George Michaelson <ggm@algebras.org>; wrote:
> 
> This is a not uncommon problem in 'make this protocol work in future' spec. It could say "for version ZERO of this protocol" and then say "future versions of this protocol should stipulate what other values mean, and how this affects handling of all-zeros state, and other states"
> 
> Saying "must not validate" baldly basically says "will always be zero" to me -Which I think is what you're saying!
> 
> _G
> 
> On Mon, Sep 9, 2019 at 3:04 PM Shane Kerr <shane@time-travellers.org>; wrote:
> Duane,
> 
> On 2019-09-06 02:01, Wessels, Duane wrote:
> > 
> > With this version the authors feel that it is ready for working group last call.
> 
> Sorry for a late comment, but I decided to give this one thorough last 
> read-through.
> 
> I'm a little concerned that the way the Reserved field is described may 
> make adoption of later versions of ZONEMD difficult. The relevant text:
> 
> 2.1.3.  The Reserved Field
> 
>     The Reserved field is an 8-bit unsigned integer, which is always set
>     to zero.  This field is reserved for future work to support efficient
>     incremental updates.
>      .
>      .
>      .
> 4.  Verifying Zone Message Digest
>      .
>      .
>      .
>     7.   The Reserved field MUST be checked.  If the Reserved field value
>          is not zero, verification MUST NOT be considered successful.
> 
> 
> The question is, what can a zone producer do to support both this 
> version of ZONEMD as well as a new version? Adding a non-zero Reserved 
> ZONEMD value will break any implementation using this specification.
> 
> I think what would be ideal is for non-zero Reserved values to be ignored.
> 
> If we treat non-zero Reserved the same as unknown algorithms (that is, 
> using placeholders) will that be okay? It may complicate generating 
> compatible ZONEMD in future ZONEMD implementations. With the envisioned 
> incremental version I think it will be fine; if you want both a 
> full-zone and incremental ZONEMD then it will indeed be complicated, but 
> I think probably few zones will need that. I have no idea whether using 
> the placeholder technique will work for more weird and wonderful later 
> versions.
> 
> I suppose it is okay to reject the use case and not worry about 
> compatibility, since we expect the incremental version to be used mostly 
> for large zones where the current ZONEMD simply won't work... 🤔
> 
> Cheers,
> 
> --
> Shane
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop