Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification
"Winfield, Alister" <Alister.Winfield@sky.uk> Tue, 08 September 2020 22:05 UTC
Return-Path: <Alister.Winfield@sky.uk>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F1D3A152D for <dns-privacy@ietfa.amsl.com>; Tue, 8 Sep 2020 15:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk
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 Sov2-P7IGtxs for <dns-privacy@ietfa.amsl.com>; Tue, 8 Sep 2020 15:05:05 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60088.outbound.protection.outlook.com [40.107.6.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FFB3A1532 for <dns-privacy@ietf.org>; Tue, 8 Sep 2020 15:05:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EYGzIsy0QUo7+VyXyUGBmsc5Co1a+b4yk0dWz46o/dCEwb1aVvZXL6VUivwCvU3V7SPCJSCF3kQx9qQ6fwmZhl4Yafc9XZeGYcgdDGyvFHCPDZWhCwBug+qHCLizYclGLUVp69dlXeLArkq8ND8RfiB4RUcyz+YI+FaW+QeOym5elczCE4PuXyn+aK7oFy5AiRsWTNC3A7Dr+n/LjmEbqONtohPexGz41xRCKw+n2ZUzK4hMYlz0Yp9dcgDXRSq0rp9aIoOjkkAQwl8GatvZZEkNhwyRK8p85or+DdVf1bhETZgxZif5TtLcLUlFlT9GDQENPkJSknGcSgYHz+LyNg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZuI6/54AQ2seQoWYcRxzg9RZOVKeQ9cRO2GfBJDxMGg=; b=fC7u0r7E6N3DfJpmqeUncEd55+UhiBpHvO6kjeIc6XLZ3XZvc79Zcn45FUcz3O+7/4kjvrgQmDx5mAsHtaMUhhLlzbnYRdQXAYWtWjaDxBxDNWdZhd3vi7j9PBVr4UiPy+aDIPPbSZqJJr/l3I0nTXkxpWEevyqTLMPnnzDOLtz5meuXyUgYtiI+mYnmSqyteyjVMYAmdqSAviDQgNA2IEvpk4GqyesXKH7QBp8VgSqmsOf0rNVX8woCKPgMj4ZXkFlQMgx8QwbK9yg1fvJRGrORoBRbtQmN4ILr4zH+tq1KdJQpntWQ/6Tzd8evAmHlHtmCofZ9/CkzNjn1RutZ4w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZuI6/54AQ2seQoWYcRxzg9RZOVKeQ9cRO2GfBJDxMGg=; b=itBHsFu0BBk6OQIVkVIqKCO3yszYrQZs9qCA+bUilsHF7M2cUZLXsAqLnsRWbfadLYOkLyARU4cCV1YeehSJXSF+nAd3wwf6UttblYrXURFosUx6phtny8RjCpWpVdU+ZHBa28B6+DxntohCxaNKwp9jGynTkUFmfIQXKK0HK7E=
Received: from VI1PR06MB4112.eurprd06.prod.outlook.com (2603:10a6:802:69::19) by VI1PR06MB6831.eurprd06.prod.outlook.com (2603:10a6:800:181::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.17; Tue, 8 Sep 2020 22:05:02 +0000
Received: from VI1PR06MB4112.eurprd06.prod.outlook.com ([fe80::bcec:b291:3e93:bdde]) by VI1PR06MB4112.eurprd06.prod.outlook.com ([fe80::bcec:b291:3e93:bdde%3]) with mapi id 15.20.3348.019; Tue, 8 Sep 2020 22:05:02 +0000
From: "Winfield, Alister" <Alister.Winfield@sky.uk>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, Neil Cook <neil.cook@noware.co.uk>
CC: DNS Privacy Working Group <dns-privacy@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] Review request: draft-btw-dprive-rfc8484-clarification
Thread-Index: AQHWfUlyio67rFWgc0qxS81N2TvuE6leqzsAgAA2WYCAAA6AgIAAQqkAgAA7pYA=
Date: Tue, 08 Sep 2020 22:05:01 +0000
Message-ID: <3A9BCDDD-883D-470E-A547-79839149F8EE@sky.uk>
References: <6e071da2-4281-d525-03ba-4d6dfc843a76@innovationslab.net> <CAHbrMsB7T+5Y=2n4LfcXwyAZQSnK4x72R44_2mCDsLhh_zD9Vw@mail.gmail.com> <8C6ABDA8-9A0E-44BB-AE23-43F97AF29730@noware.co.uk> <CAHbrMsD2y0o+uV9eiAb32_=6ZYwAUoS_zM5+T97SxnHzxB05bQ@mail.gmail.com> <0799B139-E353-4EC7-9340-87CE00C465AA@noware.co.uk> <CAHbrMsC=kOYUL_Ei1uSnWJ3hGxu=7c10eRofXJ=w5sQzcbu6mA@mail.gmail.com>
In-Reply-To: <CAHbrMsC=kOYUL_Ei1uSnWJ3hGxu=7c10eRofXJ=w5sQzcbu6mA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.40.20081000
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=sky.uk;
x-originating-ip: [2a02:c7f:700c:9b00:81d3:ade7:28bd:c1d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d8b1552a-145f-4b0c-8586-08d854433c45
x-ms-traffictypediagnostic: VI1PR06MB6831:
x-microsoft-antispam-prvs: <VI1PR06MB6831B28CEDE947483261694FE3290@VI1PR06MB6831.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: s1IAVhKbKsnekpZLWdABELp3GxLUDPjO4BdQq5MrXTbVFiUVuUtjyRybWHmNi6fNhk6hTM66jh/Rkb6/1xY9CUZmZx0OhJAyhNpuILNvQ2OrEffn9otZ3VPLmpmBrsZPspg8VRolT5RHdN+qzTbzoyPeoyxJIipaqvvsMW/l4SbZF2lZHrG+/r6uwlVQbIFOhnkom0GLea2aFY8aN8jfK4u1Z4a0tvUHN6RGvME2yulWrlVOGvewef1+C6ACeGPneyD72WRSPYh/ZRr8jb/KC5UxptUwkGEjsea6Us4ToxCg6u1vVdrIeV4S/PbbLmJ4T/faikOp7cGse1I5pT6lLw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR06MB4112.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(376002)(366004)(136003)(2616005)(110136005)(76116006)(66446008)(64756008)(91956017)(66574015)(5660300002)(478600001)(6486002)(71200400001)(186003)(4326008)(83380400001)(86362001)(8676002)(6512007)(66556008)(66476007)(33656002)(2906002)(6506007)(36756003)(66946007)(316002)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: IX7dh+MijydJsCJA7qc6HTbapqfdSqyV7aVr1sAc8tSzRUIE0plKXM6NyTUrdyprplqMsHnhY69hf8M6ss5ADf/xAxT+E4h/07+ku39l7zohuMQDYm1o7Xpgaw257cm86lDymYV4qcbxiRMqjlOS1tsv/+NMcjetNtQIHxVh2QixcBu/VGtCND5QzUSkuCwW+YGBbuSq/PBAT7ANbnJDBkTauTG2z9R2bykJzJOWyhOaSj2AI5WBdzwDoHTatnp9fuFebuhLpH2xFYWDPm0ZszrjQ/7msFXdkLASPCjkTFx18I6Z4NI8Rs1zpU/0HGsuRysDbw9ENnqolNqHgwywvVgnIX7wr/gzlKsmjVGjuW5RYcDQ5SxJCwT4cpkZcIcmv3FyDVvw7RT3vllKi3xzVXEwN4mb/VbGkJocJ/rYT8YWvZpXm0EtsxBZdCYFJsZMkjxFrchE0S5R9IhiaHNn9+rUQNXjPtbw+EjSSpWmZI+9mDvW+u5krlFaGAQmdvw8qzwbtwHI/r9MvnGde6amU5KZ2InHsNjHuHGkgn3eCZk/hc4sFYkQVHGlkBcrwC3cTQGKJ9U9+Q0MaKQsSsazMzAkVMaqRxbQBQX5PUbO7hhOQgbdaa0y1xTwrp9gsiP/cGoVApHq44BSdldGjbgNAvkUJzPLB/xKRExZVHFZRzihaHHfH0vsnVW4uQv6IFzW1JmxN68uJOJ2A8CLRIzFVA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_3A9BCDDD883D470EA54779839149F8EEskyuk_"
MIME-Version: 1.0
X-OriginatorOrg: sky.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR06MB4112.eurprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d8b1552a-145f-4b0c-8586-08d854433c45
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2020 22:05:02.1767 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GsQ0kq2KCtAI03Y0E7Ho1ym0SR+XhZ5z0TIyIHq1EXmcX4QBVsS/UJAAjoUH63iHk4z8ON3lTJGMAu4lasduKw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB6831
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/CJFSrnzB5_NDj_t3ZA3rdOFdXCY>
Subject: Re: [dns-privacy] [EXTERNAL] Re: Review request: draft-btw-dprive-rfc8484-clarification
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 22:05:08 -0000
That's an interesting use case, and I think it deserves more exposition. To me, it raises questions like * How did the client get configured to use the specified URI template in the first place? Hopefully some process defined by the working group but right now perhaps it’s from an auto-upgrade list in the client. * Why should the client use the CPE resolver instead of the central resolver, if they are administered by the same entity? The idea would be that some process as yet undefined gives the URI template to the client but assuming we want to be able to change the template to support differential services possibly changing with time of day eg (malware filtering, no filtering, security monitored etc) plus… 1. First mile latency often accounts for >90% of total latency with many home connections so even with a slow CPE cache its faster than going to a central service. 2. DoH creates a large connection count issue which you can throw compute and other hardware at to solve but its far easier to reduce it where possible eg reduce the many clients to 1 connection from each CPE to the DoH service. Far easier to scale. To give an idea there is often >10 devices per network service if each connects once you have a problem if it’s actually ~5 clients per device then we have to handle x50 connections. A reasonable sized ISP might be worried about supporting 100,000,000’s of stateful connections instead of 1,000,000’s of nearly stateless requests. (likely overestimating but it’s not hard to get to huge numbers if lots of people, devices and clients use DoH) 3. If the customer wants it, the CPE resolver can chose different settings on a per-device basis at the CPE. Yes you can configure different URLs in the clients but that’s hard to get customers to do right. Especially if you have to do it to each application separately. 4. Caching at the CPE reduces upstream resolver load by quite a lot more than you might imagine not actually a big problem but it’s nice to avoid adding compute if there is a cheaper solution trivially available. * How does the server know which CPE to redirect the client to? I’m are assuming here that this is an ISP running both elements so knowing how to map the incoming IP to the name its currently using / was told to use is relatively trivial. * What are the trust properties of a certificate stored on the CPE? You got me ! This is the one thing that has me staring hard at a sheet of paper full of crossed out ideas. One mistake and you might as well run over an unencrypted connection. Getting a signed certificate is easy. Ensuring no-one connected to the CPE can’t get a certificate for the same name is somewhat of a challenge. Avoiding storing such a cert and key on the flash is possible with some provisioning action at connection time. Alister. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
- [dns-privacy] Review request: draft-btw-dprive-rf… Brian Haberman
- Re: [dns-privacy] Review request: draft-btw-dpriv… Ben Schwartz
- Re: [dns-privacy] Review request: draft-btw-dpriv… Martin Thomson
- Re: [dns-privacy] Review request: draft-btw-dpriv… Neil Cook
- Re: [dns-privacy] Review request: draft-btw-dpriv… Neil Cook
- Re: [dns-privacy] Review request: draft-btw-dpriv… Ben Schwartz
- Re: [dns-privacy] Review request: draft-btw-dpriv… Neil Cook
- Re: [dns-privacy] Review request: draft-btw-dpriv… Ben Schwartz
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Winfield, Alister
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Ben Schwartz
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Winfield, Alister
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Neil Cook
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Ben Schwartz
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Neil Cook
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Konda, Tirumaleswar Reddy
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Rob Sayre
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Ben Schwartz
- Re: [dns-privacy] [EXTERNAL] Re: Review request: … Konda, Tirumaleswar Reddy