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

"Paul Hoffman" <paul.hoffman@vpnc.org> Thu, 21 June 2018 19:08 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 58C61130DE0 for <dnsop@ietfa.amsl.com>; Thu, 21 Jun 2018 12:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 0dn-rq-fo_0h for <dnsop@ietfa.amsl.com>; Thu, 21 Jun 2018 12:08:45 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 38EE4130DCD for <dnsop@ietf.org>; Thu, 21 Jun 2018 12:08:45 -0700 (PDT)
Received: from [10.32.60.124] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w5LJ8bxZ060860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Jun 2018 12:08:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.124]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Shumon Huque <shuque@gmail.com>
Cc: WG <dnsop@ietf.org>
Date: Thu, 21 Jun 2018 12:08:39 -0700
X-Mailer: MailMate (1.11.2r5479)
Message-ID: <37325A39-3169-4B4F-A51E-D594B814F861@vpnc.org>
In-Reply-To: <CAHPuVdVWYiJNfWtNeuT_a86zdbjYRaWwbbuiPhLPEfqrk87PTw@mail.gmail.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> <20180619231512.GA26273@jurassic> <CAHPuVdVSXNKZEhZ_2-vV_9py_n5Dw+FaMXXBbQtORwGF2xuDQw@mail.gmail.com> <ebf643d5-a85d-2f72-88f3-3710acde4746@nic.cz> <30E5CEA0-F7D9-46B5-B262-599C2101D479@verisign.com> <CAHPuVdVWYiJNfWtNeuT_a86zdbjYRaWwbbuiPhLPEfqrk87PTw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xajnZVAzjWN9CgWmUOyo1zF0Zn0>
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: Thu, 21 Jun 2018 19:08:46 -0000

On 21 Jun 2018, at 9:40, Shumon Huque wrote:

>> My goal is to ensure that when you receive a zone file -- however you
>> receive it (DNS, HTTPS, P2P file sharing, Avian Carrier) -- you get 
>> the
>> data that the zone publisher actually published.
>>
>
> I can't argue with that goal (and yes, you should probably clarify it 
> in
> the draft).

Fully agree. However, Duane's goal is only reachable if the zone is 
DNSSEC signed. Otherwise, an attacker can just change zone contents and 
the hash as well.

> The question for me is what are the use cases for this protocol
> enhancement, and is this the only way to satisfy those use cases?

Yes, the use cases are pretty central here. As we have discovered in the 
DOH WG, DNS folks can read a document and come away with quite different 
use cases from the authors *and* from each other, all the time thinking 
that their use case is obvious.

> In my mind, the main compelling use case is secure distribution of the 
> root
> zone at scale to anyone on the Internet. For that, I'd bet that many
> consumers would be quite okay with a channel security mechanism to a
> "trusted" root zone operator, whatever that mechanism is (TSIG, 
> SIG(0),
> TLS, HTTPS, etc) as long as it could be done efficiently and at scale. 
> A
> full zone signature from the zone publisher/signer is ultimately more
> secure of course. But if the security model is satisfied by trust in 
> RSOs,
> then that isn't needed.

While "many" consumers think that is OK, some (very vocally) do not. 
Having a hash over the complete root zone, and having that recorded as 
part of the signed zone, should satisfy those that do not want a second 
trust anchor (that is, for the channel security).

> The normal case of distributing a zone securely to all your 
> authoritative
> server operators, I believe, is adequately satisfied today by zone
> transfers authenticated by pre-configured static TSIG keys provisioned
> between the authorized parties. Do you see the full zone signature as 
> a
> replacement for this scenario too? (There are many zones much larger 
> and
> more frequently updated than the root zone, for which I believe the
> computational cost of this is too prohibitive).
>
> As noted earlier, out of band verification of the full zone using an
> integrated signature that does not rely on an external keying
> infrastructure, is also a plausible use case. I'm just wondering if it 
> has
> a compelling need.
>
> Anyway, not trying to derail this effort, just asking questions. On
> balance, I think I support this draft.

I agree, as long as the use cases are made clear so that we can compare 
the solution against them.

--Paul Hoffman