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

Steve Crocker <steve@shinkuro.com> Fri, 27 July 2018 02:53 UTC

Return-Path: <steve@shinkuro.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 8E08B12785F for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 19:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.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 8IXvNGqaeSPK for <dnsop@ietfa.amsl.com>; Thu, 26 Jul 2018 19:53:06 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 BEAFA127333 for <dnsop@ietf.org>; Thu, 26 Jul 2018 19:53:05 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id t13-v6so3558253wrv.12 for <dnsop@ietf.org>; Thu, 26 Jul 2018 19:53:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6t0aPJNQDLVYcvz07kM6/USCQorifTbAOAD9aLnX3bA=; b=TV19xOEyM+L5aHFZqVIq0DTb9wMYXEuu/einJrrIfD2WgyfTzozODOplMBXY7oUULR EoXHVzXJ+a3uQM6SHmqrkN+GSEaQnewp9ROBxUlenpKNEy0zJ/whmLMTDlZ+80Pn4aoN YUNrfyK3dkCYrjzNi8PV8YHpvLnwcAskf+MzR5LyL/abdDuIb/ThXz8QBqsJO9XblJXB H+qmDT7pm9yP2FKeahLTr44GLFnJL/GgRnkT5Y/bWw6/6J/Niav3l0rcinesmbzAUA4j 0Z9pwWMI6kfjRR7OXoOyPT+9VVIlaDBpZySwgIKm4Sf6OGkgp/anxpndQ1UNntYQn6t9 3I1A==
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=6t0aPJNQDLVYcvz07kM6/USCQorifTbAOAD9aLnX3bA=; b=kfE3myjfcXlk9U5sCgypwhFAC6k4dT/hY6Q1ruT+OFN8WS/f7M3wJ6E1+6Lpp7IQwV vqfFZAWAQFRlLYPNSYdqg1ME1it/RBH00YkF+QidJzXnjpqTxLVgw55cAZakRPfnODEz 8VUODZ652BqU1uurDVduHRNjRmIfvj0dreDTToXF95JbX81boXd5BkAtoMtHDgebT7Zh 7o+SvEK97SsazMF2MDUQp/cv/GyUizCtqJD+rBW+aIbg8vZVpGjh6DftnUBAdy2Wmb68 j99g6MvwqPCgvP8VX/IqojhfJFXOWr5pjr5dzpn4Q6yyZhljkZ8u4ba25HBAiYa4CUYl xAJw==
X-Gm-Message-State: AOUpUlG6vCGCulwEG1W11mB0NdagqY7RJCKQeMoXBNgXpfG4GSMl6c72 dgBYLP9e89qzxtOAPN9AQdGqQVrYHuGveW8o2Hmcww==
X-Google-Smtp-Source: AAOMgpeYjp9QldpVuN37I8fjxFwoJCMgsKQ4UX51fg1kdQGj9/FB1g/98tWJROekYiH+TMiJLVlRKqFfVBTg7/a2dH0=
X-Received: by 2002:a5d:6345:: with SMTP id b5-v6mr3350323wrw.266.1532659984334; Thu, 26 Jul 2018 19:53:04 -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> <CAHPuVdU8YjbnsVGP4qEVoMA4ZdBo3_bHjV+PxgAOEGsKd742Uw@mail.gmail.com>
In-Reply-To: <CAHPuVdU8YjbnsVGP4qEVoMA4ZdBo3_bHjV+PxgAOEGsKd742Uw@mail.gmail.com>
From: Steve Crocker <steve@shinkuro.com>
Date: Thu, 26 Jul 2018 19:52:53 -0700
Message-ID: <CABf5zvKnV_YodJSE3UcEXVfJaew0enCzDg_T7Ni=D8xS=s8zAg@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: Davey Song <songlinjian@gmail.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>, mweinberg=40verisign.com@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="000000000000ed96f90571f23556"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OqpHFSVLwHJy2Og2RWuQJF1w3ac>
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 02:53:09 -0000

Let me play Candide and stumble into this naively.  If we’re imagining very
wide spread distribution of the root zone, say 100,000 or 1,000,000 local
copies distributed twice a day, I would expect the evolution of a set of
trusted sources and the use of some existing secure transport protocol to
protect the transmission.  No new protocol or data types, just a way of
finding the address of one more trusted sources.  And the existing set of
root servers seems like a perfectly good set of trusted sources.

Steve

On Thu, Jul 26, 2018 at 7:45 PM Shumon Huque <shuque@gmail.com> wrote:

> On Thu, Jul 26, 2018 at 10:16 PM Davey Song <songlinjian@gmail.com> wrote:
>
>>
>> - 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.
>>>
>>
>> It puzzled me as well.
>>
>> It is said in the document that diffferent from DNSSEC (and NSEC), the
>> zone digest is for the intergirty of unsigned NS and Glue of the zone. As I
>> asked in IETF102: why unsigned NS and glue is worth of protecting by
>> introducing a new RRtype, addtional complexity of degesting and validation.
>> Is it really necessary for local resolver(or local-root) aware the integity
>> of NS and glue?  any technical problems if the NS RR and glue are
>> modified locally?
>>
>
> The ZONEMD digest is over the entire zone, not just the delegation NS and
> glue records.
>
> Normally, in order to ensure that secondary servers accurately got a copy
> of a zone from the master server, we would use a channel protection
> mechanism like TSIG. This is typically needed even if they were no unsigned
> data in the zone because authoritative servers do not typically validate
> signatures of the data in zones they themselves serve - in theory they
> could, but in fact I don't know any implementations that validate RRSIGs
> received over zone transfers - they just trust the source and serve the
> data. Resolvers validate signatures. Authoritative servers that serve
> signed zones trust that they have already have an authentic copy of the
> zone.
>
> The problem for wide scale distribution of the root zone, is that
> traditional TSIG (without adding a complex key management infrastructure)
> doesn't scale. Earlier in this thread, I had proposed that SIG(0) could be
> a scalable solution to this problem, but it has some limitations, and Duane
> has argued that the full zone signature is a better solution. I'm not
> opposed to this, but I think Mark Andrew's XHASH proposal is worth thinking
> through also.
>
> Even if the local-root-zone resolvers were modified to validate signatures
> of signed RRsets in the zone, if a MITM attacker fed them bogus glue, to
> recover from this, they would need operator intervention to manually
> retransfer the zone. This doesn't strike me as a robust operational
> configuration.
>
> --Shumon.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>