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

Ólafur Guðmundsson <olafur@cloudflare.com> Wed, 31 July 2019 20:07 UTC

Return-Path: <olafur@cloudflare.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 BAC91120077 for <add@ietfa.amsl.com>; Wed, 31 Jul 2019 13:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.756
X-Spam-Level:
X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 JKUvsfBGKnzL for <add@ietfa.amsl.com>; Wed, 31 Jul 2019 13:07:30 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 2AE5512004F for <add@ietf.org>; Wed, 31 Jul 2019 13:07:30 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id w79so51768545oif.10 for <add@ietf.org>; Wed, 31 Jul 2019 13:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UJP49z3o7RCkCWskrB7KiRxPZoBGXWwUKtS711Gq79c=; b=bqa0nDZvpC2/aFIXePaotXRL8vjh9I1w9Ling+B3+jpw/f4N8aYjOoJMQt+sFKz+Dt C0hoSA15WjvzjXHzQweS/6JzAAETrUnssLDVu8UfhJIyGYEW4pyJ2FgBSlRqZBtyJRhv rIO+E+0eBcZJARl16SLYUJ8WlSL8hx0RupR/Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UJP49z3o7RCkCWskrB7KiRxPZoBGXWwUKtS711Gq79c=; b=RPHGoAj/Wzq++ANTLByT83RmtknZ2VDwtHcBtwMIl+oZNGUNHlocrPETkAKI5e9SfW 4DTiLd/b5gBESp1uBPmPvxvICM1IK3VJJdMOqVNHe+kuLYa8KhjMnKLDnReqntnqMu1s Nm76FGKddNUhsYA/1JTdaS7o5sJPagjPmaNIJPkQrpZBRnZsV5Sd+HM0mY+uJbYTZ0J+ OJxISZc0EbqrtC/Z9vv/9bMmxzfyyDJH1SnrKUi2cVzZRWmmrd1y52aZnZAw11tBoHh8 SEFqKucHpW22bAny9Rqz/6uHQVS3/qgEkS0YJ55jXopTUuiyNez1al2T42PwpW2pNkmo Pl+A==
X-Gm-Message-State: APjAAAWcuVqehlPWBWp9wsnzv+S70FlSKAGX9/y5JrEznx/fV31Zvcv+ YhTPKq2b6XaZfGLb1CgHbI1hf8km7hbD8kbk5g5GRA==
X-Google-Smtp-Source: APXvYqxN1tZ/pBek6dJVmi3ORGe9rgfgTF/zGxy8yKT5NEih2hf07G9Q7McZ/9puVutn0cZYxhshPIB9+iikkyoxDnA=
X-Received: by 2002:a05:6808:3c5:: with SMTP id o5mr60102141oie.102.1564603649143; Wed, 31 Jul 2019 13:07:29 -0700 (PDT)
MIME-Version: 1.0
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> <d653d422-4a71-9fab-fd2e-b8ddaa476f91@nostrum.com> <488E2CE0-73D5-4B9E-A5AD-28FDCB95ED2A@cable.comcast.com>
In-Reply-To: <488E2CE0-73D5-4B9E-A5AD-28FDCB95ED2A@cable.comcast.com>
From: Ólafur Guðmundsson <olafur@cloudflare.com>
Date: Wed, 31 Jul 2019 16:07:17 -0400
Message-ID: <CAN6NTqyAzZY5TG8Y7ks0zEMdVuE=+m1JC0n3Dn5_1c6EKgBwwA@mail.gmail.com>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Cc: Adam Roach <adam@nostrum.com>, "add@ietf.org" <add@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b8f08c058effac62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/PGcddpnhpikcUA-_UVlG6Dg_Yzc>
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: Wed, 31 Jul 2019 20:07:35 -0000

Jason,

On Tue, Jul 30, 2019 at 5:49 PM Livingood, Jason <
Jason_Livingood@comcast.com> wrote:

> On 7/25/19, 10:12 AM, "Add on behalf of Adam Roach" <add-bounces@ietf.org
> on behalf of adam@nostrum.com> wrote:
> > 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/
>
> [JL] This speaks to the DNS query/response. But with DoH, this is
> contained inside of an HTTP envelope, so to speak, which has much more rich
> tracking - noted at https://www.cloudflare.com/privacypolicy/ under
> website visitors (which I presume applies to all HTTP transactions). So the
> confluence of DNS and HTTP here seems interesting to better understand and
> document as TRR-style policies evolve. Since there is an HTTP server
> involved in DoH, presumably all the normal HTTP log items are seen &
> processed and can be logged, like user agent, cookies, and so on.
>

Cloudflare modified the HTTPS processing for DoH requests, we did this for
privacy, efficiency and speed reasons.
The overwriting goal was to be compliant with the our public policies and
commitments.
Anything that matches https://tools.ietf.org/html/rfc8484#section-4.1
definition
of DoH request is NOT logged by the HTTPS service, we will only respond to
DoH requests on a defined list of DoH service names/addresses.

Our DoH module only counts connections, no logging of content ( mainly to
verify we do not drop anything internally)
The DNS  resolver system is the only one that writes to the resolver logs,
it is unaware of any user agent and other HTTP things,

There is no setting or reading of cookies from our servers (you can confirm
this by doing a request on you own), like

curl --verbose -H 'accept: application/dns-json' '
https://cloudflare-dns.com/dns-query?name=comcast.com&type=AAAA'


> [JL] In addition, I suspect a concern (for the very high scale centralised
> DoH platforms) is not just the per-user privacy policy but also what
> aggregated business intelligence a global scale platform would be able to
> develop (e.g. of a population of 500M users, how many have queried for *.
> netflix.com in the past N hours, by country, ASN, user agent, etc.),
> relative to competitors or potential competitors. So I suspect these
> concerns may arise, at least for platforms of very high scale /
> penetration.
>
>
This is not unique to DoH in any way or shape!
This is common to all DNS queries and having access to query streams, so
every DNS provider should answer if they share any DNS query data and with
whom and for what purpose.
Anyone that has access to query stream from one of the top ISP's in a few
countries might have better view than large Public DNS Resolver.

Restating Cloudflare 1.1.1.1 data policy: Cloudflare will not share any
query data with anyone!! Per our agreement with Apnic; they have access to
subset Resolver of logs for the last 24 hours only data that arrived on the
1.x.x.1 addresses, they do not a have access to data sent by Firefox users
unless the user modified the URL to *"https://1.1.1.1/dns-query
<https://1.1.1.1/dns-query>".*
Cloudflare will not use the query data for anything other than to improve
the service. Cloudflare keeps traffic aggregations and may share those
publicly from time to time.

Cloudflare is fully compliant the policy that Firefox has published AND
they have NO access to query data
-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com