Re: [Add] ECS privacy concerns, alternatives?

Joe Abley <jabley@hopcount.ca> Wed, 17 April 2019 18:35 UTC

Return-Path: <jabley@hopcount.ca>
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 5D4C3120292 for <add@ietfa.amsl.com>; Wed, 17 Apr 2019 11:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 cmDCs8igveZL for <add@ietfa.amsl.com>; Wed, 17 Apr 2019 11:35:04 -0700 (PDT)
Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 9C2231201BA for <add@ietf.org>; Wed, 17 Apr 2019 11:35:04 -0700 (PDT)
Received: by mail-it1-x131.google.com with SMTP id f22so6038475ita.3 for <add@ietf.org>; Wed, 17 Apr 2019 11:35:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gomFV1I2InJcFJhTgRgN3HXxQmVyUH6zxm3WFvwwyVg=; b=EjReNDy0dyKLGFZyWQRP46f+0v/yfx+Lo7O1vIeryoaUgYsEyaMbpXniTrdLVD79SD buIoWMYaRx8HTxzVcalsBYRfnpqtOqACwsvoZhhI2B/ntunVRAEHcDbnU9ApDilTkMXH r7CjkUxig2rM5opSXHOn9acApnEFKBTu7MtaA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gomFV1I2InJcFJhTgRgN3HXxQmVyUH6zxm3WFvwwyVg=; b=qSUB6h3XO9ybnIRU5m3aRRgf/eu9reJNzAaU/DtKF4DIPAm6+X+XLAA8bq+wm0fpUx FCbaKv/LmnYJ99zt7dHLOKjb/zhDCEhK7SmOVxo0u8NP9Fw0V0ikCFfnIcbqXAGYPFS4 7S0pj2erdM5rmDjxtMoW2OI2BV9of6BPC6Zb4PDDRA2XmVWzzX2R/hMlr9NRdg8XWm+d KxCjGjX+hZ1e7Qr0EdSvCUOUpxcNr1J4VkdPXMFB1ziUct4Cd8Id8zAg4+YneSbwMyV5 5za+X9GhiQw5za0xA2JLtpinBpV9naAk/fRs46APvjL4FSYOQd19LkznLk/ZXWDHFm5w KCeA==
X-Gm-Message-State: APjAAAW1+pPf2qNVxIsvxdPQINHKmxvMuMOi0+NFX+xhWisj3OkYY76o qIN7srEeJ/JyRPPQzxl6uXrKQw==
X-Google-Smtp-Source: APXvYqz6n9er+b7Sy5fWIvG+GfSrOCs7SRFfW+tFPl62hP5XNrgL0gc/+WUbULtKXHDQXuN+bts3AQ==
X-Received: by 2002:a02:7706:: with SMTP id g6mr1651308jac.118.1555526103673; Wed, 17 Apr 2019 11:35:03 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e786:128f:2140:512e:47b0:a53d? ([2607:f2c0:e786:128f:2140:512e:47b0:a53d]) by smtp.gmail.com with ESMTPSA id m6sm20618453ioj.36.2019.04.17.11.35.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 11:35:02 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <E2CD69F8-1B6F-493F-B18E-918B4855E075@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_94B19AD4-AA91-4B9B-BD48-3A966AD26619"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 17 Apr 2019 14:35:00 -0400
In-Reply-To: <CAH1iCiqMOJ0M1EiGKORf2VKysFEtWV69tP2G+W6M9CEPzf4QWA@mail.gmail.com>
Cc: Erik Nygren <erik+ietf@nygren.org>, "Livingood, Jason" <Jason_Livingood@comcast.com>, "add@ietf.org" <add@ietf.org>, "Plonka, David" <dplonka@akamai.com>, Peter Saint-Andre <stpeter@mozilla.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
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> <CAKC-DJgmb1J281Z2j4q1NbBgf+S5PmvkJfXPDkhfX_sT6cn_PA@mail.gmail.com> <CAH1iCiqMOJ0M1EiGKORf2VKysFEtWV69tP2G+W6M9CEPzf4QWA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/NBeuKPVAs2AqpeNnAg4QxKIfcCg>
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 18:35:06 -0000

On 17 Apr 2019, at 14:16, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

> Let's consider what the situation is, for authority servers.
> 
> Some (not all, not none) are CDNs. Some (not all, not none) are not doing ECS at all. Some (not all, not none) are doing ECS, but only using "vanilla" ECS functionality, via third-party IP->GEO databases/services.
> 
> The potential trade-off(s), as I see them, are:

So, to briefly join the threads just as further illustration to what I'm talking about, what you're doing here looks a lot like trying to engineer a solution for people you don't know based on requirements you're guessing at. This seems unlikely to converge on anything useful.

Being able to separate away 99% of the resolution problem in the lifetime of a session ("established phase") into something that can be said not to have any privacy or access control concerns beyond those that already exist in the service being used means that all of the traffic engineering required there can continue to be done behind the curtain, engineered with a full serving of commercial advantage and richly flavoured with special secret sauce. I'm not saying this is without complication or is something that exists today, far from it: but it at least puts the design and implementation in the hands of the service architects who know what they need and, crucially, the details don't necessarily need wide exposure and standardisation.

If there's to be an impact on performance from privacy, e.g. from a less sophisticated (even empty) set of available mechanisms available to do traffic steering at response time, it seems like it'd be really nice for it to be brief (e.g., "initialisation phase").


Joe