Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Wed, 21 November 2018 15:11 UTC

Return-Path: <sara@sinodun.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 305F2126BED; Wed, 21 Nov 2018 07:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.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 AF-FNijxGkA5; Wed, 21 Nov 2018 07:11:56 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 0B7E1127B4C; Wed, 21 Nov 2018 07:11:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=balrog-2018; h=To:Date:Subject:From; bh=pUihajPdKPezQFAGRgSXBJ3B5Xe+LGwMrz44/dGaGI4=; b=UdG1FNuY4ANuv7v4J+DnhJMZNz FJPLAsvFwQIbqFTutVeLGKsfTez86INtQXtb04DVjmqnDUtbGdVn2zEu8raytwJqPSHGNNknyJdQo 9ojD9W/bdpm7semL5lhzHeqhMw4S0UXCi93zr8Lz5hsZqgZ0KzMAx8hc0Bte7+q0maTeLYppS8QKT MrwH1Y37Q5jEGxxoRmR5yCPfKYXuEUTtTbWWHj6DWcQOb3yV1W2swsbKKCYgQVNHX2vAsz5EZC6tX zb3jOB1ZT4jML58rWcgilQfYxuq7yvk5zbM9VCPe8Q1LaxRU8gSjbufPef4+z2aZ/VEWEdCW99Lpw lqPdab6g==;
Received: from [2001:b98:204:102:fffa::409] (port=54591) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sara@sinodun.com>) id 1gPUAO-0002L3-RI; Wed, 21 Nov 2018 15:11:53 +0000
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <A21FC3A4-037D-45AB-9D79-2CEB35F06BD3@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5B531CB5-B5AB-4FAD-9602-288EF0484EC9"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 21 Nov 2018 15:11:09 +0000
In-Reply-To: <8EB6F0B2-BE11-4408-A7F5-403161D70855@cooperw.in>
Cc: Joe Abley <jabley@hopcount.ca>, IESG <iesg@ietf.org>, tjw.ietf@gmail.com, dnsop@ietf.org, dnsop-chairs@ietf.org, draft-ietf-dnsop-dns-capture-format@ietf.org
To: Alissa Cooper <alissa@cooperw.in>
References: <154276310324.29833.13160462343514423529.idtracker@ietfa.amsl.com> <CAJhMdTPTJp3Xk8EjVD2juTU1yF3A__Oez52BweNp4Nu6myV5FA@mail.gmail.com> <8EB6F0B2-BE11-4408-A7F5-403161D70855@cooperw.in>
X-Mailer: Apple Mail (2.3445.100.39)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ta8cckTd-hPqewd1TFs_wH392f4>
Subject: Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 21 Nov 2018 15:11:59 -0000


> On 21 Nov 2018, at 10:58, Alissa Cooper <alissa@cooperw.in> wrote:
> 
> 
> 
>> On Nov 20, 2018, at 9:01 PM, Joe Abley <jabley@hopcount.ca> wrote:
>> 
>> Hi Alissa!
>> 
>> On Nov 20, 2018, at 20:18, Alissa Cooper <alissa@cooperw.in> wrote:
>> 
>>> I support Benjamin's first DISCUSS point. In addition to documenting the
>>> privacy considerations, I think it's important for this document to be crystal
>>> clear about who is meant to be doing the data collection -- namely, the server
>>> operator. There are some statements in the document that otherwise could be
>>> construed to be encouraging third-party passive monitoring of DNS traffic
>>> without explaining why, which seems like a problem:
>> 
>> I think it may be worth exploring why that's a problem.
>> 
>> I think a capture format should be oblivious to the circumstances of
>> the capture;
> 
> Ok. This document is not at all oblivious, though (see Section 3). I read the document to be implicitly assuming the server operator to be doing (or at least in control of) the data collection, which is why the two statements I pointed out seemed so striking for their lack of declaring that limitation. If the document was meant to be oblivious, it shouldn’t make normative (in the dictionary definition sense) claims about what is ideal, optimal, or necessary. 

Hi Alissa, 

If we update the statements as below to clarify the context would that address your concern?

Section 1:
OLD:
"There has long been a need to collect DNS queries and responses on
  authoritative and recursive name servers for monitoring and analysis.”

NEW”
“There has long been a need for server operators to collect DNS queries and responses on
  authoritative and recursive name servers for monitoring and analysis.”

Section 3:

OLD:
"In an ideal world, it would be optimal to collect full packet
  captures of all packets going in or out of a name server.”

NEW:
“From a purely server operator perspective, collecting full packet
 captures of all packets going in or out of a name server provides the 
 most comprehensive picture of network activity.”

Sara.