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

Bob Harold <rharolde@umich.edu> Fri, 27 July 2018 14:58 UTC

Return-Path: <rharolde@umich.edu>
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 6D60E130EF9 for <dnsop@ietfa.amsl.com>; Fri, 27 Jul 2018 07:58:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 rmyk_XgAc7Dd for <dnsop@ietfa.amsl.com>; Fri, 27 Jul 2018 07:57:59 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C19130E01 for <dnsop@ietf.org>; Fri, 27 Jul 2018 07:57:58 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id l15-v6so4694899lji.6 for <dnsop@ietf.org>; Fri, 27 Jul 2018 07:57:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j3kax7kLek6Hos+/eWPtdNadmnkFUSF6vISt+od5Yq4=; b=r+VySo4Iw3xJYZsH2VdsohDsGgSMABN9fLJ5AOhCr2eD5X7ZBLjzHlD5WP8UOvfAEn OOZv1t0jrpyPesCg10BxcDJQ9A4mZqEJeQ30+wzytZTch3Y14GgmfPHMHojtaiCzf0dc KsyB14gWVZ55EDzA6WV34r1lCzemU9Mz/2yZ4KC4kBfBHjrbJnTY82IC4m7lenyTbOfT l3sSsJ1TMEuzKRalsJIuxLcipL+55UbH4+WKdHj3rwS00gW0U4+RZU8upCVJxutLb8Oe 3DdfXfplWzRZuQzSA0trOHOHfQJr/OE5a2ojpUW+VJLl28WJgpsCFfq32u8EuqIZmq1G 1l9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j3kax7kLek6Hos+/eWPtdNadmnkFUSF6vISt+od5Yq4=; b=buRQdt7K+B6nMptESNSY6/wEWxWmwk9kyOFI9QxrDSbogt9VUrGfwi/UIynAojDTq+ 9sp2+hvkXl9UZ5t+R0s7oREGL3jXIf34K4GAQDoh2Drh4Q6rquGLowuTJeB6t6VuZycA doUT8aMP2fDWHGdMMMma3Voz3ijgD/4CQB8ynoyXcRMgEbv87dP92EssPCgrx6wSEBdC bun86H/F2ZPLH80m7iBSjpB6DDAneCIO8cHbkhcKHqZEVd9KiIoykpXY5jtZcYhlByx8 cQ406CAY23JSux03SrNhDuEb13K4ALP0HA0KBy54Hmqc1Hm5pYk2iGv6h3x2a+OfEB0V MN6Q==
X-Gm-Message-State: AOUpUlECpQctovCHUIJnJJtF6Q7k5uN9urUQOr6G6wjvPD3mvN0jpXSq VJSSpGQt9KguGZQzxrysyLy7msUQ42Tt7myEppy037YS
X-Google-Smtp-Source: AAOMgpfa1NXF90DmfPZcdT2ITwo8RgJ8L/aTIoZEi0PdD4XmGt8beWkGwNSotbtPpIP0olCb+KD3mJWoMvNiCJlvkQ8=
X-Received: by 2002:a2e:1517:: with SMTP id s23-v6mr5492514ljd.73.1532703476935; Fri, 27 Jul 2018 07:57:56 -0700 (PDT)
MIME-Version: 1.0
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <CAJE_bqcELQbQeHPvvEBHOxpRyWYL76BmT_-G4jW4pTnUUXFMUw@mail.gmail.com> <CAAObRXL2LoB3f=296ZPE1Pp1nHkG---pRPAmyO1trTROxneHDQ@mail.gmail.com> <FF0A0A24-705F-46E3-BF31-314078636EE2@isc.org> <84636548-60C4-40F5-8C05-E5AD70886CB4@isc.org> <B795E43C-E0A1-4965-995B-BD50606DCEB2@shinkuro.com> <9EF9C62B-896F-4A06-8C88-35D943D063DA@isc.org>
In-Reply-To: <9EF9C62B-896F-4A06-8C88-35D943D063DA@isc.org>
From: Bob Harold <rharolde@umich.edu>
Date: Fri, 27 Jul 2018 10:57:45 -0400
Message-ID: <CA+nkc8BJN6_a2N8GmOLXsqvmYm-1UmVfX6-g2Kw_REtJ1N6GCA@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: steve@shinkuro.com, "Song Linjian (Davey)" <songlinjian@gmail.com>, IETF DNSOP WG <dnsop@ietf.org>, mweinberg=40verisign.com@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="0000000000004a027e0571fc561f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cGkJy9SIoZ4Two9RrgeBtCD-wDI>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
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, 27 Jul 2018 14:58:03 -0000

On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews <marka@isc.org> wrote:

>
>
> > On 27 Jul 2018, at 12:39 pm, Steve Crocker <steve@shinkuro.com> wrote:
> >
> > The passage below puzzles me.  Why do you want servers to get the root
> zone from less trusted sources?
>
> 1) to spread load.
> 2) not all recursive servers have direct access to authoritative sources.
> Some times they need to go through intermediaries.  The same will be true
> with transfers of the root zone.
>

Maybe I am wrong, but having lots of servers all around the world asking
for the same update at the same time looks like a good place to use
bittorrent.  (Is that reasonable?)  So the 'sources' will be untrusted, and
we do need some way to verify the resulting file that we get.

I like the XHASH idea, it seems to reduce the work required on each
update.  But I would be ok with ZONEMD also.

-- 
Bob Harold


> >  And why does the source matter if the zone entries are DNSSEC-signed?
>
> Steve please go and re-read the parts you cut out when quoting the
> previous message.  It gave several reasons.
>
> Also please look at what is and isn’t signed in a zone and think about
> what can be done when you can change the unsigned parts.
>
> Also think about what can be done when you change the signed parts but
> don’t individually verify the RRsets but rather just trust the zone content.
>
> I have a local copy of the root zone.  It lives in a seperate view which
> is not accessed directly by clients  The name server validate its contents
> when performing recursive lookups on behalf of clients.  Such
> configurations are complicated and error prone.  It also doesn’t remove
> potential privacy leaks.
>
> Having a way to verify the entire zone’s contents without having to verify
> every RRset individually after each zone transfer would make running such
> configurations easier.  It also removes threats that DNSSEC alone does not
> remove.
>
> > Thanks,
> >
> > Steve
> >
> > Sent from my iPhone
> >
> >> On Jul 26, 2018, at 7:33 PM, Mark Andrews <marka@isc.org> wrote:
> >>
> >> Additionally most nameservers treat zone data as fully trusted.  This
> is reasonable when you are getting data from a “trusted" source.  For the
> root zone we want servers to be able to get a copy of the zone from a
> untrusted / less trusted source.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>