Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

Robert Edmonds <edmonds@mycre.ws> Mon, 19 March 2018 22:24 UTC

Return-Path: <edmonds@mycre.ws>
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 CFDE512E887 for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 15:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 hzLsPsPxisp4 for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 15:24:40 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B03312D965 for <dnsop@ietf.org>; Mon, 19 Mar 2018 15:24:19 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id D8DDB12C20C2; Mon, 19 Mar 2018 18:24:18 -0400 (EDT)
Date: Mon, 19 Mar 2018 18:24:18 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Message-ID: <20180319222418.xrkh5opxts46wj6c@mycre.ws>
References: <alpine.LRH.2.21.1803190813150.31565@bofh.nohats.ca> <20180319163434.GA25738@laperouse.bortzmeyer.org> <CA+nkc8CWtXOiXCVQf4iyJwBS1K4seLxsJmtZyRyz7yuCn+u8hQ@mail.gmail.com> <20180319194945.GG3322@mournblade.imrryr.org> <20180319205014.rajzau6bvps7jr6p@mycre.ws> <alpine.LRH.2.21.1803191730090.12290@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.21.1803191730090.12290@bofh.nohats.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zc7N4Kb5MsDOn-xBguyl9LE2Qls>
Subject: Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 19 Mar 2018 22:24:46 -0000

Paul Wouters wrote:
> On Mon, 19 Mar 2018, Robert Edmonds wrote:
> 
> > Viktor Dukhovni wrote:
> > > The idea is to log the DNSKEY RRs observed at each zone apex.
> > > Without the proposed flag, one would also have to log denial of
> > > existence which would make the logs much too large.
> > 
> > Can you expand on what you mean by "much too large"? There are already
> > existing large scale passive DNS systems that log every RRset that they
> > observe, and on relatively modest amounts of hardware. Is transparency
> > for DNSSEC really all that less tractable than the "log every RRset"
> > problem?
> 
> Do these large scale passive DNS systems then host the data for (m)any
> clients to fully download?

If those "(m)any clients" were interested in being customers of the
operator of the large scale passive DNS system, then yeah.

https://www.farsightsecurity.com/faq/#q13

> There are also privacy aspects. if you need to audit/log every query,
> you are uploading more personal identifiable information. Combined with
> TTL=0 or really short RRSIG times, these can become trackers. DNSKEY and
> DS records don't come with such short TTLs (or if they would it could
> itself be seen as a sign of malicious behavior) so there is much less
> of a one to one relationship between those queriers and answers.

Who is uploading what to whom in this scenario?

Suppose there were something like
https://www.internic.net/domain/root.zone, but instead of being a daily
point in time snapshot of the root zone in master file format, it were a
log that captured each RRset and a publish date, going back for some
small window of time, and it were (ugh) PGP signed so that you know it's
authentic. Would that be enough for independent auditors to construct
and publish their own append-only Merkle tree logs or whatever, so that
folks who want to "trust, but verify" the DNSSEC responses from the root
could do so without having to upload their query logs to anyone? If so,
doesn't this generalize to TLDs as well?

That is, I guess I'm saying if you need cooperation from the zone
publisher anyway, why not just get them to publish what you need, out of
band? (Sure, it doesn't work for the TLDs that don't want to publish
their zones.)

-- 
Robert Edmonds