Re: [DNSOP] Incremental zone hash - XHASH

"Wessels, Duane" <dwessels@verisign.com> Fri, 20 July 2018 23:38 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 B6516130FAC for <dnsop@ietfa.amsl.com>; Fri, 20 Jul 2018 16:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_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 JVzesI_Fv3VO for <dnsop@ietfa.amsl.com>; Fri, 20 Jul 2018 16:38:48 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 81BB4130FB2 for <dnsop@ietf.org>; Fri, 20 Jul 2018 16:38:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10906; q=dns/txt; s=VRSN; t=1532129928; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=YFI44rW4YVNBKOYFdmcltQFCmeA93/aFbFvbFpnGu2Q=; b=eXPFuShnhmwb8oIsoLJgIcShpi1t3OUohyLpoBxH5vHSQeVm8+vB9exW SrI6KW+/al+QGo8uOBCdX60DVUQ+khZ6IaOD4LGV1tSqcAiWFZxejNqWc CMWdGtUA5Cnff2ApszmXgjI5QkSBbzmTiP1qmbse12IyD9aCheboNkInh QjERHT6IYiyt70hNwAjfyRJKNEir0ZMsOCK+50AP6axyb/NhTgOiPZ7JB l250ucH02sD/AescCGPXX5QQK+7voXwezjMG24MK1GZW5CEoWpiCWiVgY 66GHXPVLC7kb6F30HpeS7eJSGWiowN7FK/jRDRBYeXnniCHVS6qMVAGyo w==;
X-IronPort-AV: E=Sophos; i="5.51,381,1526342400"; d="p7s'?scan'208"; a="7232601"
IronPort-PHdr: =?us-ascii?q?9a23=3AVukbdh/TQghLK/9uRHKM819IXTAuvvDOBiVQ1KB2?= =?us-ascii?q?1e4cTK2v8tzYMVDF4r011RmVBduds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2O2+55zebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbYqINvRxY7ndcMsaS2RfQ8hRSyJPDICy?= =?us-ascii?q?b4QNDuoOIelXopLyp1cSqBuzHxWgCP/txzJOm3T43bc60+MkEQze0gAvH8wBsG?= =?us-ascii?q?/PrNrrMKcSSvi5x7TGwzXedfxW3yny5IbVeR0mvP6NU6x/cdHKyUYxEwPFlU6d?= =?us-ascii?q?qZL7MDOP1+QNqGmb7+VmVe61l2EnrARxryGpy8wxhIfJgYcVxUrF9SV/2Is1JM?= =?us-ascii?q?O3SFJ1YdK+F5tQrS6aO5NoTcItWW5ovT46yrkYtpKhYCcKz5EnyhjCYPKEa4iF?= =?us-ascii?q?+g/vWPqLLTtlhn9odqiziwuy/EWu0OHxWc253E5XoiZZiNXAq3IA2wDJ5sSaRf?= =?us-ascii?q?Zw/V2t1SuM2gzL5OFLP0M5mbbeJpMk2LE9lZ4evl/GEyL4hkn5ka6be0A/9eWs?= =?us-ascii?q?6unqYLDrq5GSOoJ2lw7zNLkllNalDuQiKAcOWnCW+eG71LL+40L0WK5Kjvgqkq?= =?us-ascii?q?nBt5DaONgbqra5AwBL1oYj7A6yAiq63toAgHUILEpLdh2GgIT1JV3COu74Auu4?= =?us-ascii?q?g1S2iDdn3erJMaD7DpXTNHjDi7Hhcaxh5E5bzQo/1dFf55RKBbEdOP//R1P9uM?= =?us-ascii?q?bFAhI7PQG42fvrBdVz248EVm+CBreVMKbIvl+J4uIvLfOMZIgQuDvlNvck6eDh?= =?us-ascii?q?jWQimVADeampxoAaaG6mEfR8IkWZenvsgtgHEWsQogU+S+nqhEWYUTFPf3ayQ7?= =?us-ascii?q?485jYjBYKjF4jDXIOtj6aa0Se6BZ1ZenpKCleWEXfnb4+EQesDaDqOIs99lTwJ?= =?us-ascii?q?TaWuS4k61RGprA/30LtnIfTI+i0Wr57j08J15+KA3S01oBl9FcfV+meBVWxrhS?= =?us-ascii?q?tcQjYs36lXoFd2jFCZ3v4rreZfEIkZ2P5SSQo+LtqU4/FzDd24ElbNYdqSU1ui?= =?us-ascii?q?Wf24DCswVdM+xZkFZEMrSIbqtQzKwyf/W+xdrLeMHpFht/uEh3U=3D?=
X-IPAS-Result: =?us-ascii?q?A2GVAABWcVJb/zGZrQpcGgEBAQEBAgEBAQEIAQEBAYMfgRG?= =?us-ascii?q?BJwqDdIgEjhoklTwUgV8HCAMYCwuEPgKDLjQYAQIBAQEBAQECAQECgQUMgjUkA?= =?us-ascii?q?Q4vHD0BAQEBAQEnAQEBAQEBIwJABCwBAQEBAgEBASFLCwUJAgIBCBgZEQICAhk?= =?us-ascii?q?MCyUCBA4FDoMSAYF3F6xVgS6EXYVmDwWKVT6BEScMgl6DGQEBgS0BEgEJLSeCQ?= =?us-ascii?q?zGCJAKMXIUch3QDBgKDYYFZVYJlh39Di2qIA4N5hX4CBAIEBQIUgUGBGnFwFTs?= =?us-ascii?q?qAYI+CYIbGINFhRSFPm8BgUMFiRENgR+BGwEB?=
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; Fri, 20 Jul 2018 19:38: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; Fri, 20 Jul 2018 19:38:43 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Mark Andrews <marka@isc.org>
CC: dnsop WG <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] Incremental zone hash - XHASH
Thread-Index: AQHUIBTX7mBtg+ZwQ0atkbatbawIhqSZCHIA
Date: Fri, 20 Jul 2018 23:38:43 +0000
Message-ID: <8D74445E-9D51-4665-8448-19B1C3F47A2B@verisign.com>
References: <FA63BBB1-5AB1-4494-85A9-B43CB2A04F89@isc.org>
In-Reply-To: <FA63BBB1-5AB1-4494-85A9-B43CB2A04F89@isc.org>
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=_67704BA9-7F6C-447D-A88E-FB4602275D2B"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GCyw-ubkUZ5NifWvbpfnHVAp5lU>
Subject: Re: [DNSOP] Incremental zone hash - XHASH
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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, 20 Jul 2018 23:38:52 -0000

Mark,

Thanks for the email.

My first reaction is that it adds a lot of additional records to the zone.  If I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for each XHASH.  You didn't really say how (or if) XHASH could be used on an unsigned zone.

My second reaction is that it is (necessarily) more complex than what we proposed with ZONEMD.  It seems like it probably works, but I haven't really spent time thinking about it in depth.

The use case that my coauthors and I are trying to address with ZONEMD is to verify authenticity for relatively stable zones being distributed to servers other than the ones in the NS RRset.  For this XHASH feels like too much.  Too much data and too much complexity.  I'm not sure if you're proposing XHASH as an alternative to, or in addition to, ZONEMD.

If the latter then I'd say get input from operators of dynamic zones and see if they think the tradeoff of extra data and complexity is of net benefit to them.

DW



> On Jul 20, 2018, at 3:31 AM, Mark Andrews <marka@isc.org> wrote:
> 
> Rather than having a full zone hash this can be done as a chain
> of hashes (XHASH).
> 
> The XHASH would include all records at a signed name (where a signed
> name is NOT an NSEC3 name) up until the next signed name (where a
> signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD.
> If there is a NSEC3 record and its RRSIGs in this range it is included
> in the hash computation.  Where a NSEC3 record matches the name of a
> record that exists in the zone it is hashed with that name. The record
> type appears at both top and bottom of zone similar to NS.
> 
> The chain is only deemed to be complete if there is a hash record at
> the zone apex. This allows for incremental construction and destruction
> of the XHASH chain similar to the way the presence of NSEC at the zone
> apex indicates that chain is complete.
> 
> If there are records that are not at or under the zone apex they are included
> in the final XHASH of the zone sorting from the zone apex to the end of the
> namespace then from the start of the namespace to the zone apex. Such records
> at not normally visible to queries other than AXFR/IXFR.  AXFR/IXFR permit such
> records. 
> 
> XHASH would allow for UPDATE to incrementally adjust the chain without
> having to hash the entire zone at once.
> 
> XHASH would allow for a slave server to verify a zone is still complete
> after a IXFR by just checking the areas of the zone impacted by the IXFR.
> 
> e.g.
> 
> 	example.com SOA
> 	example.com NS ns.example.com
> 	example.com DNSKEY …
> 	example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH
> 	example.com XHASH …
> 
> 	a.example.com NS ns.a.example.com
> 	a.example.com NSEC b.example.com NS RRSIG NSEC XHASH
> 	a.example.com XHASH …
> 	ns.a.example.com A …
> 
> 	b.example.com NS ns.b.example.com
> 	b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH
> 	b.example.com XHASH …
> 	ns.b.example.com A …
> 
> 	ns.example.com A …
> 	ns.example.com AAAA …
> 	ns.example.com NSEC example.com A AAAA RRSIG NSEC XHASH
> 	ns.example.com XHASH …
> 
> Each of the groupings shows which records plus RRSIGs that are
> included in the XHASH calculation.
> 
> To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY
> flag bit is be needed to indicate which RRSIG(XHASH) should/should not
> be present once the chain is complete.  The same applies to RRSIG(ZONEMD).
> 
> Verification of a AXFR would be slightly slower than with ZONEMD as there
> are more RRSIG records to be processed,
> 	
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop