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

Petr Špaček <petr.spacek@nic.cz> Tue, 19 June 2018 14:32 UTC

Return-Path: <petr.spacek@nic.cz>
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 D24A91311A7 for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.52
X-Spam-Level:
X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 LGBCgmRma56J for <dnsop@ietfa.amsl.com>; Tue, 19 Jun 2018 07:31:58 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 EC86413113A for <dnsop@ietf.org>; Tue, 19 Jun 2018 07:31:57 -0700 (PDT)
Received: from [192.168.3.5] (ip-86-49-248-232.net.upcbroadband.cz [86.49.248.232]) by mail.nic.cz (Postfix) with ESMTPSA id 24B9F6072B for <dnsop@ietf.org>; Tue, 19 Jun 2018 16:31:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1529418716; bh=xoAG+Tsb6+3RPfjdATdO/t/dDAH+Uexsmsl/nXg5tU4=; h=To:From:Date; b=ozAggu2qgL4SXV06ECjkOz+LvhkileBIJ1LyvW5YGfaJ8bB6mjRakFR4wIwlzvls4 2w2y5RtCx1ZPFdJdBt+WQKztAgobWrDWjUAks5BN6UoqcCW9ETKOe4GNpdmR0e2uOO iu12wP/Lr/hiZSigqEbp+foE19eOop3LQ7omUnoI=
To: dnsop@ietf.org
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>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <37873808-8354-b26b-34f4-880ea7a5f0da@nic.cz>
Date: Tue, 19 Jun 2018 16:31:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <884c2d11-9db0-7668-59c9-baa8574a03f7@time-travellers.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NS6jeQ4Yz7jWkovaVX7AWgSU1LY>
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 14:32:10 -0000

Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
> Wessels, Duane:
>>
>>> On May 25, 2018, at 11:33 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:
>>>
>>> At Wed, 23 May 2018 15:32:11 +0000,
>>> "Weinberg, Matt" <mweinberg=40verisign.com@dmarc.ietf.org> wrote:
>>>
>>>> We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note,
>>> this -01 version includes the following changes:
>>> [...]
>>>> We plan to ask for time on the dnsop agenda in Montreal.  Your feedback
>>> is welcome and appreciated.
>>>
>>> I've read the draft.  I have a few high level comments and specific
>>> feedback on the draft content:
>>>
>>> - It was not really clear exactly what kind of problem this digest
>>>    tries to solve, especially given that the primarily intended usage
>>>    is for the root zone, which is DNSSEC-signed with NSEC.
>>
>> Thanks you for the feedback.  We will write a clearer problem statement
>> in the introduction for the next version.
> 
> As I mentioned, I have seen zones broken during transfer in production,
> and having a standard way to check for this seems reasonable.

Hmm, can you share some details about your experience?
Did you find out when the data corruption took place?
a) network transfer
b) implementation bugs (e.g. incorrectly received IXFR)
c) on disk
d) some other option?

I wonder if this proposal is worth the complexity ... If we wanted plain 
checksum we could use TSIG with built-in key (all zeroes or so) and to 
get checksum for the network part with negligible implementation 
complexity. (TSIG trick is Mukund's idea, not mine.)

If we wanted checksum for on-disk data, well, the outside world has 
tools for this already ...

This proposal smells little bit as not-invented-by-dnsop syndrome 
because it does not build on existing technology. There are technologies 
to protect data in transit and technologies to protect data at rest 
already so we might look how to reuse them instead of reinventing wheel 
just for DNS. Reinvented wheels tend to have sharp edges, especially in 
security area :-D


>>> - This digest can't be incrementally updated, that is, you'll need to
>>>    calculate the digest over the entire zone even if just a single
>>>    record is modified (am I correct?).  That's probably an inevitable
>>>    cost for the motivation of providing cryptographically strong
>>>    integrity check, but that's a pity for me.  One case I know of where
>>>    things like "zone digest" is wanted is to ensure consistency for a
>>>    very large zone between primary and secondary servers that are
>>>    synchronized using IXFR.  In principle they must be consistent, but
>>>    operators may want to have a lightweight (albeit not
>>>    cryptographically strong) way to confirm no unexpected events (such
>>>    as an implementation bug) quietly broke the consistency.  Perhaps
>>>    such usage is just outside the scope of this proposal, but I first
>>>    expected I could use it for this kind of purpose it was a bit
>>>    disappointing and I wanted to mention it.
>>
>> Incremental updates could be supported if the working group feels it is
>> important.  We have a working proof-of-concept implementation of this that
>> hashes individual RRsets and then XORs them into a final message digest
>> (thanks to Roy Arends for the suggestion).
>>
>> However, this complicates the implementation.  It almost certainly requires
>> more CPU processing but probably not to an extent that matters significantly.
>> We could do some simple benchmarks.
>>
>> If there is desire to follow this path, then we should discuss whether or
>> not to keep having the zone digest algorithms exactly match the DS digest
>> algorithms.  For example, digest alg 2 could mean "SHA256 over the zone
>> as a whole" while digest alg 3 could mean "SHA-256 digest and XOR individual
>> RRsets" to support incremental updates.
> 
> As I mentioned in my review of the first version of this document, I
> think that inserting digest records periodically throughout the zone
> could serve to allow incremental updates (as the recipient can cache
> unchanged values) and also allow a degree of parallelism.
> 
> I certainly won't push for it. My main concern is that for large-ish
> zones with frequent updates digest is basically useless without such a
> mechanism.

It depends on what you want to protect from: If it is corruption during 
network transfer then TSIG is the answer, possibly with a built-in key 
(e.g. all zeroes to make it zero config/checksum only).

I think we need to first answer question why existing technologies do 
not fit the purpose.

-- 
Petr Špaček  @  CZ.NIC