Re: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and COMMENT)

Allison Mankin <allison.mankin@gmail.com> Sun, 28 June 2020 20:11 UTC

Return-Path: <allison.mankin@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3D63A0F0A; Sun, 28 Jun 2020 13:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iehArWWZ4UDl; Sun, 28 Jun 2020 13:11:40 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 06A313A0F09; Sun, 28 Jun 2020 13:11:39 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id i16so11396417qtr.7; Sun, 28 Jun 2020 13:11:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=rSEf11IrWQLjt6ejfGqFe0/mZ/ri4Wrhkhd/Y8rmCSU=; b=MHn625mT9vNmN59+VCfe1usljSCNf4pi2W41KgWnyGGgIeF7D1DNqRWQGQ7HLnLxek 4vZeM6ue43NKTzXUi37/cZXo9O6ILK3pVzkvGOC2Yd+zqHYCtHLOD2AQE2R4ZKpGk8MR gpgQqO6mqm3SdzjJGQi9XST7hIIUeiNCyBrsxXFQnt5GPI0Bu3NpyfxoProFIA3ds0po sJTPj1mvcVwlnPJOz7yl1O/83+KPtvyJcvhuDq30umJsycHbHh16PRaTnP8I4wLKrPI6 aJiJAjTYxe9vvgJZgQoVF8aBg5xIWxtPlARIl+2l0oddU+ExP8NXSnVcBMa6Sgyq81gS 9dsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=rSEf11IrWQLjt6ejfGqFe0/mZ/ri4Wrhkhd/Y8rmCSU=; b=Iq1aOUsjdTMyhhEZLk5NOmzCzlwXlE5u0fc/Ei9zm5UCPPlr9d2kJ1rm9BxLX3oUgo jbM6ts1Aj0CioDVPwE+pdeDA9zuPAq5199/an5C5Ofl/mLDIiGZGqqqDpBSSu82QA0h8 YoafgVc/oWAlg4DzRFixygy09dR7x4O0LpnCiAztAm6EyD8QOhwFeIiradr4BQTT6yqc Rur0pIcaP4Ud9lAcfLic8mtmGlCYS6Hfl2cczyZ0kqk8PAgBQgPOKE8zyARx78iBcyMG Q0boToWfqyWy57vwRlKj3OjRA3afK3PxQnWk1dutI8bSRp8nCj4Tb47wRecvOFVjyfig H/Rw==
X-Gm-Message-State: AOAM531WVcnTXfhP5qAJ+oOwHP4hoe7NnZk4vrQ0rK4cL2jv09K8Jnet yFGMaUyy+Bgk1W6qv3CgbymfI5AO
X-Google-Smtp-Source: ABdhPJySpRTUjjfNUMbnDSQtKFwlIyh58GX042HbZAbERt1uTgTI0V1YCQNFSp+9MPcTGbFDMK7cmQ==
X-Received: by 2002:ac8:7343:: with SMTP id q3mr13447792qtp.165.1593375098510; Sun, 28 Jun 2020 13:11:38 -0700 (PDT)
Received: from [192.168.1.3] (pool-108-28-90-34.washdc.fios.verizon.net. [108.28.90.34]) by smtp.gmail.com with ESMTPSA id x4sm12716902qkl.130.2020.06.28.13.11.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Jun 2020 13:11:37 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-FAA2113B-7D91-422B-A4B7-AFA9F6666A2C"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Allison Mankin <allison.mankin@gmail.com>
In-Reply-To: <9826D3BC-02B4-4249-81AF-D118543C69A1@cooperw.in>
Date: Sun, 28 Jun 2020 16:11:36 -0400
Cc: Sara Dickinson <sara@sinodun.com>, Vittorio Bertola <vittorio.bertola@open-xchange.com>, IESG <iesg@ietf.org>, draft-ietf-dprive-bcp-op@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, dns-privacy@ietf.org
Message-Id: <A1E45CB9-FA53-4889-97BD-EFC42A0FBC4F@gmail.com>
References: <9826D3BC-02B4-4249-81AF-D118543C69A1@cooperw.in>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/NlCeNfMuVX6cXMbwaVE2Crp16Bw>
Subject: Re: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2020 20:11:43 -0000

Hi Alissa,

Please read the -10 version. We've addressed this Discuss by omitting any mention of jurisdiction and marking all texts in the DROP statement section as non-normative. 

Sara references the change in the June 18 email with subject line:  IESG review of draft-IETF-DPRIVE-BCP-op

Here's the new top of Section 6; is this enough to satisfy your Discuss?

The contents of Section 6.1.1 and Section 6.1.2 are non-normative,
   other than the order of the headings.  Material under each topic is
   present to assist the operator developing their own DROP statement
   and:

   o  Relates _only_ to matters around to the technical operation of DNS
      privacy services, and not on any other matters.

   o  Does not attempt to offer an exhaustive list for the contents of a
      DROP statement.

   o  Is not intended to form the basis of any legal/compliance
      documentation.

> On Jun 28, 2020, at 14:43, Alissa Cooper <alissa@cooperw.in> wrote:
> 
> Hi Sara,
> 
> Thanks for your response and the updates to the document. I’ve trimmed my DISCUSS down to the remaining issue.
> 
>>>> On Mar 4, 2020, at 8:29 AM, Sara Dickinson <sara@sinodun.com> wrote:
>>>> 
>>>> 
>>>> (3) I do not think item #5 in Section 6.1.2 belongs in this document. I don't
>>>> see how it is within scope for the IETF to be specifying these sorts of best
>>>> practices, which are not technical or operational in nature but focus on legal
>>>> matters and likely require the involvement of lots of lawyers in order to get
>>>> the provisions written. 
>>> 
>>> I’m channelling Vittoro here (cc’ed) who as a Head of Policy helped to formulate this text…
>>> 
>>> The reason this was included is that the actual policy that will apply to the data is the merge of the operator's privacy policy and of the relevant jurisdiction's privacy laws, with the latter overriding the former in case of conflict. Since the former is in scope for the DROP it seems reasonable for the latter to be. If the goal here is to provide a document that informs users of what will actually be done with their data, then outlining which privacy laws will apply to them and how these laws will play out seems reasonable. 
>> 
>> I don’t really see how the above is responsive to my point. This is not the IETF’s area of expertise and therefore we should not be specifying best practices about it. Every IETF technology exists within a framework of laws and regulations that vary by jurisdiction, but we don’t specify best practices about them because they aren’t within our scope. We also don’t want our RFCs to be obsolete because one country or region decides to change its laws — we’re aiming for global significance.
>> 
>> 
>>> Also, I think what
>>> this section asks for is not the norm today and therefore it seems odd for the
>>> IETF to specify a best practice that operators may not have any chance of being
>>> able to comply with (e.g., listing specific law enforcement agencies, privacy
>>> laws, or countries where data centers will reside and the data will never move
>>> from them).
>> 
>> It's also not true that supplying this information is "not the norm today". Any GDPR-compliant privacy policy must specify the legal entity processing the information, its place of business, the user's rights, and whether the information will be moved to third countries. Basically, points 5.1-5.3 only turn into best practice what the GDPR mandates in Europe - and there is little doubt among privacy experts that the GDPR is the current global best practice in terms of privacy laws. 
> 
> The IETF operates globally and I think endorsing the idea of fracturing data management and protection along jurisdictional lines is far from a best practice that the body of the IETF’s work endorses.
> 
>> 
>> As for 5.4, there are already significant efforts for the disclosure of law enforcement access, even in the US and even with creative ways to circumvent legal issues (see https://en.wikipedia.org/wiki/Warrant_canary ). It's not an issue that has no grounds in reality.
> 
> 
> Best,
> Alissa
> 
>> 
>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Section 1:
>>> 
>>> "This document does not, however,
>>>      define a particular Privacy statement, nor does it seek to provide
>>>      legal advice or recommendations as to the contents."
>>> 
>>> This is not accurate. The document does make recommendations about the contents.
>> 
>> Will remove ‘or recommendations’. 
>> 
>> 
>>> 
>>> Section 3: "the privacy of the DNS" strikes me as a bit of an odd term as the
>>> DNS itself doesn't have privacy needs. Perhaps this means the privacy
>>> properties of the DNS.
>> 
>> Yes - will update. 
>> 
>>> 
>>> Section 5.2.3: I think the table and its associated text belongs in Appendix B.
>>> It is not BCP material itself and is not readily understandable without the
>>> rest of the text in Appendix B anyway.
>> 
>> Fair enough - will move this. 
>> 
>>> 
>>> Section 5.2.4: "Resolvers _might_ receive client identifiers e.g.  MAC
>>> addresses in EDNS(0) options - some Customer-premises equipment (CPE) devices
>>> are known to add them." It would be great to add a citation there if one exists.
>> 
>> Yes - will add. 
>> 
>>> 
>>> Section 5.3.3:
>>> 
>>> "Operators should not provide identifiable data to third-parties
>>>   without explicit consent from clients (we take the stance here that
>>>   simply using the resolution service itself does not constitute
>>>   consent)."
>>> 
>>> I'm not convinced its appropriate for this document to be commenting on what
>>> constitutes consent.
>>> 
>>> I also think that as a general matter the research in this area demonstrates
>>> that privacy-by-consent is broken and that the number of cases in which an
>>> individual providing consent for identifiable data sharing actually reads,
>>> understands, and agrees with the terms of the sharing is miniscule.
>>> 
>>> It seems like the real best current practice mitigation here is to not share
>>> identifiable data.
>> 
>> I appreciate the difficulties with this, but several aspects of this draft have got push back on the basis of how many operators actually employ the ‘best practice’. The reality is that many of the large recursive operators currently make some statement about the DNS service or in an umbrella privacy statement to the effect that they will share data if they have consent (and then completely fail to describe what that consent entails), for example:
>> 
>> https://www.cisco.com/c/en/us/about/legal/privacy-full.html  (Overall policy which appears to apply to OpenDNS - OpenDNS doesn’t seem to have a specific one)
>> We may share your personal information with third parties for the purposes of operating our business, delivering, improving, and customizing our Solutions, sending marketing and other communications related to our business, and for other legitimate purposes permitted by applicable law or otherwise with your consent.
>> 
>> https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/privacy-policy/
>> Cloudflare will not sell, license, sublicense, or grant any rights to your data that we collect from DNS queries to any other person or entity without your consent. 
>> 
>> https://policies.google.com/privacy?hl=en (Overall policy referenced from the Google Public DNS privacy policy page)
>> We’ll share personal information outside of Google when we have your consent.
>> 
>> 
>> It is somewhat frustrating that this draft doesn't tackle this issue in any meaningful way. We had previously included a clause in the DROP statement where the operator was recommended to outline their specific consent process (so in other words, not defining consent in this document in any way,  just requiring operators to clarify how _they_ define it given they have used the word) but this received some push back.
>> 
>> Adding an optimisation describing the ideal position (not sharing) seems reasonable, as would adding any additional text to clarify the limitations of the definition of consent in this document, but removing it completely would mean virtually no large operators would ever be even minimally compliant…..
>> 
>> 
>>> 
>>> Section 6.1.1: "Make an explicit statement that IP addresses are treated as
>>> PII." PII is a bit of a jurisdiction-specific term. I would recommend using the
>>> definition of personal data from RFC 6973.
>> 
>> Ack. 
>> 
>>> 
>>> Section 6.2: This section should be an appendix.
>> 
>> That’s fine. 
>> 
>>> 
>>> Section A.2: I don't understand why the reference to Section 8 of RFC 8484
>>> isn't just in the bulleted list with all the other documents, and why there is
>>> a generic note included with it when the specific privacy implications are more
>>> completely discussed in the referenced section of RFC 8484 (just like with the
>>> other documents in the list).
>> 
>> I think that text came in before RFC8484 was published and section 8 was quite limited, happy to convert to a bullet point.
>> 
>> Best regards
>> 
>> Sara. 
>> 
>