Re: [Add] meeting hum: should the IETF take up this work?

Adam Roach <adam@nostrum.com> Thu, 25 July 2019 14:12 UTC

Return-Path: <adam@nostrum.com>
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 012C012023B for <add@ietfa.amsl.com>; Thu, 25 Jul 2019 07:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, 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 Z3uXdcxF8l9y for <add@ietfa.amsl.com>; Thu, 25 Jul 2019 07:12:07 -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 C874D12022E for <add@ietf.org>; Thu, 25 Jul 2019 07:12:00 -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 x6PEBrbg051059 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 Jul 2019 09:11:55 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1564063918; bh=T+TqmWIFNq/Oe0yp6wthCJUgjGJBYiSK5EUDyHeFnfA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=CsfLYQGWWDatHlXJZGmfJgDgbDW0j7RIvNT3awz8EOHZWrbJOPon33DCGVGC4ZMkz wPDH8S0XQfV0tTpdBMwaFAeQxUUQtxcYJGzaTkEUjrjnGNN8pdHpHa7fHQ1sHh089i C2Zh+P6REMLAnfL3eGoBM4Zl2C91F2q8UHg/7Qlk=
X-Authentication-Warning: raven.nostrum.com: Host [196.52.21.215] claimed to be Orochi.local
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>
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com> <AAEA003A-58DB-4FEE-81B2-BBFE9BBB2A37@rfc1035.com> <CAChr6SwA+HM4u5-xpUxQXPH8G8k7sfm6AETJJ019HE=bsq+OXA@mail.gmail.com> <8F094057-DFBC-4732-9DA4-BE46E7914C8A@rfc1035.com> <20190724165951.GB29051@laperouse.bortzmeyer.org> <821B448B-F7EA-46A5-837D-DA0E8C60643A@open-xchange.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <d653d422-4a71-9fab-fd2e-b8ddaa476f91@nostrum.com>
Date: Thu, 25 Jul 2019 10:11:52 -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: <821B448B-F7EA-46A5-837D-DA0E8C60643A@open-xchange.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/YtopjEzBjqZuU6uY3QLkJJxjW74>
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 <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 14:12:09 -0000

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