Re: [Add] Not looking at DNS privacy in isolation

Andrew Campling <andrew.campling@419.consulting> Mon, 02 December 2019 12:21 UTC

Return-Path: <andrew.campling@419.consulting>
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 0423112006B for <add@ietfa.amsl.com>; Mon, 2 Dec 2019 04:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 qBQWb6abd0ZC for <add@ietfa.amsl.com>; Mon, 2 Dec 2019 04:21:01 -0800 (PST)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100044.outbound.protection.outlook.com [40.107.10.44]) (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 9C591120018 for <add@ietf.org>; Mon, 2 Dec 2019 04:21:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oHoZdT2xW8RQbjO7/azSZ/eqriP/qRDhr91COzx/s9U5MuK7VLSr1HrZNvzy40Xu1YiQqd8fe+RXnC85V5uF3CkSgr/YeBA+8ZlE6yyv3opWSw11+mZRopkRieVQAx37SCjP+p5uG8S5WYDxF5fJXWzDYVLCS0L6YyS7xo/2jfRkF+5Gdr+FM0tHuMd4NpHY4t28biUV5mQzlsgJJkXzM4qfUQWELai6KCrFzPmJUPhfTNdrWIGBs+TmC015WBJMyDEhoYadGlR8rz/NEvO0hPNEYCA2iiK5CqDaAjKX3I0gRFoljZcKGnTE77J5GZquDEGFX037PKh7yVCYGsoeNw==
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=G/x+uf3AqKNbw9VGZx/4vGnabnkAdzeJfR75WWuykgw=; b=YVY6caEIS8KiK1ZxBggUegYnLRt3ISyPHGch5pqu+Bjdh2Dbl7vXsd5GuIJzJJh/JhaBgVvmggXRSiZX6pv43X5f8MFM7zOc6PBH1DEh28qNgx0818ud0mustZ2RnSRP09//u/cWBZZ/thUQnFVI86B5OBLhhP2ZwLzI9XqL33hW0FvQQBaMV/9JUyNVrjhm6BGpjWf0f7od1BtBN6X2WqvB+T1R+1Dwz4ramV3IdtCZXyXy7Xgb5mmjI3ihUugOGMPFKqNLjbmm04nWFGdshCwNPg2Jpem15ESnA2XFns4X3n+sRp0Sm9JPSIAdnsayrXMbw6URNxbgn3zUK6tlNg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G/x+uf3AqKNbw9VGZx/4vGnabnkAdzeJfR75WWuykgw=; b=O8ZVg4yNutANUQp6HJEyS4NiSzKHhIv3/4j1KCvJ1K1AMGhfEY1XhEbWUiJzkrVRZ5LdqsstEBmLsPnzKrJdkuyRInvMfzawt+gKB+brX1CkJYtqOqxZUg/sfriRDBekkxEDjTU09DARY5e0M7Z3/DEWm5774lAbYZ03pZPd3Ok=
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1296.GBRP265.PROD.OUTLOOK.COM (20.176.143.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.20; Mon, 2 Dec 2019 12:20:58 +0000
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::7d46:b916:32e9:1d73]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::7d46:b916:32e9:1d73%7]) with mapi id 15.20.2495.014; Mon, 2 Dec 2019 12:20:58 +0000
From: Andrew Campling <andrew.campling@419.consulting>
To: Tommy Pauly <tpauly@apple.com>, "Livingood, Jason" <Jason_Livingood@comcast.com>
CC: Patrick McManus <mcmanus@ducksong.com>, "add@ietf.org" <add@ietf.org>, Christian Huitema <huitema@huitema.net>
Thread-Topic: [Add] Not looking at DNS privacy in isolation
Thread-Index: AQHVpu+mgv9dyH0LKkS1489Sd57mCKemxNrw
Date: Mon, 02 Dec 2019 12:20:58 +0000
Message-ID: <LO2P265MB0573807295C7FEBA3C9BB8D1C2430@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
References: <2C53815C-D874-4299-A6AF-F433D063D061@cable.comcast.com> <4DC9ED82-111A-4157-B3B1-CCFDDD23CC01@apple.com>
In-Reply-To: <4DC9ED82-111A-4157-B3B1-CCFDDD23CC01@apple.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting;
x-originating-ip: [81.141.75.33]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cc1c8337-3392-42a5-da56-08d77722165c
x-ms-traffictypediagnostic: LO2P265MB1296:
x-microsoft-antispam-prvs: <LO2P265MB12969D52FCE7C7838B24958BC2430@LO2P265MB1296.GBRP265.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39830400003)(346002)(396003)(366004)(189003)(199004)(64756008)(66556008)(76116006)(66476007)(66946007)(256004)(71200400001)(71190400001)(66574012)(14454004)(52536014)(6436002)(99286004)(3846002)(11346002)(66066001)(4744005)(53546011)(14444005)(86362001)(6506007)(102836004)(2906002)(6246003)(66446008)(33656002)(316002)(76176011)(229853002)(6116002)(5660300002)(966005)(7696005)(4326008)(110136005)(54906003)(26005)(790700001)(7736002)(44832011)(55016002)(236005)(81156014)(81166006)(9686003)(54896002)(186003)(6306002)(8676002)(74316002)(446003)(25786009)(8936002)(606006)(508600001)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1296; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kzKLY0rejJxcpVrex/ghMF2aMO2fd0dBATiED3dOkKMEd4jK0LJ6ptjLvpSwyzqqIyiLfzEXn+vdVTmN/tD3KmdYZlc9p6hswuTGVrBwrCCHqHWwYg7rMiphw8yXI/lVqkxhIVhm2fBL5JrNEmFghd9FIEKofpZkbAQpBNVPusGAgoKE5omND95Qz/cYwAAWtLE75eMBiXVrTu8vG9Mp3fDt66TU6DS3ry7+I8DUtckRR4Wzq0c5YTLp2aorqIKn/FJLFLTPhtUkLEzjjG8HBsxf2URuLM5k9TZR0rzixiTxN5bX4e7xgoK8fKfmWfU3xkhxss1fK7//WyTA6foK6wr+6yErlsD75Ei3qYxdCvtFn2HwqpgYV9hCYqbuGuGgv+tB9fd7KAwv0DBnVW+NHIf3wqP3YSn6+coXXa1zNB0L5miK2KKbn409jnrj8D3UgMoiwIQvb3mACo4UOY3Ix3pbglRnAP4BwZi86XjNRnE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573807295C7FEBA3C9BB8D1C2430LO2P265MB0573GBRP_"
MIME-Version: 1.0
X-OriginatorOrg: 419.consulting
X-MS-Exchange-CrossTenant-Network-Message-Id: cc1c8337-3392-42a5-da56-08d77722165c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2019 12:20:58.3632 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pBzJC4aPKcRvudsg0h9cMgn6bS7RDiS8Zb4iYNgEPzsXVVDNknh4fE6UmLPU31v0e5ZJjTxKSHXdwcdlSsnu9wrmw+avyeHWVoTE2BHbleQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1296
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/7MFHTdh6mxKUQ7N90BzATlAfh8I>
Subject: Re: [Add] Not looking at DNS privacy in isolation
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: Mon, 02 Dec 2019 12:21:03 -0000

On Nov 29, 2019, at 18:19, Tommy Pauly <tpauly@apple.com> wrote:

> Once the contents of queries and SNI values are encrypted, the number of entities along a path that can easily correlate
> cleartext names with client identifiers is reduced.

True, however the counter to this is that, if centralisation of DNS occurs (which I acknowledge is not a necessary result of encrypted DNS but could be, based on some early implementations), then the risks of the data being compromised increase, as outlined in Jari Arkko’s recent paper.  See https://datatracker.ietf.org/doc/draft-arkko-arch-infrastructure-centralisation/  - “Where such centralised points are created, they will eventually fail, or they will be misused through surveillance or legal actions regardless of the best efforts of the Internet community.  The best defense to data leak is to avoid creating that data store to begin with.”

Andrew