Re: [Add] ECS privacy concerns, alternatives?
Erik Nygren <erik+ietf@nygren.org> Wed, 17 April 2019 16:04 UTC
Return-Path: <nygren@gmail.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 83A29120458 for <add@ietfa.amsl.com>; Wed, 17 Apr 2019 09:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 FpzbX_S_j2rb for <add@ietfa.amsl.com>; Wed, 17 Apr 2019 09:04:27 -0700 (PDT)
Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 3AD5112044D for <add@ietf.org>; Wed, 17 Apr 2019 09:04:27 -0700 (PDT)
Received: by mail-wm1-f46.google.com with SMTP id z24so4265226wmi.5 for <add@ietf.org>; Wed, 17 Apr 2019 09:04:27 -0700 (PDT)
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=0PM0EhlTay0qsLSntqZwXGIujD9cEMN1GXleIRTsuUk=; b=D6mnUYhW+BRtv3K3/Vvtd1ZHkd2839NRcC0RzN5uqzzJGAQ2+H2FhD7mk2J+873w3t 46BWyZqKplc9QmOWXM2lWd/LS0nrseorxF0Y0Nej5q6XnYW17tgts0/GNdiIWtMjd/zb zqizaSp4UgcqMb8L8a7U+Lkj4WeJQEhvRw2DWYKPuyjryEND7om1ivohcbMXAvk44Yc7 Y/x9kARQIn+wkfh8yeyIIPE37c/461WP+WtpPsUu1ZbkPc8ORqZz1KG5zpxv/SiJTCoS qmT14G/db/875LIEd5+XOXmEo3HaghKmeo+prSMKsiU2SsasfmOTWX5Am+1d8qca9dvE yLRg==
X-Gm-Message-State: APjAAAVlRDLols8MayQA8ovSZkyEI4LX8jt4nrmYWjeS7VbowZ0Ji/ol W7CkJrE1Hw3uB+5cWvu9H8XoG9hObaE8Cv64dBk=
X-Google-Smtp-Source: APXvYqxNW4/1InrH3ZuvR7h64YkmnYWEUucg58Q4trwWqKzo/XQMieDfogzzkAhmMIFspT2YLrysAMpofoSirzTWf6E=
X-Received: by 2002:a7b:c1cf:: with SMTP id a15mr364798wmj.44.1555517065263; Wed, 17 Apr 2019 09:04:25 -0700 (PDT)
MIME-Version: 1.0
References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <b64761dc-dfab-e4e1-4bfb-82d607efa590@riseup.net> <alpine.LRH.2.21.1904101324530.9940@bofh.nohats.ca> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <af5f5c76-0095-65a0-39d1-d29d4bb0e906@mozilla.com> <ybl36mn8b54.fsf@w7.hardakers.net> <f9d0cd98-db0c-7f42-d351-d9a5002c4765@mozilla.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> <CAH1iCiqPqWCEmT0DSyzu-DRtna_p1SZXuiK15HHyTrjnX1iUaA@mail.gmail.com>
In-Reply-To: <CAH1iCiqPqWCEmT0DSyzu-DRtna_p1SZXuiK15HHyTrjnX1iUaA@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Wed, 17 Apr 2019 09:04:13 -0700
Message-ID: <CAKC-DJgmb1J281Z2j4q1NbBgf+S5PmvkJfXPDkhfX_sT6cn_PA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>, "add@ietf.org" <add@ietf.org>, Peter Saint-Andre <stpeter@mozilla.com>, "Plonka, David" <dplonka@akamai.com>
Content-Type: multipart/alternative; boundary="0000000000001dff9a0586bc0a9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/mIUrHCl64Bz1QxqQ7RRatD5HM_k>
Subject: Re: [Add] ECS privacy concerns, alternatives?
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, 17 Apr 2019 16:04:29 -0000
On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote: > > > On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason < > Jason_Livingood@comcast.com> wrote: > >> And for ease of any replies, I have a separate question on CDN >> localization via ECS. The 6th privacy requirement suggests that ECS cannot >> be used unless there is encryption between the resolver and the >> authoritative server, presumably via DoT. This suggests that the privacy >> concern isn't that the network/geographic hint provided by ECS is >> problematic in and of itself, but that it should not be observable along >> the network path used in recursion. >> >> But if TRR-to-auth recursion is not available via DoT, I wonder what the >> recommended mechanism is for providing a more privacy-protective >> network-geographic hint to an authoritative server, in order for example >> for a CDN to dynamically respond with a localized response. Maybe something >> new needs to be standardized? What options do folks suggest? > > > That's a great question. Apologies in advance for always providing long > answers. :-) > > IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip. > > I may be oversimplifying the situation, but I believe the vast majority of > authority DNS services (or proxy services in front of those) structure > their internal representation of things as geo->answer mappings, and > generally have some flavor of ip->geo mapping on their front-end(s). > Unfortunately, Geo is only one of the dimensions used. At least some of the common and heavily used CDNs and other DNS-based routing services also need to use both ASN and in some cases the regional network location within the ASN. As an example, a CDN or other widely distributed service may have "on-net" deployments located deep within ISP regional networks. So it's not just a matter of "hand out the London cluster for UK clients". It's "hand out the right cluster in the UK for the client based on the POP for the ISP/network they are currently connected to, out of a set of well over a hundred distinct UK clusters." This level of locality can actually help privacy by reducing the number of hops and network/country borders that are crossed (and therefore reducing the chances that the service request flow traffic is crossing surveillance points). The purpose of doing this is for increasing user performance, but also avoiding congested interconnect points. Decreasing localization here would result in substantially more traffic crossing ISP backbone and interconnect links. Even for country-level, the validity of "geo" is a function of the country and works better in the US and Europe. In Asia and South America and other parts of the world there are many areas within countries (and also between ISPs). But the general point stands that the client IP is not what is needed here by authorities. Just enough information to know where the client is topologically within the network. DNS authorities would actually prefer to have the coarsest effective granularity here as it increases DNS cache hit rate. In IPv6 coarser information is easier to provide via ECS. For example, a /48 is generally fine as nothing finer-grained typically differentiates routing. IPv4 is much trickier due to fragmentation of the address space. What I'd suggest as an alternative instead is to look at a "kIP" approach. ie, to only send information via ECS at a granularity that "makes an individual appear indistinguishable amongst a set of [k] individuals". For some context, see a talk from maprg: https://www.ietf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv6-address-anonymization-03.pdf Specifying something for TRR-to-auth recursion like "When ECS is sent to authorities it should be at a k=100 aggregation (or coarser) level, unless over an encrypted channel" may provide the desired property? Having a revision or new version of ECS that makes this easier to accomplish might also be valuable. Since this is generally desirable for caching efficiency, I suspect that even once a recursive to authoritative encrypted channel is defined it will still be preferable to send these more aggregated ECS information. (Note that there may be IPR in the space around sending non-client-IP identifiers for ECS.) Also see for background a SIGCOMM 2015 paper from a few years back on ECS measurements from one CDN: https://www.akamai.com/de/de/multimedia/documents/technical-publication/end-user-mapping-next-generation-request-routing-for-content-delivery-technical-publication.pdf Erik
- [Add] Mozilla's DoH resolver policy Paul Hoffman
- Re: [Add] Mozilla's DoH resolver policy nusenu
- Re: [Add] Mozilla's DoH resolver policy Paul Wouters
- Re: [Add] Mozilla's DoH resolver policy Martin Thomson
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Valentin Gosu
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Jim Reid
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Manabu Sonoda
- Re: [Add] Mozilla's DoH resolver policy Valentin Gosu
- Re: [Add] Mozilla's DoH resolver policy Ray Bellis
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Daniel Stenberg
- Re: [Add] Mozilla's DoH resolver policy Paul Wouters
- Re: [Add] Mozilla's DoH resolver policy Vladimír Čunát
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Vladimír Čunát
- Re: [Add] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] Mozilla's DoH resolver policy nusenu
- Re: [Add] [Ext] Mozilla's DoH resolver policy Paul Hoffman
- Re: [Add] [Ext] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] [Ext] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] [Ext] Mozilla's DoH resolver policy Brian Dickson
- Re: [Add] [Ext] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Peter Saint-Andre
- Re: [Add] Mozilla's DoH resolver policy Ted Hardie
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Ted Hardie
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Christian Huitema
- Re: [Add] Mozilla's DoH resolver policy Mark Andrews
- Re: [Add] Mozilla's DoH resolver policy Wes Hardaker
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Vittorio Bertola
- Re: [Add] Mozilla's DoH resolver policy Livingood, Jason
- Re: [Add] Mozilla's DoH resolver policy Livingood, Jason
- Re: [Add] Mozilla's DoH resolver policy Salz, Rich
- Re: [Add] Mozilla's DoH resolver policy Ben Schwartz
- Re: [Add] Mozilla's DoH resolver policy Adam Roach
- [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Mark Delany
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Mark Delany
- Re: [Add] Mozilla's DoH resolver policy Christian Huitema
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] Mozilla's DoH resolver policy Geoff Huston
- Re: [Add] Mozilla's DoH resolver policy Ralf Weber
- Re: [Add] Mozilla's DoH resolver policy Paul Wouters
- Re: [Add] ECS privacy concerns, alternatives? Erik Nygren
- Re: [Add] ECS privacy concerns, alternatives? Joe Abley
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] ECS privacy concerns, alternatives? Joe Abley
- Re: [Add] ECS privacy concerns, alternatives? Paul Hoffman
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson
- Re: [Add] Mozilla's DoH resolver policy Hollenbeck, Scott
- Re: [Add] Mozilla's DoH resolver policy Adam Roach
- Re: [Add] ECS privacy concerns, alternatives? Puneet Sood
- Re: [Add] ECS privacy concerns, alternatives? Erik Kline
- Re: [Add] ECS privacy concerns, alternatives? Brian Dickson