Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1351201F2 for ; Thu, 25 Jul 2019 08:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 sY2m5wYch5r2 for ; Thu, 25 Jul 2019 08:32:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9BB96120265 for ; Thu, 25 Jul 2019 08:32:34 -0700 (PDT) Received: from Orochi.local ([196.52.21.215]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6PFWQK3064259 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Jul 2019 10:32:29 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1564068750; bh=xF7n+tIkAtRQbIsZQ443rHKC7Yrpqzjrs42umEBLhfE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=tl5TOTn+4e6hfzfJPKjo1hmEghLfSX+T4e8M4JhIJv3eNUc13+F6vulsu8R5DcSrj x0sgB3dslrj/h1MMV/P0Yz4+Dp/f93fLHAjMjvuwIkJIld4dg732PkOvxFXS8xy+6Y lIPgLSNq4xFstwpDqQJ9DCybb8WHMYw/Ghf89kZ4= X-Authentication-Warning: raven.nostrum.com: Host [196.52.21.215] claimed to be Orochi.local To: Andrew Campling Cc: "add@ietf.org" , "neil.cook@open-xchange.com" References: <8F094057-DFBC-4732-9DA4-BE46E7914C8A@rfc1035.com> <20190724165951.GB29051@laperouse.bortzmeyer.org> <821B448B-F7EA-46A5-837D-DA0E8C60643A@open-xchange.com> From: Adam Roach Message-ID: <64d4f80c-9d3c-278a-3629-2f5193303d83@nostrum.com> Date: Thu, 25 Jul 2019 11:32:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0767A5CF1582F17527B696C5" Content-Language: en-US Archived-At: Subject: Re: [Add] meeting hum: should the IETF take up this work? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 15:32:44 -0000 This is a multi-part message in MIME format. --------------0767A5CF1582F17527B696C5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit See my response to Vittorio, which I think addresses your points. /a On 7/25/19 11:19, Andrew Campling wrote: > *Adam* > You rightly mention the protections offered by the Cloudflare privacy > policy and Mozilla's contract with Cloudflare.  The topical reference > to Facebook should serve as a timely reminder about the growing > importance of privacy as well as a useful illustration that > well-intentioned privacy policies can often be by-passed or undermined. > Given your comment to Neil, I think that it would be incredibly > helpful to have your thoughts on the following points: > > * Will all resolvers accessible within Mozilla's TRR policy have a > contractual relationship with the company to provide this > additional layer of protection? > * In Europe, DNS constitutes personal data and therefore needs to be > processed in compliance with GDPR - I didn't notice a direct > reference to this in the privacy policies, apologies if I've > missed it; > * For non-US citizens "reasonably believed to be outside the US", > FISA Section 702 of course overrides the stated privacy policies > of both Mozilla and Cloudflare (this is _not_ a criticism, simply > a clarification), has global reach when combined with the Cloud Act. > > I think we should all bear in mind that DoH does of course have the > potential to provide a contiguous, device level fingerprint to the DoH > resolver, is a backward step for privacy in that regard vs both DoT > and DNS53.  In my view this does helpfully illustrate that encryption > and privacy are not synonymous – no doubt others will have their own > views. > *Andrew * > -----Original Message----- > From: Adam Roach > Sent: 25 July 2019 15:12 > To: Neil Cook ; Stephane > Bortzmeyer > Cc: Jim Reid ; add@ietf.org; Rob Sayre > Subject: Re: [Add] meeting hum: should the IETF take up this work? > On 7/25/19 03:57, Neil Cook wrote: > > But let’s say I decide to run my own non-public DoH  resolver on my > > network at home. Firefox won’t have it on their list of TRRs, and if > > as you suggest, the discovery drafts are pointless and so don’t > > proceed, no application will ever find out about it, unless I > > configure it manually on every single application and computer in my > > house (not even mentioning those IoT devices that I can’t configure). > > > > It is also possible that we end up with a large number of public DoH > > resolvers which mine your personal data for profit. Given the current > > business model of the internet that is entirely possible. > Since you mention Firefox's TRR list and then mention data mining > (with an implied connection), I'd like to point out yet again that one > of the key criteria for appearing on that list is an agreement to > treat resolution data according to a strict set of privacy-protecting > provisions. You can see, for example, Cloudflare's associated privacy > policy at > https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ > I'm going to pre-reply to a frequent response that the lack of direct > contractual relationship between users and Cloudflare is problematic. > Even if you don't trust Mozilla's contractual agreement with > Cloudflare to provide protection here, I would think that FTC v. > Facebook (2019) [1] should serve as a pretty vivid illustration of > what happens when a US company operates outside its published privacy > policy. > /a > ____ > [1] > https://www.ftc.gov/news-events/press-releases/2019/07/ftc-imposes-5-billion-penalty-sweeping-new-privacy-restrictions > --------------0767A5CF1582F17527B696C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
See my response to Vittorio, which I think addresses your points.

/a

On 7/25/19 11:19, Andrew Campling wrote:
Adam
You rightly mention the protections offered by the Cloudflare privacy policy and Mozilla's contract with Cloudflare.  The topical reference to Facebook should serve as a timely reminder about the growing importance of privacy as well as a useful illustration that well-intentioned privacy policies can often be by-passed or undermined. 
 
Given your comment to Neil, I think that it would be incredibly helpful to have your thoughts on the following points:
 
  • Will all resolvers accessible within Mozilla's TRR policy have a contractual relationship with the company to provide this additional layer of protection?
  • In Europe, DNS constitutes personal data and therefore needs to be processed in compliance with GDPR - I didn't notice a direct reference to this in the privacy policies, apologies if I've missed it; 
  • For non-US citizens "reasonably believed to be outside the US", FISA Section 702 of course overrides the stated privacy policies of both Mozilla and Cloudflare (this is not a criticism, simply a clarification), has global reach when combined with the Cloud Act.
    •
 
I think we should all bear in mind that DoH does of course have the potential to provide a contiguous, device level fingerprint to the DoH resolver, is a backward step for privacy in that regard vs both DoT and DNS53.  In my view this does helpfully illustrate that encryption and privacy are not synonymous – no doubt others will have their own views.   
 
 
Andrew
 
-----Original Message-----
From: Adam Roach <adam@nostrum.com>
Sent: 25 July 2019 15:12
To: Neil Cook <neil.cook=40open-xchange.com@dmarc.ietf.org>; Stephane Bortzmeyer <bortzmeyer@nic.fr>
Cc: Jim Reid <jim@rfc1035.com>; add@ietf.org; Rob Sayre <sayrer@gmail.com>
Subject: Re: [Add] meeting hum: should the IETF take up this work?
 
On 7/25/19 03:57, Neil Cook wrote:
> But let’s say I decide to run my own non-public DoH  resolver on my
> network at home. Firefox won’t have it on their list of TRRs, and if
> as you suggest, the discovery drafts are pointless and so don’t
> proceed, no application will ever find out about it, unless I
> configure it manually on every single application and computer in my
> house (not even mentioning those IoT devices that I can’t configure).
>
> It is also possible that we end up with a large number of public DoH
> resolvers which mine your personal data for profit. Given the current
> business model of the internet that is entirely possible.
 
 
Since you mention Firefox's TRR list and then mention data mining (with an implied connection), I'd like to point out yet again that one of the key criteria for appearing on that list is an agreement to treat resolution data according to a strict set of privacy-protecting provisions. You can see, for example, Cloudflare's associated privacy policy at https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/
 
I'm going to pre-reply to a frequent response that the lack of direct contractual relationship between users and Cloudflare is problematic.
Even if you don't trust Mozilla's contractual agreement with Cloudflare to provide protection here, I would think that FTC v. Facebook (2019) [1] should serve as a pretty vivid illustration of what happens when a US company operates outside its published privacy policy.
 
/a
 
____
[1]
 
 
 


--------------0767A5CF1582F17527B696C5--