From nobody Mon Apr 1 03:56:03 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89491200F4 for ; Mon, 1 Apr 2019 03:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 YL1Wx7dYJltC for ; Mon, 1 Apr 2019 03:56:00 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 7AF8C12001A for ; Mon, 1 Apr 2019 03:56:00 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x31Apawx002701; Mon, 1 Apr 2019 11:55:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=jtM47DpImWJY/vYXQIorpYhU1ukJ2ZwPekZiNk9biIw=; b=b126s+eeHc6zlziNbM4duI693JRISAWr8t43PKUZ9I1zorGmjanEhGJaYYIJqacF0rAl GvnixYGflSAxc89Q0/6iMA/z48jSbhadsKCyQ6Cv2uj9X5TpwP240AAvAwtNZxCyis1n njWj8etThxQO3gA7UevtWvBpajXYBo1QMW5u65N3SUl3yfO5iISLjmfS1Xx0zpvRsaWA PUlYhwJFSIcoo6Dn2sgrY137Hb4xbpjOzEW+LCsZi7z16rzUOlxUnafFl8NiUoKiShm0 Ussslox5oImOkTnEL8lmjKFNnEmER0cHHaDOizr8UJD0SBXy8/x7+DM6Z2RulixQgUix FQ== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2rj0kt7yy5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Apr 2019 11:55:30 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x31AlELm006480; Mon, 1 Apr 2019 06:55:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2rj3sx9un9-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Apr 2019 06:55:28 -0400 Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com (172.27.27.28) by USTX2EX-DAG3MB2.msg.corp.akamai.com (172.27.27.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 03:55:15 -0700 Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.27.28]) by USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.27.28]) with mapi id 15.00.1473.003; Mon, 1 Apr 2019 05:55:15 -0500 From: "Reed, Jon" To: Adam Roach , Paul Brears , "andrew.campling@bt.com" , "Alister.Winfield@sky.uk" , "john@johncarr.eu" , "mcmanus@ducksong.com" CC: "paul.hoffman@icann.org" , "doh@ietf.org" Thread-Topic: [Doh] [EXTERNAL] Re: DoH Thread-Index: AQHU5jBcBn/wQwg5BUOVVmuJRjhusKYnNycA Date: Mon, 1 Apr 2019 10:55:15 +0000 Message-ID: <01528060-1D57-4480-93EB-3A5406EE2164@akamai.com> References: <73a0935d-f80b-0e8d-eb89-cb35a473122c@nostrum.com> <826904ddc23941d5be4d8872c4f2737a@tpw09926dag11h.domain1.systemhost.net> <2af82a6d-6887-ae36-4527-47e476829345@nostrum.com> <9E29A232-BA75-478D-96BF-5D6164142BDD@sky.uk> <6bebaadff9b54dc1a906c237a756d476@tpw09926dag11h.domain1.systemhost.net> <62c8932a-34f6-e0be-99fe-0976a8b4d5f7@nostrum.com> In-Reply-To: <62c8932a-34f6-e0be-99fe-0976a8b4d5f7@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.137] Content-Type: text/plain; charset="utf-8" Content-ID: <6D9F229BE9E13C4B942693B6F2325F65@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-01_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904010074 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-01_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904010075 Archived-At: Subject: Re: [Doh] [EXTERNAL] Re: DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 10:56:02 -0000 T24gMy8yOS8xOSwgOTowNyBBTSwgIkFkYW0gUm9hY2giIDxhZGFtQG5vc3RydW0uY29tPiB3cm90 ZToNCg0KICAgIE9uIDMvMjkvMTkgMTI6NTQsIFBhdWwgQnJlYXJzIHdyb3RlOg0KICAgID4gSSB0 aGluayB0aGUga2V5IGRpZmZlcmVuY2UgaXMgdGhhdCBvbiBhIG5vcm1hbCBXaWRvd3MgUEMgeW91 4oCZZCBuZWVkIGRldmljZSBhZG1pbiBjcmVkZW50aWFscyB0byBjaGFuZ2UgRE5TIHByb3ZpZGVy Lg0KICAgIA0KICAgIA0KICAgIFRoaXMgYWdhaW4gY29uZmxhdGVzIHByb2R1Y3QgY29uY2VybnMg d2l0aCBwcm90b2NvbCBvbmVzLiBBcHBsaWNhdGlvbnMgDQogICAgaGF2ZSBhbHdheXMgaGFkIHRo ZSBhYmlsaXR5IHRvIGluY29ycG9yYXRlIHRoZWlyIG93biByZXNvbHZlciBsaWJyYXJ5IA0KICAg IGFuZCBjb25maWd1cmUgaXQgdG8gdXNlIHNlcnZlcnMgb3RoZXIgdGhhbiB0aG9zZSBwcm92aWRl ZCBieSB0aGUgDQogICAgb3BlcmF0aW5nIHN5c3RlbSAoY2YuIGMtYXJlcywgYWRucykuIFRoZSBj b25jZXJuIHlvdSBkZXNjcmliZSBpcyB0aGF0IA0KICAgIHNvbWUgcG9wdWxhciBhcHBsaWNhdGlv bnMgbWF5IGNob29zZSB0byBkbyBzby4NCiAgICANCkkgdGhpbmsgYXQgdGhpcyBwb2ludCwgaXQn cyBkaWZmaWN1bHQgdG8gc2VwYXJhdGUgdGhlIHByb3RvY29sIGZyb20gaXRzIHVzZSBieSBhcHBs aWNhdGlvbnMgX2FzIGl0IHBlcnRhaW5zIHRvIHRoZXNlIHNvcnRzIG9mIGRpc2N1c3Npb25zXy4g IEFzIGFuIGVuZ2luZWVyLCBJIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYW5kIEkgdGhpbmsg aXQncyBpbXBvcnRhbnQgdG8gY29udGludWUgdG8gY29udmV5IGl0LCBidXQgSSB0aGluayBmb3Ig bWFueSBwZW9wbGUsIERvSCBtYXkgYmUgZm9yZXZlciBjb25mbGF0ZWQgd2l0aCB0aGUgY29uY2Vw dCBvZiBhIGJyb3dzZXIgc2VsZWN0aW5nIGEgcmVjdXJzaXZlIGZvciB5b3UuICBJIHRoaW5rIGl0 J3MgZmFpciB0byBzYXkgdGhhdCB0aGUgZXhpc3RlbmNlIG9mIHRoZSBEb0ggcHJvdG9jb2wgaXRz ZWxmIG1ha2VzIGl0IG11Y2ggbXVjaCBlYXNpZXIgZm9yIGFwcGxpY2F0aW9ucyB0byBpbmNvcnBv cmF0ZSB0aGVpciBvd24gcmVzb2x2ZXIgbGlicmFyeSwgc2luY2UgbWFueSBlbnZpcm9ubWVudHMg cHJvdmlkZSBhbiBIVFRQUyBjbGllbnQgImZvciBmcmVlIi4gIChJbiBteSBleHBlcmllbmNlLCB3 aGVuIGFuIGFwcGxpY2F0aW9uIGNob29zZXMgdG8gdXNlIGFyZXMgb3IgYWRucywgaXQncyBiZWNh dXNlIHRoZSBhcHAgbmVlZHMgdGhlIGFzeW5jIGZ1bmN0aW9uYWxpdHksIGFzIG9wcG9zZWQgdG8g c2ltcGx5IHNlbGVjdGluZyBhbiBhbHRlcm5hdGUgcmVzb2x2ZXIgbGlicmFyeS4gIENlcnRhaW5s eSB0aGV5J3JlIGJvdGggbXVjaCBoYXJkZXIgdG8gaW50ZWdyYXRlIHRoYW4gc2ltcGx5IGlzc3Vp bmcgYSBHRVQgcmVxdWVzdC4pDQogDQpUbyBhdm9pZCByZS1oYXNoaW5nIGV2ZXJ5dGhpbmcgb24g eWV0IGFub3RoZXIgdGhyZWFkLCBhbmQgc3BlYWtpbmcgZm9yIG15c2VsZiBvbmx5LCBpdCBzb3Vu ZHMgbGlrZSB0aGUgYW5zd2VyIHRvIEpvaG4ncyBxdWVzdGlvbiBpczogIlllcywgdGhlcmUgaGFz IGJlZW4gY29uc2lkZXJhYmxlIGRpc2N1c3Npb24gaW4gdmFyaW91cyB3b3JraW5nIGdyb3VwcyBh Ym91dCB0aGUgaW1wYWN0IG9mIHdpZGVzcHJlYWQgZGVwbG95bWVudCBvZiBhcHBsaWNhdGlvbnMg dGhhdCBjaG9vc2UgYnlwYXNzIHRoZSBzeXN0ZW0gcmVzb2x2ZXIsIGFuZCBjaG9vc2UgdG8gZG8g c28gb3ZlciBhIHByb3RvY29sIHRoYXQgaXMgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSByZWd1bGFy IEhUVFBTIHRyYWZmaWMuICBUaGVyZSBpc24ndCBhIGdvb2QgYW5zd2VyIHlldC4gIFNldmVyYWwg cGVvcGxlIGhhdmUgYXV0aG9yZWQgZHJhZnRzIGFib3V0IHRoZSBvcGVyYXRpb25hbCBpc3N1ZXMs IGFuZCB0aGVyZSB3YXMgYSBzaWRlLW1lZXRpbmcgYXQgSUVURiAxMDQgYWJvdXQgd2hpY2ggd29y a2luZyBncm91cHMgYXJlIHN1aXRhYmxlIGZvciByYWlzaW5nIHRoZXNlIGlzc3VlcywgYnV0IHRo aXMgaXMgYSBjb25jZXJuIHNoYXJlZCBieSBzb21lIG5ldHdvcmsgb3BlcmF0b3JzLCBzZWN1cml0 eSBzb2Z0d2FyZSB2ZW5kb3JzLCBhbmQgY2xvdWQgcHJvdmlkZXJzLiINCg0KLUpvbg0KDQoNCi0t DQpKb24gUmVlZCA8anJlZWRAYWthbWFpLmNvbT4NClNlbmlvciBQZXJmb3JtYW5jZSBFbmdpbmVl cg0KQWthbWFpIFRlY2hub2xvZ2llcw0KTmFtZXNlcnZlcnMgU2VydmljZSBQZXJmb3JtYW5jZSAN Cg0KDQo= From nobody Mon Apr 1 13:26:29 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E2112001B for ; Mon, 1 Apr 2019 13:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 9IO8aab7KY_4 for ; Mon, 1 Apr 2019 13:26:24 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 DEAAE12004B for ; Mon, 1 Apr 2019 13:26:23 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id x12so12553884qts.7 for ; Mon, 01 Apr 2019 13:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Rm5DMLjCx5GgVmHgCLswj1Ins/I05mhlEA6P1XKyLU=; b=jZO+aRE+254K+umPtUUL4RPd6QyDH466Wo6UCwKXE2TNSLUChhoSW77UHeaHJ1rhrN RbGksJ1g3v2xiP18pvZwwvN6EUtxiP2twzAp+ITWcLitf9msluxVuASJmm1FROXxyzcF ldzlB63qe9PaRHY5+7KqjH69XTywaDNGcR1DmAB3UGX/75yGsW0PsZVbVTukxLqk8ZL8 AHLc40FHDBX7GB+mx97Rww4Po8q/VSqGWPKRkohN1BAu6YujDwmRJIUy8ah2od4bEoGW bsdfaXI4p6dv6gEo+yLuEhozwjxS3tNgTNxrMerbdtJzHT4Hv+6hqfLpzmldUVN2uyNG gGFg== 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=3Rm5DMLjCx5GgVmHgCLswj1Ins/I05mhlEA6P1XKyLU=; b=BKJmkarTq+04bwXpBs4aOCc2ekcUZ9TDRINfds+QdDiWnMgM3jlosWBHfGyBykcsDm ZgSQHYWKILcR6zaHeJ7vm82tV+Nz0l1oRYP5H05MrXPTjY1szDNDG574utuc6Ra4r0NZ sUeXSmL5AQgWEGSGxsNVMq7kWJww2uy/j9gNRbTZC00ran3/vWgJhy5qrn7ljFi/Zz2s YhDAnQR9HQ4G1etwuY6rZGSkAZHVpBoHGOQ9KySJqGLiNRkUCq+s26nbwM6os5m616WX Q2/Z8e4QgXaKZ34Ju9xtdDsU30ZVb3mLPfGCrXycDB9icVZU6brNAERJ05aRWiAW5VK2 J2+A== X-Gm-Message-State: APjAAAUa7G2HzZO8ZDaJ3LwnR7NuInZYcWKMPw6uORYH3zYwPUrXvaP0 DixfAneSUmfzFCAWuF6VQ0Xw9R2uht7/0XE2TLI= X-Google-Smtp-Source: APXvYqw0lpb/c3QrpZO3E1Hlov+du61V4O++Kp+ayqrPtn9ZOH+U9IPjJSLisMwtFrgRzHD2GdYyvLqbI83IdntvajA= X-Received: by 2002:ac8:38f5:: with SMTP id g50mr55679764qtc.119.1554150382970; Mon, 01 Apr 2019 13:26:22 -0700 (PDT) MIME-Version: 1.0 References: <9E5DEDE1-14C1-48AA-B2EC-85A8CC20CBE7@cable.comcast.com> In-Reply-To: <9E5DEDE1-14C1-48AA-B2EC-85A8CC20CBE7@cable.comcast.com> From: Brian Dickson Date: Mon, 1 Apr 2019 13:26:10 -0700 Message-ID: To: "Livingood, Jason" Cc: Eric Rescorla , DoH WG Content-Type: multipart/alternative; boundary="0000000000008129bd05857dd5af" Archived-At: Subject: Re: [Doh] Mozilla's plans re: DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 20:26:27 -0000 --0000000000008129bd05857dd5af Content-Type: text/plain; charset="UTF-8" On Fri, Mar 29, 2019 at 11:31 AM Livingood, Jason < Jason_Livingood@comcast.com> wrote: > > [2] Many networks redirect NXDOMAIN to a search/advertising page. > > [JL] This is a reply on this somewhat minor point because NXDOMAIN was > also raised at the side meeting. I wonder if folks have more specific > references to networks that are *currently* engaged in NXDOMAIN > redirection. My sense is that this practice was largely fallen by the > wayside as a result of being overtaken by the browser-based omnibox > function that launched several years ago and the resulting change in user > behavior to just type search terms into the address bar and then click on > search results. In any case, curious to know if there's a list of ISPs > currently doing this. > > It is probably worth pointing out that, with a very few exceptions in the CCtld space, that TLDs are DNSSEC signed, and DNSSEC validation can help prevent NXDOMAIN redirection. There is still a problematic issue with NSEC3 opt-out. With NSEC or NSEC3 with no opt-out, it is possible to distinguish unsigned delegations from NXDOMAIN results. When opt-out NSEC3 is used, that is not possible. This means that in NSEC3 opt-out TLDs, it is technically possible for NXDOMAIN rewriting by re-purposing the DNSSEC "proof" of NXDOMAIN, into a DNSSEC "proof" of unsigned delegation. For TLDs that don't do opt-out, NXDOMAIN rewriting can be blocked by doing DNSSEC validation. (This would seem to suggest that having TLDs move away from opt-out would be in everyone else's interest.) Brian --0000000000008129bd05857dd5af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 29, 2019 at 11:31 AM Livi= ngood, Jason <Jason_Livin= good@comcast.com> wrote:
> [2] Many networks redirect NXDOMAIN to a search/advert= ising page.

[JL] This is a reply on this somewhat minor point because NXDOMAIN was also= raised at the side meeting. I wonder if folks have more specific reference= s to networks that are *currently* engaged in NXDOMAIN redirection. My sens= e is that this practice was largely fallen by the wayside as a result of be= ing overtaken by the browser-based omnibox function that launched several y= ears ago and the resulting change in user behavior to just type search term= s into the address bar and then click on search results. In any case, curio= us to know if there's a list of ISPs currently doing this.


It is probably worth pointing out that, with a = very few exceptions in the CCtld space, that TLDs are DNSSEC signed, and DN= SSEC validation can help prevent NXDOMAIN redirection.
There is s= till a problematic issue with NSEC3 opt-out. With NSEC or NSEC3 with no opt= -out, it is possible to distinguish unsigned delegations from NXDOMAIN resu= lts. When opt-out NSEC3 is used, that is not possible.

=
This means that in NSEC3 opt-out TLDs, it is technically possible for = NXDOMAIN rewriting by re-purposing the DNSSEC "proof" of NXDOMAIN= , into a DNSSEC "proof" of unsigned delegation.

For TLDs that don't do opt-out, NXDOMAIN rewriting can be block= ed by doing DNSSEC validation.=C2=A0
(This would seem to suggest = that having TLDs move away from opt-out would be in everyone else's int= erest.)

Brian
--0000000000008129bd05857dd5af-- From nobody Mon Apr 1 13:33:09 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E85E1200CE for ; Mon, 1 Apr 2019 13:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 bfHlzYmNBlZv for ; Mon, 1 Apr 2019 13:33:06 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 649101201E0 for ; Mon, 1 Apr 2019 13:32:59 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id k189so6558764qkc.0 for ; Mon, 01 Apr 2019 13:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y0XkbrZFtzEQt46Tp5xIEfXgC1cmff0XF8hSi6IJAEI=; b=GthSqiAmOa9SE0Mo8hJqJGwQEve/HvBq2X9LSmZmQpJVgmgdHks9uuC8lIvGFk71yk Y10POzV9lYnP86/qQbQWoPxmNFABDDOkjGwMXUkoSTqmklpq00Tba0oEqMdP4CWD1GxF Vz9W6Ba7bF4O3md/Rjydazx9Fo+Kw4diQWnQFfYCWwAo+lvJop/KYlc+4xYfDtct9N7k mts9ArpowcSAT+pcud90naaDP9elimue3O/xLHWRXX13GIonZT+i2rSTz8m9CAUHaA3E LYTIO++mdnvjrq5/ARjfKOaiewYcxlEJ7p2KqZ/Qu+OuOk9ozowwJV2/T1WjiiGbNxr2 vmvA== 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=y0XkbrZFtzEQt46Tp5xIEfXgC1cmff0XF8hSi6IJAEI=; b=eckeaDEFr9CBp+cfjcY5sddXpmA/rDFmaU6MyxOidShN+vdkQGILKLDHWJ2IpnKm7y LiwxJ+4FVvc8bXE3S4T0uh+lOlI8rMZxAkOZwdBsdl+IORvVMWkJ2thGcp6PPlvB6KtC Sl+UHPmaxykC8oMvx8M2Kacjh7GBimPcY97GPVdsdAV4GEiW/8Y23NYxCilrzzwp5Xls WgHQLfqSti1JDrCxq66WNK4keEjgSlhbVH39R8fhpSMkoFyqYe5Crhs9tIp4O5SwLcYI i0fJMyQZtlUwa2Z32Vg+o6FUG0lsaBX/Liu3QaeSRnom/T0JxNbZDZCOgRxDCDFNfSkZ AYLQ== X-Gm-Message-State: APjAAAVjSrQ/D0/scTUp7lYdNh6YCNHEPpFqisRBnryHTeei+3JieDxq wct0sldtseDj78Pd5lOFn1P/qAyiWUVZ4DQEbeE= X-Google-Smtp-Source: APXvYqxsuHN9k8wFYyoVx9e3V1F1BAD1AvJIRjnSXM3huAgekHBKL5H4LPtD2c3ckwzCvvKanXvXGPvw6j4IbpxqEtE= X-Received: by 2002:a37:784:: with SMTP id 126mr50255697qkh.10.1554150778569; Mon, 01 Apr 2019 13:32:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Mon, 1 Apr 2019 13:32:46 -0700 Message-ID: To: Eric Rescorla Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000158d4a05857ded90" Archived-At: Subject: Re: [Doh] Mozilla's plans re: DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 20:33:09 -0000 --000000000000158d4a05857ded90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla wrote: > I=E2=80=99ve heard a number of questions about Mozilla=E2=80=99s plans ar= ound > DoH. We=E2=80=99ve made a number of public statements, but it might be us= eful > to try to put this all in one place. > > In context, the problem we are attempting to solve here is attack on > the user=E2=80=99s name resolution from an attacker with full or partial > control of the network, as contemplated by Section 3 of BCP 72 as well > as BCP 188. There=E2=80=99s ample evidence of monitoring/manipulation of = user > traffic via this vector [0][1][2]. > > [1] > https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pea= rce.pdf > Looking specifically at the problem statement and evidence, I have a question about this (or any other) investigative work: Has there been any related/follow-up work, or other similarly scoped work, to examine the use of DNSSEC in the domains tested, that you're aware of or can point folks at? I.e. Were any of the manipulated domains signed DNSSEC domains, where validation might have prevented the manipulated responses from being accepted from the resolver? Clearly there would still be the issue of being able to find/reach a resolver that does not manipulate results, but at least the manipulation would be detected/blocked. (Percentages overall, and percentages in the manipulated results groups, would both be interesting and informative.) Brian --000000000000158d4a05857ded90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 27, 2019 at 2:18 AM Eric = Rescorla <ekr@rtfm.com> wrote:
<= div dir=3D"ltr">I=E2=80=99ve heard a number of questions about Mozilla=E2= =80=99s plans around
DoH. We=E2=80=99ve made a number of public statemen= ts, but it might be useful
to try to put this all in one place.

I= n context, the problem we are attempting to solve here is attack on
the = user=E2=80=99s name resolution from an attacker with full or partial
con= trol of the network, as contemplated by Section 3 of BCP 72 as well
as B= CP 188. There=E2=80=99s ample evidence of monitoring/manipulation of usertraffic via this vector [0][1][2].

Looking specifically at the problem statement and ev= idence, I have a question about this (or any other) investigative work:
Has there been any related/follow-up work, or other similarly scoped= work, to examine the use of DNSSEC in the domains tested, that you're = aware of or can point folks at?

I.e. Were any of t= he manipulated domains signed DNSSEC domains, where validation might have p= revented the manipulated responses from being accepted from the resolver?

Clearly there would still be the issue of being abl= e to find/reach a resolver that does not manipulate results, but at least t= he manipulation would be detected/blocked.

(Percen= tages overall, and percentages in the manipulated results groups, would bot= h be interesting and informative.)

Brian
--000000000000158d4a05857ded90-- From nobody Mon Apr 1 13:46:22 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF531201EB for ; Mon, 1 Apr 2019 13:46:20 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 hu32U4OTXS1C for ; Mon, 1 Apr 2019 13:46:17 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 0B75F1201E0 for ; Mon, 1 Apr 2019 13:46:17 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id v14so7323825lfi.0 for ; Mon, 01 Apr 2019 13:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QBRWZXXm7UdoCzL0SzUm6BIaDWTGT2R3UhyC/Kc4UEw=; b=E+tkGZhDfSBXYY7pmZCO4u9u7QrM5rnDyIPVvSD7pMkI1kU7UwW7xSxaTPRk7Z83hm 0qpryTfhBddNCljnmvOjUX0zkhkRvj7tzsydOGF1RHAM+J0UISCrsRRlrodTuFTg640T rshJp2lnZnUMjIaqudvb63LJ+Xbbystokri9E3vWOcOTy8aXx1k2W5jJYdErOkCpy9bP erKeC8aW5oJpJC8AwsMBEZuLeKAdw5t6F3+L7nB0HP8y2QHPbM2oP62q/2jAQvjnbTsw OgcphPvUxze0tPVkmQzVMfT89E1Ygw90NJlzft/FRzfEWrxrYVl+52jHcc4kFkB/Rf8V +iZA== 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=QBRWZXXm7UdoCzL0SzUm6BIaDWTGT2R3UhyC/Kc4UEw=; b=ZGigtmoC/xybsOjQj/5KUNpsUA8NRAifXPavE2xywZOdFSpf8OHE6BijAQ4gkuIeCj Ygt3MR5BC7bhmaf1pwfbcOHVJ5ep64ByOoIwPOP73kwraeGqxOsroXpxrQyAsOH2XP/D tnH05srfqjz0654DEEn32OIwWH79cIKTlnr2JLojdWBNGwzFgO8L5qGhDLIjk370S0Sk CvW/oEjwIMRRNm6Sis9yXXB9KG2ZgCjMe9Nfa753XoZuzHEuZJHnor+g9HUqgWU8zvxH 1nVW4p5A+8K2Kb6/vpn1zmDXYH1Y71VR/WztVui+3cZyez3zbYELmezlla+DK+aZMN55 1AkQ== X-Gm-Message-State: APjAAAViWZMqcX4bmkMEdDAkUocxXrGM9jNwM9TdDzLtfPcpgrSCWW8c wJIt/2f4X0EckYMxioY4ztv0JPPWXvkOKgyjGJ/eAQ== X-Google-Smtp-Source: APXvYqzHCBR6ADNdMy4kCvC9cYdXBElBrfK22xh17wgy7bs18G4P5UQgvvE9fq4/OG412cKoBn+Ym3YFhBrZQ7Bn6aQ= X-Received: by 2002:ac2:52a6:: with SMTP id r6mr35429333lfm.27.1554151575259; Mon, 01 Apr 2019 13:46:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 1 Apr 2019 13:45:38 -0700 Message-ID: To: Brian Dickson Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000092264a05857e1cf0" Archived-At: Subject: Re: [Doh] Mozilla's plans re: DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 20:46:20 -0000 --00000000000092264a05857e1cf0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 1, 2019 at 1:32 PM Brian Dickson wrote: > > > On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla wrote: > >> I=E2=80=99ve heard a number of questions about Mozilla=E2=80=99s plans a= round >> DoH. We=E2=80=99ve made a number of public statements, but it might be u= seful >> to try to put this all in one place. >> >> In context, the problem we are attempting to solve here is attack on >> the user=E2=80=99s name resolution from an attacker with full or partial >> control of the network, as contemplated by Section 3 of BCP 72 as well >> as BCP 188. There=E2=80=99s ample evidence of monitoring/manipulation of= user >> traffic via this vector [0][1][2]. >> > >> [1] >> https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pe= arce.pdf >> > > Looking specifically at the problem statement and evidence, I have a > question about this (or any other) investigative work: > Has there been any related/follow-up work, or other similarly scoped work= , > to examine the use of DNSSEC in the domains tested, that you're aware of = or > can point folks at? > > I.e. Were any of the manipulated domains signed DNSSEC domains, where > validation might have prevented the manipulated responses from being > accepted from the resolver? > > Clearly there would still be the issue of being able to find/reach a > resolver that does not manipulate results, but at least the manipulation > would be detected/blocked. > I don't have much more information than is in the paper (you'll note I'm not an author), but generally DNSSEC doesn't help that much here. You can't safely do DNSSEC validation on user-facing clients because of a combination of tampering by middleboxes (typically record stripping, etc,. not really "attacks") and errors in the published DNSSEC records. -Ekr > (Percentages overall, and percentages in the manipulated results groups, > would both be interesting and informative.) > > Brian > --00000000000092264a05857e1cf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 1, 2019 at 1:32 PM Brian = Dickson <brian.peter.di= ckson@gmail.com> wrote:


On Wed, Mar 27, 2019= at 2:18 AM Eric Rescorla <ekr@rtfm.com> wrote:
I=E2=80=99ve heard a num= ber of questions about Mozilla=E2=80=99s plans around
DoH. We=E2=80=99ve= made a number of public statements, but it might be useful
to try to pu= t this all in one place.

In context, the problem we are attempting t= o solve here is attack on
the user=E2=80=99s name resolution from an att= acker with full or partial
control of the network, as contemplated by Se= ction 3 of BCP 72 as well
as BCP 188. There=E2=80=99s ample evidence of = monitoring/manipulation of user
traffic via this vector [0][1][2].
<= /div>
<= div dir=3D"ltr">

Looking specificall= y at the problem statement and evidence, I have a question about this (or a= ny other) investigative work:
Has there been any related/follow-u= p work, or other similarly scoped work, to examine the use of DNSSEC in the= domains tested, that you're aware of or can point folks at?

I.e. Were any of= the manipulated domains signed DNSSEC domains, where validation might have= prevented the manipulated responses from being accepted from the resolver?=

Clearly there would still be the issue of being a= ble to find/reach a resolver that does not manipulate results, but at least= the manipulation would be detected/blocked.
=

I don't have much more information than is in the p= aper (you'll note I'm not an author), but generally DNSSEC doesn= 9;t help that much here. You can't safely do DNSSEC validation on user-= facing clients because of a combination of tampering by middleboxes (typica= lly record stripping, etc,. not really "attacks") and errors in t= he published DNSSEC records.
-Ekr


(Percentages overall, and percentages in th= e manipulated results groups, would both be interesting and informative.)

Brian
--00000000000092264a05857e1cf0-- From nobody Mon Apr 1 14:24:01 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E514612000E for ; Mon, 1 Apr 2019 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RvLlKrPwy5pP for ; Mon, 1 Apr 2019 14:23:55 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 0019F120114 for ; Mon, 1 Apr 2019 14:23:54 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id t78so6480463vsc.1 for ; Mon, 01 Apr 2019 14:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wr9sXpzVM8zLEjFiHkhOLSFQkSHPk7syWmIuK9rTKhk=; b=bOQsIgEvZNudY6jlPbouIZ9LheOYPzKggUpEX55h09fxLvXGPYGqVlBSMOgZozA/7O +Cx6elYgZl9fTwd2APGBhj920j9U96VOhjb3mrb/vPBrPfRlwmn3Mqd5sI9iVkfmVor6 yyv+FHenr8/FBOlZ672Rb2EHD5bVPa0B6C9fMaaBm56c+t/+UnZespVVqtOdG7+zaiSe zmNMcvc130mKR5nvRRJX7QvWuSzLlXGxGW73/KqK5Cg27hqukgH4jm4tx3OO2Kj8WG/Z BGvnn7brJxuqHk4ybMlJZwMl5VKcye98FjS8QjJCOAJSMer/fyMZXt9KsT6thQammoaa TBGw== 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=wr9sXpzVM8zLEjFiHkhOLSFQkSHPk7syWmIuK9rTKhk=; b=j2x9tkR4o3U1vyJf3OM0uwA+cAu9bhXcJFubog5AHd0CRwKOlMKTGYeAmRrk/EWS2J Hch2A6no/eqzsMitDmVYsSpR4NVlDNYfGYxruvJ/kh67BbGmKeilCpx68JKoNpHcEzzd stpRhW3ftcUdxVWfTAXVf+g5/mvptu46UceAfrgkEBGWXfwMADLIKfYgQp4Ga4NO8d3E ZMnYsbmar59Rj3KV7BZm3JG/84EyjFR8iTLsReDjXmH/iX4n9qiUxssNsFMVo8lUG0OR KpHcvUoA5uNr97BGpi/StbjoXFCiTcGr6O79dbmIxe6ploXnnxs0QAEV66FpuaKEUl2N dgsA== X-Gm-Message-State: APjAAAWVPcfqzRte6W16YFz8nFizghD+iiiX54nZp+RqhrvnzPP91lnP Ck2UiCkToDkZSzqCorpG6xuM4vqcB4NoeuDoGLG2jXmrjGw= X-Google-Smtp-Source: APXvYqxrFs+u7QLSddpsKoYG5fWL32FIZ/T71bo8NVw5WgA1HHaoUrvLRAkpWzNe8GMraX/8cX6+3sk5QSvHGZeDDOE= X-Received: by 2002:a67:fb89:: with SMTP id n9mr24449349vsr.119.1554153833692; Mon, 01 Apr 2019 14:23:53 -0700 (PDT) MIME-Version: 1.0 References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org> <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> In-Reply-To: <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> From: Ben Schwartz Date: Mon, 1 Apr 2019 17:23:42 -0400 Message-ID: To: Martin Thomson Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000035cf9005857ea358" Archived-At: Subject: Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 21:23:58 -0000 --00000000000035cf9005857ea358 Content-Type: multipart/alternative; boundary="0000000000002f65a105857ea371" --0000000000002f65a105857ea371 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 30, 2019 at 8:48 AM Martin Thomson wrote: > On Mon, Mar 25, 2019, at 12:37, Paul Hoffman wrote: > > The reason I didn't drop down to http: is that doing so evokes the > > response, even though you are quite correct that the other two > > methods given in this document do not offer any authentication. > > There is a different reason that I think is stronger. We tolerate an > exposure on DHCP and other network-layer configuration options (like the v6 > RA). The security implications of those mechanisms are well understood and > it is common for networks to deploy systems that limit the opportunity for > attacks. Things like filtering broadcast and RA from end hosts are common. > > But the connection to a resolver might be harder to secure in this > fashion. Though it might be possible to narrow the use of unicast port 53 > (or 853), such filtering is different. It is not always the case that the > resolver is local in the same way that a DHCP server/relay or gateway is. > For DoH, which might use a service that is completely external to the > network, this is more difficult. > What is your view on subsequent unauthenticated connections that _do_ terminate inside the network? If these are allowed, then we can consider designs that reduce the need for clients to perform authentication, and move the point of authentication to a relay or reverse-proxy operated by the network operator. > Therefore, it is easier to look at this step of the configuration process > as being subject to "untrusted" activity and insist on authentication. > It's certainly true that the only basis for authentication is the assertion > by the network discovery phase, for which you have no prior expectations. > However, the property we are looking for is that we are talking to the > same server that the network intended for us to talk to. Thus, if the name > of the server comes from the same mechanism that gave us an IP address > (DHCP), or the system that provides connectivity (RA), then we at least > have that much. > > If your goal is to talk to the resolver provided by the network, then I > believe that to be sufficient. > > Hence I would propose a different design for this, bringing DoT into the > design. > > 1. The first step requires no new protocol mechanisms. To discover DoT, > connect to the resolver IP at port 853. If the server produces a > certificate that is valid for the IP address of the resolver, then you are > good to proceed. No new mechanism is required. (Clients may decide to > accept any certificate here if they require opportunistic security, but I > would suggest that this is unwise for the aforementioned reasons. That > said, it's better than using Do53, so I'd say it's still worth doing except > for the fact that this establishes an expectation on the part of DoT > resolvers that having a valid certificate is not required, which is > dangerous.) > For clarity, this is the DoT Opportunistic Privacy Profile in RFC 7858 Section 4.1 . It's the default mode on Android 9 and later. How would you view an arrangement where the network operator runs a DoT forwarder at an RFC 1918 address with a self-signed certificate, forwarding all queries to an external DoT resolver that the forwarder authenticates by name against a typical root store? 2. We add a field to DHCP and RA that carries the "DoT resolver". When > this is present, the client resolves this name using the resolver. This > resolution is unsecured. The client then connects to the resulting IP > address and validates the certificate it presents using this name. This > enables easier deployment of DoT because a certificate for a name is easier > to get than an IP certificate (it also enables use of 1918 address and the > like). > > 3. We add another field to DHCP and RA that carries the "DoH resolver". > When this is present, the client resolves the associated name using the > unsecured resolver. The client then connects to this endpoint, validates > the certificate and proceeds to use DoH. > > We could decide not to do the DoT step, but I wanted to include it to > illustrate the symmetry of the design. > > You will observe that this is significantly simpler than the proposed > design. There are several drawbacks, that I will address: > > A. A client in a residential network will not receive this option unless > their gateway/relay is configured to relay these values from external > network. The design proposed in the current draft has this property in > that the SUDN is forwarded by resolvers that don't understand its purpose. > In this case, endpoints will talk to the DNS proxy in their gateway and not > be able to discover a DoH service provided by an ISP. RFC 5625 points out > that it is not generally possible to talk to the external resolver. > > B. This doesn't provide any option for web clients to find the local > resolver. I will separately argue that this is not a valid use case, and > moreover that it is one that presents some privacy challenges for clients > and networks. It should not be possible for a web site to be able to use a > client's position in the network to access information that it would not > otherwise be able to access itself. Allowing requests to a local resolver > might allow access to that sort of information. Sites are better suited to > making requests of configured resolvers. With DoH, they can make those > requests from the client, meaning that the answers will be more suitable > for the client's position in the network than their own. Though this > requires that the configured resolver has nodes that are deployed near the > client, I believe this to be sufficient. > > I think that problem A is pretty significant. The SUDN option does help > there, but it eliminates the weak "authentication" we have. For anything > in this area to work, I think that we would need some other basis for > deciding that the DoH server that is identified in this way is OK. The > only idea that I have, which is a poor one, is to configure clients with a > list of "trusted" resolvers. I don't like maintaining these sorts of > lists, but it might be the only way to manage it. No matter what option we > choose here, I would prefer that we look at the DHCP/RA steps first. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000002f65a105857ea371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 30, 2019 at 8:48 AM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
On Mon,= Mar 25, 2019, at 12:37, Paul Hoffman wrote:
> The reason I didn't drop down to http: is that doing so evokes the=
> <horror> response, even though you are quite correct that the ot= her two
> methods given in this document do not offer any authentication.

There is a different reason that I think is stronger.=C2=A0 We tolerate an = exposure on DHCP and other network-layer configuration options (like the v6= RA).=C2=A0 The security implications of those mechanisms are well understo= od and it is common for networks to deploy systems that limit the opportuni= ty for attacks.=C2=A0 Things like filtering broadcast and RA from end hosts= are common.

But the connection to a resolver might be harder to secure in this fashion.= =C2=A0 Though it might be possible to narrow the use of unicast port 53 (or= 853), such filtering is different.=C2=A0 It is not always the case that th= e resolver is local in the same way that a DHCP server/relay or gateway is.= =C2=A0 For DoH, which might use a service that is completely external to th= e network, this is more difficult.

What= is your view on subsequent unauthenticated connections that _do_ terminate= inside the network?=C2=A0 If these are allowed, then we can consider desig= ns that reduce the need for clients to perform authentication, and move the= point of authentication to a relay or reverse-proxy operated by the networ= k operator.
=C2=A0
Therefore, it is easier to look at this step of the configuration process a= s being subject to "untrusted" activity and insist on authenticat= ion.=C2=A0 It's certainly true that the only basis for authentication i= s the assertion by the network discovery phase, for which you have no prior= expectations.=C2=A0 =C2=A0However, the property we are looking for is that= we are talking to the same server that the network intended for us to talk= to.=C2=A0 Thus, if the name of the server comes from the same mechanism th= at gave us an IP address (DHCP), or the system that provides connectivity (= RA), then we at least have that much.

If your goal is to talk to the resolver provided by the network, then I bel= ieve that to be sufficient.

Hence I would propose a different design for this, bringing DoT into the de= sign.

1. The first step requires no new protocol mechanisms.=C2=A0 To discover Do= T, connect to the resolver IP at port 853.=C2=A0 If the server produces a c= ertificate that is valid for the IP address of the resolver, then you are g= ood to proceed.=C2=A0 No new mechanism is required.=C2=A0 (Clients may deci= de to accept any certificate here if they require opportunistic security, b= ut I would suggest that this is unwise for the aforementioned reasons.=C2= =A0 That said, it's better than using Do53, so I'd say it's sti= ll worth doing except for the fact that this establishes an expectation on = the part of DoT resolvers that having a valid certificate is not required, = which is dangerous.)

For clarity, this = is the DoT Opportunistic Privacy Profile in=C2=A0RFC 7858 Section 4.1.=C2=A0 It's = the default mode on Android 9 and later.

How would= you view an arrangement where the network operator runs a DoT forwarder at= an RFC 1918 address with a self-signed certificate, forwarding all queries= to an external DoT resolver that the forwarder authenticates by name again= st a typical root store?

2. We add a field to DHCP and RA that carries the "DoT resolver".= =C2=A0 When this is present, the client resolves this name using the resolv= er.=C2=A0 This resolution is unsecured.=C2=A0 The client then connects to t= he resulting IP address and validates the certificate it presents using thi= s name.=C2=A0 This enables easier deployment of DoT because a certificate f= or a name is easier to get than an IP certificate (it also enables use of 1= 918 address and the like).

3. We add another field to DHCP and RA that carries the "DoH resolver&= quot;.=C2=A0 When this is present, the client resolves the associated name = using the unsecured resolver.=C2=A0 The client then connects to this endpoi= nt, validates the certificate and proceeds to use DoH.

We could decide not to do the DoT step, but I wanted to include it to illus= trate the symmetry of the design.

You will observe that this is significantly simpler than the proposed desig= n.=C2=A0 There are several drawbacks, that I will address:

A. A client in a residential network will not receive this option unless th= eir gateway/relay is configured to relay these values from external network= .=C2=A0 The design proposed in the current draft has this property in that = the SUDN is forwarded by resolvers that don't understand its purpose.= =C2=A0 In this case, endpoints will talk to the DNS proxy in their gateway = and not be able to discover a DoH service provided by an ISP.=C2=A0 RFC 562= 5 points out that it is not generally possible to talk to the external reso= lver.

B. This doesn't provide any option for web clients to find the local re= solver.=C2=A0 I will separately argue that this is not a valid use case, an= d moreover that it is one that presents some privacy challenges for clients= and networks.=C2=A0 It should not be possible for a web site to be able to= use a client's position in the network to access information that it w= ould not otherwise be able to access itself.=C2=A0 Allowing requests to a l= ocal resolver might allow access to that sort of information.=C2=A0 Sites a= re better suited to making requests of configured resolvers.=C2=A0 With DoH= , they can make those requests from the client, meaning that the answers wi= ll be more suitable for the client's position in the network than their= own.=C2=A0 Though this requires that the configured resolver has nodes tha= t are deployed near the client, I believe this to be sufficient.

I think that problem A is pretty significant.=C2=A0 The SUDN option does he= lp there, but it eliminates the weak "authentication" we have.=C2= =A0 For anything in this area to work, I think that we would need some othe= r basis for deciding that the DoH server that is identified in this way is = OK.=C2=A0 The only idea that I have, which is a poor one, is to configure c= lients with a list of "trusted" resolvers.=C2=A0 I don't like= maintaining these sorts of lists, but it might be the only way to manage i= t.=C2=A0 No matter what option we choose here, I would prefer that we look = at the DHCP/RA steps first.

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000002f65a105857ea371-- --00000000000035cf9005857ea358 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCA4hN4Pt6li+/qB3YUIahV5 TQPKLxAYFWBx5yI5o0lUrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA0MDEyMTIzNTRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEASVr5W/JGdR4UV4UdI44/lGYdBOP5sGQW4AiNzoEs FSbxVeLDAGSrPH5LflrRhx+QYvU6YRPQxx3tC4DH8V5N/+H8Od9Iz/d73x69V7CDNJjmMsKG3n0d Hxj+wzcE42Ph7jyLVhw074d9e37g2gi1tEhQlGJCNMqNM4ASpe8KAGrodUyuhJks2kQqVRcembg7 ZqX2SAYf2poGsYCPvyNqH9zIZzYl7H4C1l8KWhD+JYuH22/kA2Ph5cFtLN/Y+89zlojxWt2QkKbS 95wnjiX+b6AmUgphxGBjpfJXBqktl6wtLDVHs7d/LsU2z0I6j7PmmN4NY8+ZbNyof1lV+r52pA== --00000000000035cf9005857ea358-- From nobody Wed Apr 3 13:35:04 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5300E120189 for ; Wed, 3 Apr 2019 13:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=riseup.net 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 xFU2YONGBQ94 for ; Wed, 3 Apr 2019 13:35:01 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6662E12006A for ; Wed, 3 Apr 2019 13:35:01 -0700 (PDT) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id C93FB1A0200 for ; Wed, 3 Apr 2019 13:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1554323700; bh=IQJs9VD2BUTQFMVBPZoCipFkS3q0zCl/nskmLhDdXLg=; h=To:References:From:Subject:Date:In-Reply-To:From; b=QWdvw5CUoaRz75kLzwhhddMe6HTEgVTcpnG6TE6LuycKGe+xVYesN+os4BiVQUhIq TydnDzA9FKJjP4WaElLTdIDTQ4cL89S70nC/lKRcbcUxq58gMOmY7UrLNWRoTAlbvG fqlnv09ezwp6bemB5EXa1mEu0RlL67Y8OBZVPEPE= X-Riseup-User-ID: 2F096B0E20E4639861B096222038CBA9FC896A216B2DABAC1BC27F93D17E2E6E Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id F0FAC1202A8 for ; Wed, 3 Apr 2019 13:34:59 -0700 (PDT) To: doh@ietf.org References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org> <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> From: nusenu Openpgp: preference=signencrypt Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA== Message-ID: Date: Wed, 03 Apr 2019 20:34:00 +0000 MIME-Version: 1.0 In-Reply-To: <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1MrQVr6CAyrLTUnT85bXXtDh3Pme7SzF0" Archived-At: Subject: Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 20:35:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1MrQVr6CAyrLTUnT85bXXtDh3Pme7SzF0 Content-Type: multipart/mixed; boundary="amHfqVhcrgrZpBNIvZ4Lv9FTMvTWoQvTd"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: Subject: Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org> <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> In-Reply-To: <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> --amHfqVhcrgrZpBNIvZ4Lv9FTMvTWoQvTd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Martin Thomson: > There is a different reason that I think is stronger. We tolerate an > exposure on DHCP and other network-layer configuration options (like > the v6 RA). The security implications of those mechanisms are well > understood and it is common for networks to deploy systems that limit > the opportunity for attacks. Things like filtering broadcast and RA > from end hosts are common. >=20 > But the connection to a resolver might be harder to secure in this > fashion. Though it might be possible to narrow the use of unicast > port 53 (or 853), such filtering is different. It is not always the > case that the resolver is local in the same way that a DHCP > server/relay or gateway is. For DoH, which might use a service that > is completely external to the network, this is more difficult. >=20 > Therefore, it is easier to look at this step of the configuration > process as being subject to "untrusted" activity and insist on > authentication.=20 +1 thanks for writing this down. I agree with your reasoning regarding the potential external position of the resolver and the increased attack opportunity/exposure (in contrast to the mostly local DHCP attack surface). I'd also like to add that even though most clients probably use DHCP to d= iscover DNS servers, not all do, and therefore assuming it is fine to use an unauthenticated mechanism is fine because DHCP is unauthenticated as w= ell, is somewhat flawed. > It's certainly true that the only basis for > authentication is the assertion by the network discovery phase, for > which you have no prior expectations. However, the property we are > looking for is that we are talking to the same server that the > network intended for us to talk to. Thus, if the name of the server > comes from the same mechanism that gave us an IP address (DHCP), or > the system that provides connectivity (RA), then we at least have > that much. >=20 > If your goal is to talk to the resolver provided by the network, then > I believe that to be sufficient. >=20 > Hence I would propose a different design for this, bringing DoT into > the design. >=20 > 1. The first step requires no new protocol mechanisms. To discover > DoT, connect to the resolver IP at port 853. If the server produces > a certificate that is valid for the IP address of the resolver, then > you are good to proceed. No new mechanism is required. (Clients may > decide to accept any certificate here if they require opportunistic > security, but I would suggest that this is unwise for the > aforementioned reasons. That said, it's better than using Do53, so > I'd say it's still worth doing except for the fact that this > establishes an expectation on the part of DoT resolvers that having a > valid certificate is not required, which is dangerous.) >=20 > 2. We add a field to DHCP and RA that carries the "DoT resolver". > When this is present, the client resolves this name using the > resolver. This resolution is unsecured. The client then connects to > the resulting IP address and validates the certificate it presents > using this name. This enables easier deployment of DoT because a > certificate for a name is easier to get than an IP certificate (it > also enables use of 1918 address and the like). >=20 > 3. We add another field to DHCP and RA that carries the "DoH > resolver". When this is present, the client resolves the associated > name using the unsecured resolver. The client then connects to this > endpoint, validates the certificate and proceeds to use DoH. >=20 this makes sense to me. > We could decide not to do the DoT step, but I wanted to include it to > illustrate the symmetry of the design. I'm in favor of keeping the DoT step since it provides a path for deployment even before the new DHCP options are implemented/available. > B. This doesn't provide any option for web clients to find the local > resolver. I will separately argue that this is not a valid use case, > and moreover that it is one that presents some privacy challenges for > clients and networks. It should not be possible for a web site to be > able to use a client's position in the network to access information > that it would not otherwise be able to access itself. Agreed. --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --amHfqVhcrgrZpBNIvZ4Lv9FTMvTWoQvTd-- --1MrQVr6CAyrLTUnT85bXXtDh3Pme7SzF0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlylGO0ACgkQrWE4wkXN Qn4qIRAAzp5LgSdTwQeL2aIZ91Eanq02BGcZdtqOpdMSb/ZjnbVBP0Q0fZsEhVd3 Q9zhBtPQrgGcGiNtb/sD1EuEsNz1xtqB1xZEceQYQBTfcwAtSxtPh3vjxVxn7T2Y 8ZKATyJJ5Y0vRn4tP/LWXDly7jm9lgMkxQUiuULCGMgJTYwU/APfUhiNO3+ps98G rjIQqO7kjmfBbLDN8hLYM/8y/bUurJTB/l6QxONdL2J7/lwXQX8PtpWzE0mp3yJD o9aSd9VoyfAISj0+IENeEAnlvSipliJBn4+INEhlUcZTx+4vY/q7O+f6lV5FoPcV J31HIGnF71z2Poht9o6aMeJS4InkBKudJJ6/8OKkDheMJ4oWcF0EisXFIFAx8ulq U4caNERyZv+XGU26SuGLucFpM9OawMt6Yx+gCFH5X8PTMkoSpkkSlcQtjW9CpUzm +RoJMxJ7UEfrTFaO03i4nYdeY4i9IHvfA8rIZbs4bvd8UnpVUcLAE0BfkRnLl9mf C8tSdIpS21KaL9pUEJ8ydtlg84tGF8z9DeDef2XitTbitKFA1gOmFqbwKDAkmLiR 4pnHTbvmiqkvC/UIdfK974fp2TdRBD3dDNoZRdZRO+8nnyc9dafybFat8uMqCSu2 TCWHPdB9gWxtUeiI5R2OnEKUtyhYIO6MzRdUwJYPqE5NlXX3YHY= =T/yy -----END PGP SIGNATURE----- --1MrQVr6CAyrLTUnT85bXXtDh3Pme7SzF0-- From nobody Thu Apr 4 08:15:47 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FE91201D4 for ; Thu, 4 Apr 2019 08:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Cm5kssCj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=06bmUcsA 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 lCOYMD-p24Hn for ; Thu, 4 Apr 2019 08:15:43 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3391200B5 for ; Thu, 4 Apr 2019 08:15:43 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E3FCA626A; Thu, 4 Apr 2019 11:15:41 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 04 Apr 2019 11:15:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=3eCU350AjWP+spBEy0KxBnCKhoa0 wfhPBDnJKn98BRI=; b=Cm5kssCj2xUcw4J9yJsiMpcOqB4ANEvDAFxdzgYuEwBY KutJLe4e4aULwECDeis8S8o9lhAIJiBJFE4RC5vPMi7AkO9Q+rhixVzE7smISj30 8LQNZNiR/aRC/FHIIeXYnf8jL8AIAt6jbjKtMfZeZmm/qTGqpFum19g9KkgI+Iz1 XdxO2e1Wy+KJJFcAafbQqvs4/CdxU1QBo0YC1K57hmLitd/7WErPNWYnGAYz2F/5 YQNV13Dm7rHsK0TLhJGfmjuD66R3ldA/+uLh1OciJ9oYeYgb3wCZiVK9PKaLzH9W d8oa7csjbQyWQxurJgX/2qZ2G9jmQYSo6iZOc5McYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3eCU35 0AjWP+spBEy0KxBnCKhoa0wfhPBDnJKn98BRI=; b=06bmUcsAjIE/JkQWeECb1O EgKPwkT7n6Sl1uSzDeI7BQKCkptmLMkSp/qXWivILGsSDh+Uwq2zNol4CCdbSI3p CSh+gEVnukLc5wYByVyK+Bieh7iBWXC4Ije8USi2CudstJxyhCxxo+Q0hs3TO0Fo C0PXgkZlcmwmIR3/qQ5lwzVMYTAWxJWWg0Ibem+fYbPEgx+2zCvRXX9/CrH+UfLj IF+nPHfq4/x4OTQ6vzYw3dy5TQqSaOIBN3ptnbSor3f025gh5mKnjJISmywrx3YQ ieiclLAn23SoaPTVwLAH8ujWLKUOPHNE5zeOES3tMfo2I38nDXcZUA3B5JK0SY9A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdekheculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfgg fkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhm shhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3FB627C411; Thu, 4 Apr 2019 11:15:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org> <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> Date: Thu, 04 Apr 2019 11:15:41 -0400 From: "Martin Thomson" To: "Ben Schwartz" Cc: "DoH WG" Content-Type: text/plain Archived-At: Subject: Re: [Doh] =?utf-8?q?Authentication_in_draft-ietf-doh-resolver-associ?= =?utf-8?q?ated-doh-03=2Etxt?= X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 15:15:46 -0000 On Mon, Apr 1, 2019, at 23:23, Ben Schwartz wrote: > What is your view on subsequent unauthenticated connections that _do_ > terminate inside the network? If these are allowed, then we can > consider designs that reduce the need for clients to perform > authentication, and move the point of authentication to a relay or > reverse-proxy operated by the network operator. How do you determine that a connection terminates inside the network? My assumption here is that discovery (DHCP/RA) is privileged, but nothing else. As for avoiding authentication, I will suggest that is a non-goal. We want consistent use of the protocol (be it DoT or DoH). > For clarity, this is the DoT Opportunistic Privacy Profile in RFC 7858 > Section 4.1 . It's the > default mode on Android 9 and later. Right. Forgive my sloppy non-use of the correct terminology. > How would you view an arrangement where the network operator runs a DoT > forwarder at an RFC 1918 address with a self-signed certificate, > forwarding all queries to an external DoT resolver that the forwarder > authenticates by name against a typical root store? All I care about is what the client can verify. A self-signed certificate wouldn't work. The forwarder could operate at the TCP layer and this would be fine, but clients can't trust the forwarder to do the right thing and just assert that without proof. What you describe is a MitM attack. We could talk about the use of an HTTP forward proxy for this, if the networking layer required that, but that is a lot harder to get right. Then you could talk DoH or even DoT to the real resolver, but you would still have a TLS connection to a server with a valid name. From nobody Thu Apr 4 15:20:34 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BDD120269 for ; Thu, 4 Apr 2019 15:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 cAdxJ0QY-fYS for ; Thu, 4 Apr 2019 15:20:32 -0700 (PDT) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) (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 B969F12023C for ; Thu, 4 Apr 2019 15:20:31 -0700 (PDT) Received: by mail-wr1-f67.google.com with SMTP id y7so5631146wrn.11 for ; Thu, 04 Apr 2019 15:20:31 -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=Zf468KCLuTSxlEkeB9jriH0ewAKlp7GXqbrkqMBL6g0=; b=O1E7PBaZP3iqwwp29dCXW393U3eHVImSNemoueenAZaGUcaxiYC78mbcWAgcKmotL/ 9XB0DK18g/rSrFwSZxxflPzE+AqBy5aRgiaDHuBB4KqOOgHClioz6eMmahjcWnUfklvd QwOWxWy/DIgvyUByqeI9CRTFrUQC9yfBxNVelzoSHgH4UADIbL1QJIcKDTnvjjIkAD1g F3c6dbi/33WluljG24zklcTb7L7et+y47g/EEok0iu/bUYI5Qugnaho08l1JtkjywsE8 f8soTh56p7phNuOx1sH8AbOUO0x0mA0vSYr6BKvGdyHw4OG+MI33FRrtp0Lk5bDygLeR FcvQ== X-Gm-Message-State: APjAAAUgufguZm/5yuwfVQR3p2XUq/nq35LM5Js74YQKaHuAqde1XaIk CBc6rx4YWL4UYdwrtQKGEpq9tLM12bC+JKW+W0k= X-Google-Smtp-Source: APXvYqxxghfIVP5n2J2Z/0gWMHXCD+f6L7U7Nyp0JludcuT8bADQvJimN9818nDEMFGj4GUa0yXk2+Ajx0r1Ut+xJyY= X-Received: by 2002:adf:e949:: with SMTP id m9mr5531386wrn.237.1554416429976; Thu, 04 Apr 2019 15:20:29 -0700 (PDT) MIME-Version: 1.0 References: <7D357986-AD33-4619-8037-8BCD59687AF0@gmail.com> In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 4 Apr 2019 15:20:18 -0700 Message-ID: To: Ben Schwartz Cc: Fred Baker , DoH WG Content-Type: multipart/alternative; boundary="00000000000024511b0585bbc7b6" Archived-At: Subject: Re: [Doh] gethostbyname? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 22:20:34 -0000 --00000000000024511b0585bbc7b6 Content-Type: text/plain; charset="UTF-8" At Tue, 26 Mar 2019 07:26:49 -0400, Ben Schwartz wrote: > Please avoid casting aspersions on other working group participants, even > in jest, as it might be misconstrued and cause offense. Perhaps the wording wasn't very appropriate, but I think it's generally a good practice to have any IETF work assume the use of IPv6. It's also consistent with the overall trend to IPv6-awareness in the IETF, e.g., as described in https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ The actual draft text doesn't seem to be so problematic in that sense: Browsers which cannot get the IP address(es) of the resolver configured by the operating system using APIs are still able to use an operating system function such as gethostbyname() or its equivalents to convert host names into IP addresses through the stub resolver in the operating system on which they are running. since it only refers to gethostbyname() as an example and also says "or its equivalents", and I also don't think the author lives in the previous century given that he was involved in the development of a modern DNS library; but I don't think changing gethostbyname() to getaddrinfo() (or at least gethostbyname2()) doesn't do any harm either, if it's not an improvement. I've just sent a pull request for this change on github: https://github.com/dohwg/draft-ietf-doh-resolver-associated-doh/pull/6 > > I have a silly question. In section 4, the draft goes to the API level to > > specify how to resolve a domain name. gethostbyname was deprecated in favor > > of getaddrinfo (and therefore IPv6 capability) in 1999 (RFC 2553), and is > > now found in all common OS's including Linux, FreeBSD, Windows, MacOSX, and > > so on. A reference to gethostbyname in this draft comes across as ignorant > > at best, perhaps deliberately so. > > > > What do we need to do to drag the authors into the current century? -- JINMEI, Tatuya --00000000000024511b0585bbc7b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Tue, 26 Mar 2019 07:26:49 -0400,
Be= n Schwartz <bemasc=3D40go= ogle.com@dmarc.ietf.org> wrote:

> Please avoid casting asp= ersions on other working group participants, even
> in jest, as it mi= ght be misconstrued and cause offense.

Perhaps the wording wasn'= t very appropriate, but I think it's
generally a good practice to ha= ve any IETF work assume the use of
IPv6.=C2=A0 It's also consistent = with the overall trend to IPv6-awareness
in the IETF, e.g., as described= in https= ://www.iab.org/2016/11/07/iab-statement-on-ipv6/

The actual draf= t text doesn't seem to be so problematic in that sense:

=C2=A0= =C2=A0 Browsers which cannot get the IP address(es) of the resolver
=C2= =A0=C2=A0 configured by the operating system using APIs are still able to u= se
=C2=A0=C2=A0 an operating system function such as gethostbyname() or = its
=C2=A0=C2=A0 equivalents to convert host names into IP addresses thr= ough the stub
=C2=A0=C2=A0 resolver in the operating system on which the= y are running.

since it only refers to gethostbyname() as an example= and also says
"or its equivalents", and I also don't thin= k the author lives in the
previous century given that he was involved in= the development of a
modern DNS library; but I don't think changing= gethostbyname() to
getaddrinfo() (or at least gethostbyname2()) doesn&#= 39;t do any harm
either, if it's not an improvement.=C2=A0 I've = just sent a pull request for
this change on github:
https://g= ithub.com/dohwg/draft-ietf-doh-resolver-associated-doh/pull/6

&g= t; > I have a silly question. In section 4, the draft goes to the API le= vel to
> > specify how to resolve a domain name. gethostbyname was= deprecated in favor
> > of getaddrinfo (and therefore IPv6 capabi= lity) in 1999 (RFC 2553), and is
> > now found in all common OS= 9;s including Linux, FreeBSD, Windows, MacOSX, and
> > so on. A re= ference to gethostbyname in this draft comes across as ignorant
> >= ; at best, perhaps deliberately so.
> >
> > What do we ne= ed to do to drag the authors into the current century?

--
JINMEI,= Tatuya
--00000000000024511b0585bbc7b6-- From nobody Thu Apr 4 15:47:31 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F656120273 for ; Thu, 4 Apr 2019 15:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co 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 r3p0bUpYwpa3 for ; Thu, 4 Apr 2019 15:47:26 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 E7F6212019A for ; Thu, 4 Apr 2019 15:47:25 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id v10so3432587iom.8 for ; Thu, 04 Apr 2019 15:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=XsISN9ARDGPJo+tgCRt2orvggva/4xgdYZnQnd4QlOw=; b=HswUedSkm5hpOlPJXNAImTFYW0ajNf8AwRjacllTqqxywq3s8czwUuobBG2i6nBzIs OVBZ4h2e8LnloVANFZrA7G3erOiNEpPZOsViOLa/OGjNNgF/lDXJR94ZD50zy62yS0Ml kfjPK+qSdJYANo3tMjPibC4IDxCEVIlutXj+4= 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:reply-to :from:date:message-id:subject:to:cc; bh=XsISN9ARDGPJo+tgCRt2orvggva/4xgdYZnQnd4QlOw=; b=pbPxgQL/rPB8n2/0x2C4pNKhPmRP0JvHKmgKUpmOp5YW9H3Pns2cBwGWX2EDYZTxbM q0zaPWRYf0cdoCsn0cMg8cprP/gguyj1EKXTBZQq6E+ffkiJ+GtGem6Jr2twZlj92eE8 JwBFkaFzzHuGWRZDkZQ3FLSFMWWs8AFpPz2GWoyLUQYXK2++T5g60Jd0TiyCPJqpUnRW +m6oVxN3+HklY7MJGGAWZk9spQHtI5MvBREPELlkyyUtfW1IdWGEm2v5cVW+oyaTXdWY ArhwCK9SGxe+Vsa/il5CbzmaR4j53HxObo2wi9AxyxqaAWgea5C5dmS78PSjhC9Y98pd JFhQ== X-Gm-Message-State: APjAAAXTiCONNLJps3qSjgGwidN8TXLRmFy5SHrPmDz7nGC94dZDQ9kd avwDNl/518Ct5Xzm1ZhOC/QdHBevyM95RLrTI2Tr5g== X-Google-Smtp-Source: APXvYqyHb5/ouos9AoAf9tstrek79U4gWPhVgL4bUD/2DVSXKGDzyBEPi2Kx9c1yjXsptJeBKHZoGQ5ir6TB9yxqdn0= X-Received: by 2002:a6b:b258:: with SMTP id b85mr6044761iof.122.1554418044856; Thu, 04 Apr 2019 15:47:24 -0700 (PDT) MIME-Version: 1.0 References: <7D357986-AD33-4619-8037-8BCD59687AF0@gmail.com> In-Reply-To: Reply-To: ek@loon.co From: Erik Kline Date: Thu, 4 Apr 2019 15:47:13 -0700 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Ben Schwartz , DoH WG , Fred Baker Content-Type: multipart/alternative; boundary="00000000000065bf8e0585bc2740" Archived-At: Subject: Re: [Doh] gethostbyname? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 22:47:30 -0000 --00000000000065bf8e0585bc2740 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 4 Apr 2019 at 15:20, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 26 Mar 2019 07:26:49 -0400, > Ben Schwartz wrote: > > > Please avoid casting aspersions on other working group participants, ev= en > > in jest, as it might be misconstrued and cause offense. > > Perhaps the wording wasn't very appropriate, but I think it's > generally a good practice to have any IETF work assume the use of > IPv6. It's also consistent with the overall trend to IPv6-awareness > in the IETF, e.g., as described in > https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ > > The actual draft text doesn't seem to be so problematic in that sense: > > Browsers which cannot get the IP address(es) of the resolver > configured by the operating system using APIs are still able to use > an operating system function such as gethostbyname() or its > equivalents to convert host names into IP addresses through the stub > resolver in the operating system on which they are running. > > since it only refers to gethostbyname() as an example and also says > "or its equivalents", and I also don't think the author lives in the > previous century given that he was involved in the development of a > modern DNS library; but I don't think changing gethostbyname() to > getaddrinfo() (or at least gethostbyname2()) doesn't do any harm > either, if it's not an improvement. I've just sent a pull request for > this change on github: > https://github.com/dohwg/draft-ietf-doh-resolver-associated-doh/pull/6 > > You could even add a reference to rfc3493#section-6.1, I would think. --00000000000065bf8e0585bc2740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 4 Apr 2019 a= t 15:20, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> wrote:
At Tue, 26 M= ar 2019 07:26:49 -0400,
Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org&= gt; wrote:

> Please avoid casting aspersions on other working gro= up participants, even
> in jest, as it might be misconstrued and caus= e offense.

Perhaps the wording wasn't very appropriate, but I th= ink it's
generally a good practice to have any IETF work assume the = use of
IPv6.=C2=A0 It's also consistent with the overall trend to IP= v6-awareness
in the IETF, e.g., as described in https://www.iab= .org/2016/11/07/iab-statement-on-ipv6/

The actual draft text doe= sn't seem to be so problematic in that sense:

=C2=A0=C2=A0 Brows= ers which cannot get the IP address(es) of the resolver
=C2=A0=C2=A0 con= figured by the operating system using APIs are still able to use
=C2=A0= =C2=A0 an operating system function such as gethostbyname() or its
=C2= =A0=C2=A0 equivalents to convert host names into IP addresses through the s= tub
=C2=A0=C2=A0 resolver in the operating system on which they are runn= ing.

since it only refers to gethostbyname() as an example and also = says
"or its equivalents", and I also don't think the auth= or lives in the
previous century given that he was involved in the devel= opment of a
modern DNS library; but I don't think changing gethostby= name() to
getaddrinfo() (or at least gethostbyname2()) doesn't do an= y harm
either, if it's not an improvement.=C2=A0 I've just sent = a pull request for
this change on github:
h= ttps://github.com/dohwg/draft-ietf-doh-resolver-associated-doh/pull/6


You could even add a ref= erence to rfc3493#section-6.1, I would think.=C2=A0
--00000000000065bf8e0585bc2740-- From nobody Fri Apr 5 09:43:31 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD531205CC; Fri, 5 Apr 2019 09:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 hsuOi67sZ6a4; Fri, 5 Apr 2019 09:43:25 -0700 (PDT) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 7BBA312051F; Fri, 5 Apr 2019 09:43:24 -0700 (PDT) Received: by mail-yw1-xc32.google.com with SMTP id c4so2523208ywa.11; Fri, 05 Apr 2019 09:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S0ws1wmYsF4vt5xH9Iu4yvbM90SU6cSfDGjXi0YKhDg=; b=ZwTOPFroPbgoa6fO3+oltD2VTqs0br8n2L1Sk+pHqZhN47mbLg0DuawnWZ6MoMpXFT i42vpmc2YEqt72bxnEsvRPQowzbQ1xyIonpJnzExvvW2a0EPpgx1qtz6o/5IekFU7uCq id2ucuSAQp+Z+NVx++ZKhwuM+FcAumI9l7fvlM6NC74ePMoQSznF4EGvJFZj6U7z84LS 9FyErJgdB8/NH4wN0kJ9BEK0q1xoASyxyAPA0xR6Qs7sQchJTycrn1dqCRl8i/TqXVlg 1MvDME9h5/RAtt/QqkYNVLSiLbBARXBUSJtONdv+b3BgsL6cNsiuQo+Om1YNWql6c4B2 tagg== 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=S0ws1wmYsF4vt5xH9Iu4yvbM90SU6cSfDGjXi0YKhDg=; b=IFn9wb2Zahb3n5j0NZQM8lWHfojd8ZtJdMZMxhOoUQmbaPEfnNHDkGzDcp7IR4iK7h BHbPcZ9enkTH6UspJXqJd+L2yHuzh+feMU6izoB68EpHhMYI489Ad0oK6Vb6KiKFMGqe hgMEw5VTaxKnPa0BiWX6sOIqLsK1JqgcVWHF2l0dDwrQBpDIa4JHY+ZvP88upZofj4Ce 1nrlKnH3IcmVLoTIahSbju70M47cKaUSu1h+zwgzhYp71mRZhpJePH1dLzrJibA/gT2f vEAq3DBrDXxT87zrIhAa4uhZ1uTFv+Kw2+ASlisxdykmp73igCw7j7VDv5cMxtjtpqdF lDtg== X-Gm-Message-State: APjAAAU6ImZuhOiaJOCGuwZrwAJZqgBh04m/NrfSPvXOSiJ+JyZKDFqX LjQFnnS8y8xMeS9bc07osYDlkDW3PG9M3IRf3fk= X-Google-Smtp-Source: APXvYqxLwiEuWLHxCGIYSjJBcTFpL33jIVGBe9nC2LuVr6ayR6m2XC1o6vB7LA6k5yo3wa3PzIbpBddWuTWXPxkPamM= X-Received: by 2002:a81:3d17:: with SMTP id k23mr11405457ywa.266.1554482603382; Fri, 05 Apr 2019 09:43:23 -0700 (PDT) MIME-Version: 1.0 References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> In-Reply-To: From: william manning Date: Fri, 5 Apr 2019 09:43:12 -0700 Message-ID: To: nalini elkins Cc: Christian Huitema , doh@ietf.org, Vittorio Bertola , dnsop , dns-privacy@ietf.org, "Ackermann, Michael" , Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000625c190585cb2f8e" Archived-At: Subject: Re: [Doh] [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 16:43:29 -0000 --000000000000625c190585cb2f8e Content-Type: text/plain; charset="UTF-8" Every now and then, Paul Vixie and I are in complete harmony. In my current slot, we are one of thousands of entities that are being held accountable to a series of regulatory requirements that have significant fiscal impacts on the exfiltration of private/patient data. We are starting to focus on three distinct areas to reduce the impact that DOH presents to our security posture. 1) In contractual/proccurement language. We have some "Must have" items and now we will have "Must not" items. 2) There are at least two technical options for tracking/blocking DOH which are being turned into turnkey options to "swat" this covert C&C channel. 3) Aggressive Browser Hygiene. This genie has not signed BAA or supplier agreement with us and we will not allow it to dictate our business processes or affect our liability without the DOH enabler shouldering fiscal and legal exposure when DOH is shown to be the culprit in exposure of private data. I can't see how DOH is going to pass GDRP muster inside the EU either, but that is for others to debate. I have told my GDRP affected counterparts about the privacy risks with DOH deployment. as usual, YMMV. /William Manning On Sun, Mar 10, 2019 at 8:26 PM nalini elkins wrote: > > Similarly, putting DNS in user space allows for immediate adoption of > DNSSEC and privacy enhancements, even when the operating system or the > local network does not support them > > At enterprises (banks, insurance, etc) on their internal networks, people > run their own DNS servers which may resolve for both internal and external > sites. > > We were recently talking to a Fortune 50 company in the United States > about what might happen you install a version of the browser which uses > DNS-over-HTTPS automatically. (Clearly, this applies to any variant.) > > The questions that the Fortune 50 company architect asked were something > like this: > > 1. You mean that DNS could be resolved outside my enterprise? > > 2. So whoever that is that resolves my DNS sees the pattern and frequency > of what sites my company goes to? > > 3. How do I change this? > > I look forward to a discussion on this issue.. There will be at least > one enterprise present in Prague to speak for themselves. I will see if I > can get others to participate remotely. > > It would be good to also discuss how to warn enterprises that this is > about to happen. I wonder if an announcement via CERT or another group > may be appropriate. > > Thanks, > Nalini > > On Mon, Mar 11, 2019 at 6:36 AM Christian Huitema > wrote: > >> >> On 3/10/2019 4:07 PM, Vittorio Bertola wrote: >> > Honestly, I understood it differently - at this point in time they are >> > doing tests on whether their resolver performs better or worse than >> > the system's one, but their announced model is that Firefox will adopt >> > a DoH resolver (though it's unclear how it will be chosen) and it will >> > just use that one. But if people from Mozilla could make a clearer >> > announcement on what their plans currently are, that would be good. >> > Still, most of the issues arise whenever an application, for whatever >> > reason and under any mechanism, starts to use one or more resolvers >> > different than the one set up in the operating system: even if it used >> > more than one, you would still get many of the issues listed in the >> > document (though, if it used more than one at the same time, I think >> > you'd actually also get some new specific issues, so we'd need to add >> > a discussion of this possibility). >> >> >> Your view of operating systems and applications is firmly rooted in >> history, which is another way to say in the past. The evolution in the >> past years points to a systematic deconstruction of that relation, with >> for example virtual machine, containers, or the trend to move network >> stacks out of the operating system and into the application. This is >> pretty obvious for security stacks, but it is also becoming very clear >> with QUIC and transport stacks. There are two big drivers: portability, >> and rapid adoption of innovation. These two drivers apply to DNS just >> like they apply to transport. >> >> Putting QUIC in application space allows for immediate provision of >> innovations like 0-RTT, head-of-queue blocking mitigation, or the better >> crypto of TLS 1.3. Similarly, putting DNS in user space allows for >> immediate adoption of DNSSEC and privacy enhancements, even when the >> operating system or the local network does not support them. That genie >> is not going back in the bottle any time soon. >> >> -- Christian Huitema >> >> >> _______________________________________________ >> dns-privacy mailing list >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy >> > > > -- > Thanks, > Nalini Elkins > President > Enterprise Data Center Operators > www.e-dco.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --000000000000625c190585cb2f8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Every now and then, Paul Vixie and I are in complete harmo= ny.=C2=A0 In my current slot, we are one of thousands of entities that are = being held accountable to a series of regulatory requirements that have sig= nificant fiscal impacts on the exfiltration of private/patient data.=C2=A0 = We are starting to focus on three distinct areas to reduce the impact that = DOH presents to our security posture.=C2=A0 1) In contractual/proccurement = language.=C2=A0 We have some "Must have" items and now we will ha= ve "Must not" items.=C2=A0 2) There are at least two technical op= tions for tracking/blocking DOH which are being turned into turnkey options= to "swat" this covert C&C channel.=C2=A0 3) Aggressive Brows= er Hygiene.=C2=A0

This genie has not signed BAA or suppl= ier agreement with us and we will not allow it to dictate our business proc= esses or affect our liability without the DOH enabler shouldering fiscal an= d legal exposure when DOH is shown to be the culprit in exposure of private= data.=C2=A0 I can't see how DOH is going to pass GDRP muster inside th= e EU either, but that is for others to debate.=C2=A0 I have told my GDRP af= fected counterparts about the privacy risks with DOH deployment.=C2=A0

as usual, YMMV.=C2=A0=C2=A0

/= William Manning=C2=A0

On Sun, Mar 10, 2019 at 8:26 PM nalini elkins &l= t;nalini.elkins@e-dco.com>= ; wrote:
=C2=A0> Similarly, putting DNS in user space = allows for=C2=A0immediate adoption of DNSSEC and privacy enhancements, even= when the=C2=A0operating system or the local network does not support them= =C2=A0=C2=A0

At enterprises (banks, insurance, etc) = on their internal networks, people run their own DNS servers which may reso= lve for both internal and external sites.

We = were recently talking to a Fortune 50 company in the United States about wh= at might happen you install a version of the browser which uses DNS-over-HT= TPS automatically.=C2=A0 (Clearly, this applies to any variant.)
=
The questions that the Fortune 50 company architect asked we= re something like this:

1. You mean that DNS could= be resolved outside my enterprise?

2. So whoever = that is that resolves my DNS sees the pattern and frequency of what sites m= y company goes to?

3. How do I change this?
<= /div>

I look forward to a discussion on this issue..=C2= =A0 =C2=A0 There will be at least one enterprise present in Prague to speak= for themselves.=C2=A0 I will see if I can get others to participate remote= ly.

It would be good to also discuss how to warn e= nterprises that this is about to happen.=C2=A0 =C2=A0I wonder if an announc= ement via CERT or another group may be appropriate.=C2=A0 =C2=A0
=
Thanks,
Nalini

On Mon, Mar 11, 2019 at = 6:36 AM Christian Huitema <huitema@huitema.net> wrote:

On 3/10/2019 4:07 PM, Vittorio Bertola wrote:
> Honestly, I understood it differently - at this point in time they are=
> doing tests on whether their resolver performs better or worse than > the system's one, but their announced model is that Firefox will a= dopt
> a DoH resolver (though it's unclear how it will be chosen) and it = will
> just use that one. But if people from Mozilla could make a clearer
> announcement on what their plans currently are, that would be good. > Still, most of the issues arise whenever an application, for whatever<= br> > reason and under any mechanism, starts to use one or more resolvers > different than the one set up in the operating system: even if it used=
> more than one, you would still get many of the issues listed in the > document (though, if it used more than one at the same time, I think > you'd actually also get some new specific issues, so we'd need= to add
> a discussion of this possibility).


Your view of operating systems and applications is firmly rooted in
history, which is another way to say in the past. The evolution in the
past years points to a systematic deconstruction of that relation, with
for example virtual machine, containers, or the trend to move network
stacks out of the operating system and into the application. This is
pretty obvious for security stacks, but it is also becoming very clear
with QUIC and transport stacks. There are two big drivers: portability,
and rapid adoption of innovation. These two drivers apply to DNS just
like they apply to transport.

Putting QUIC in application space allows for immediate provision of
innovations like 0-RTT, head-of-queue blocking mitigation, or the better crypto of TLS 1.3. Similarly, putting DNS in user space allows for
immediate adoption of DNSSEC and privacy enhancements, even when the
operating system or the local network does not support them. That genie
is not going back in the bottle any time soon.

-- Christian Huitema


_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.= org
https://www.ietf.org/mailman/listinfo/dns-privacy


--
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--000000000000625c190585cb2f8e-- From nobody Sat Apr 6 11:04:29 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D827B120343; Sat, 6 Apr 2019 11:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jkB8Fx75oGST; Sat, 6 Apr 2019 11:04:15 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 3AB9D120088; Sat, 6 Apr 2019 11:04:15 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id p14so7844208ljg.5; Sat, 06 Apr 2019 11:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=b6Euf47XWEtl5GAq60AgnEDxFTNZPhVd490lCln0jUk=; b=LN+T1zbNQuAl0GqjuPEWx/NQaEO/PBPSp0VbT7NddHlYaAZ++gR9P4Dt34IuVwvDQm ufKuE7zwXtVHOm5jcuN9i88rLLIgY1yvoFmgFV4nx4IWyJZmlX/y4V0MLetXneTcU5LT JxFqOuhAKSWNT1UQ8Cv0ote4MdeUUuzxyvb4YLYhhb88wQNuRxcjzRTmyZcB/22CYsap yfgdY0u5hHUCWSwfo9DWl5xTmsIfnbnZfOkDcRvNni6xF+/zRPc7iefMl/dprQTD8riE CT/IVOtn4pWmyszmIdIMvYRndiY26KwIRZBgwr3QsYFSJ05zMTAfmVGnO40cfbtS34Or YBRg== 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:content-transfer-encoding; bh=b6Euf47XWEtl5GAq60AgnEDxFTNZPhVd490lCln0jUk=; b=bJ+ovIvSRSbJvIQ3b8TFnd+EMVjCvCPvuKyP+pCKtPuHfF7DsuFXayXoaKMmJ5f0xZ mw3mkXcpkVIzK/lPU+nGarePwyzAJUOJKSOYRiS12ZTdO2WUOi7oUbIRxcWgypipfypV fEunB0BnY0AzhnmE2ThNVGROlarc7wLK4sgyAw4nUe4K/gTdJ/R/4Y9fNn0TDljl9hOU FRgjVwI/CFE/+ts1gnuhPSo7XkuLKDI1Ov32ZcdQkN8p1hCDqA8Gp8FGtlgYcLebxmCM 7S9UQnlngXHkJ7XWWWVI528zntUy7ecxGkkailaCKRmm/h0JWb+JAOcVvW4LJAqkYwa7 vmdA== X-Gm-Message-State: APjAAAUa4B0jlu8fjr1YNnl0gidydSS3dgRF1xrNQgADE4ei5YDr1xfk 2Eb8w9OpntZ4ToeUPO6zORxa0wENMvleo7wHIgj3jQ== X-Google-Smtp-Source: APXvYqz5TA+Qyj1nTKlFR+ZikOUV6gnbg2vpP8wbaIG+2T4ep0esVRAPO9h+6r5tKNP4REcvQhBaDnOF+iBEG0hltks= X-Received: by 2002:a2e:b016:: with SMTP id y22mr11162525ljk.133.1554573853392; Sat, 06 Apr 2019 11:04:13 -0700 (PDT) MIME-Version: 1.0 References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> In-Reply-To: From: Watson Ladd Date: Sat, 6 Apr 2019 11:04:01 -0700 Message-ID: To: william manning Cc: nalini elkins , Stephen Farrell , doh@ietf.org, dnsop , Christian Huitema , dns-privacy@ietf.org, Vittorio Bertola , "Ackermann, Michael" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 18:04:19 -0000 On Fri, Apr 5, 2019 at 9:45 AM william manning wrote: > > Every now and then, Paul Vixie and I are in complete harmony. In my curr= ent slot, we are one of thousands of entities that are being held accountab= le to a series of regulatory requirements that have significant fiscal impa= cts on the exfiltration of private/patient data. We are starting to focus = on three distinct areas to reduce the impact that DOH presents to our secur= ity posture. 1) In contractual/proccurement language. We have some "Must = have" items and now we will have "Must not" items. 2) There are at least t= wo technical options for tracking/blocking DOH which are being turned into = turnkey options to "swat" this covert C&C channel. 3) Aggressive Browser H= ygiene. > > This genie has not signed BAA or supplier agreement with us and we will n= ot allow it to dictate our business processes or affect our liability witho= ut the DOH enabler shouldering fiscal and legal exposure when DOH is shown = to be the culprit in exposure of private data. I can't see how DOH is goin= g to pass GDRP muster inside the EU either, but that is for others to debat= e. I have told my GDRP affected counterparts about the privacy risks with = DOH deployment. You know you can just turn it off the same way you configure your devices on your network. I also don't understand the GDRP issue you raise: surely all DNS services have the same problems. I'm more than happy to show you how to click the checkbox to turn it off in Firefox. In fact there is a checkbox you need to click to turn it on, and you can customize it at will. (I literally just checked) > as usual, YMMV. > > /William Manning > > On Sun, Mar 10, 2019 at 8:26 PM nalini elkins w= rote: >> >> > Similarly, putting DNS in user space allows for immediate adoption of= DNSSEC and privacy enhancements, even when the operating system or the loc= al network does not support them >> >> At enterprises (banks, insurance, etc) on their internal networks, peopl= e run their own DNS servers which may resolve for both internal and externa= l sites. >> >> We were recently talking to a Fortune 50 company in the United States ab= out what might happen you install a version of the browser which uses DNS-o= ver-HTTPS automatically. (Clearly, this applies to any variant.) >> >> The questions that the Fortune 50 company architect asked were something= like this: >> >> 1. You mean that DNS could be resolved outside my enterprise? >> >> 2. So whoever that is that resolves my DNS sees the pattern and frequenc= y of what sites my company goes to? >> >> 3. How do I change this? >> >> I look forward to a discussion on this issue.. There will be at least= one enterprise present in Prague to speak for themselves. I will see if I= can get others to participate remotely. >> >> It would be good to also discuss how to warn enterprises that this is ab= out to happen. I wonder if an announcement via CERT or another group may = be appropriate. >> >> Thanks, >> Nalini >> >> On Mon, Mar 11, 2019 at 6:36 AM Christian Huitema = wrote: >>> >>> >>> On 3/10/2019 4:07 PM, Vittorio Bertola wrote: >>> > Honestly, I understood it differently - at this point in time they ar= e >>> > doing tests on whether their resolver performs better or worse than >>> > the system's one, but their announced model is that Firefox will adop= t >>> > a DoH resolver (though it's unclear how it will be chosen) and it wil= l >>> > just use that one. But if people from Mozilla could make a clearer >>> > announcement on what their plans currently are, that would be good. >>> > Still, most of the issues arise whenever an application, for whatever >>> > reason and under any mechanism, starts to use one or more resolvers >>> > different than the one set up in the operating system: even if it use= d >>> > more than one, you would still get many of the issues listed in the >>> > document (though, if it used more than one at the same time, I think >>> > you'd actually also get some new specific issues, so we'd need to add >>> > a discussion of this possibility). >>> >>> >>> Your view of operating systems and applications is firmly rooted in >>> history, which is another way to say in the past. The evolution in the >>> past years points to a systematic deconstruction of that relation, with >>> for example virtual machine, containers, or the trend to move network >>> stacks out of the operating system and into the application. This is >>> pretty obvious for security stacks, but it is also becoming very clear >>> with QUIC and transport stacks. There are two big drivers: portability, >>> and rapid adoption of innovation. These two drivers apply to DNS just >>> like they apply to transport. >>> >>> Putting QUIC in application space allows for immediate provision of >>> innovations like 0-RTT, head-of-queue blocking mitigation, or the bette= r >>> crypto of TLS 1.3. Similarly, putting DNS in user space allows for >>> immediate adoption of DNSSEC and privacy enhancements, even when the >>> operating system or the local network does not support them. That genie >>> is not going back in the bottle any time soon. >>> >>> -- Christian Huitema >>> >>> >>> _______________________________________________ >>> dns-privacy mailing list >>> dns-privacy@ietf.org >>> https://www.ietf.org/mailman/listinfo/dns-privacy >> >> >> >> -- >> Thanks, >> Nalini Elkins >> President >> Enterprise Data Center Operators >> www.e-dco.com >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Apr 6 11:30:48 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A386012007C for ; Sat, 6 Apr 2019 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 DlY-iRwOabWK for ; Sat, 6 Apr 2019 11:30:45 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB79D12007A for ; Sat, 6 Apr 2019 11:30:44 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 00EEA242109D; Sat, 6 Apr 2019 18:30:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Sat, 6 Apr 2019 19:30:34 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> To: Watson Ladd X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 18:30:47 -0000 > On 6 Apr 2019, at 19:04, Watson Ladd wrote: >=20 > You know you can just turn it off the same way you configure your > devices on your network. I also don't understand the GDRP issue you > raise: surely all DNS services have the same problems. Read this: = https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the= -general-data-protection-regulation-gdpr/consent/what-is-valid-consent If you need further advice on GDPR, consult a Data Protection Authority = or a lawyer who specialises in this field. Note that the cast of thousands has been trimmed and this new thread is = not cross-posted to other WG lists. From nobody Sat Apr 6 11:54:08 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDBB120091 for ; Sat, 6 Apr 2019 11:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 4_ee_zOYhunv for ; Sat, 6 Apr 2019 11:54:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFD412002E for ; Sat, 6 Apr 2019 11:54:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D5957BE56; Sat, 6 Apr 2019 19:53:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83KrsiuCAyOC; Sat, 6 Apr 2019 19:53:54 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4E964BE53; Sat, 6 Apr 2019 19:53:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554576834; bh=30UuMZ+AL25bKV+vieFgSL0LCM2M1EMrM2tE77zYbps=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KLlEo6SrAuk7C/7naEpYq4bXcXwJiLZnw84Y3LLN3Nkdjed7X/U9yBrE9YLUCjela AW5g9LfJvxXJsaIPCANpvIwvq1kCvCpyynSNDlwdyCEEYzWKg39zc8+sOvGfXKAG6c stYBNSDOWQDJTPdy0uToKhOm7ZDqSYK1S9i+mlO8= To: Jim Reid , Watson Ladd Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> Date: Sat, 6 Apr 2019 19:53:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cyt32vAEsH3SZzzaoVmz4vmCXOvQhzDKq" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 18:54:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cyt32vAEsH3SZzzaoVmz4vmCXOvQhzDKq Content-Type: multipart/mixed; boundary="v6vevj0jG8eQ57EPuDU3yrq7krLAfMmbO"; protected-headers="v1" From: Stephen Farrell To: Jim Reid , Watson Ladd Cc: DoH WG Message-ID: <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> In-Reply-To: <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> --v6vevj0jG8eQ57EPuDU3yrq7krLAfMmbO Content-Type: multipart/mixed; boundary="------------714842E621A15B29727D7334" Content-Language: en-GB This is a multi-part message in MIME format. --------------714842E621A15B29727D7334 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, On 06/04/2019 19:30, Jim Reid wrote: >=20 >=20 >> On 6 Apr 2019, at 19:04, Watson Ladd >> wrote: >>=20 >> You know you can just turn it off the same way you configure your=20 >> devices on your network. I also don't understand the GDRP issue >> you raise: surely all DNS services have the same problems. >=20 > Read this:=20 > https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-= the-general-data-protection-regulation-gdpr/consent/what-is-valid-consent= Too much text there for me sorry:-) FWIW, I also don't get the GDPR angle here. If it's meant as an issue of consent related to selection of DNS server, ISTM more or less the same - if by picking an ISP I'm supposed to have consented to the ISP's choice of recursive that same argument seems to apply for a browser-chosen recursive since the user chose the browser. (And I'd actually argue there is no valid consent as to choice of recursive in either case, since IMO a person cannot consent to use of something they don't know exists, and people in general do not know that DNS recursives exist.) So can you explain the specific GDPR-related issue that you think is relevant? Thanks, S. > > If you need further advice on GDPR, consult a Data Protection > Authority or a lawyer who specialises in this field. >=20 > Note that the cast of thousands has been trimmed and this new thread > is not cross-posted to other WG lists. >=20 >=20 > _______________________________________________ Doh mailing list=20 > Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh >=20 --------------714842E621A15B29727D7334 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------714842E621A15B29727D7334-- --v6vevj0jG8eQ57EPuDU3yrq7krLAfMmbO-- --cyt32vAEsH3SZzzaoVmz4vmCXOvQhzDKq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyo9cEACgkQWrL68XsX K+ocog//TyIxNfdmg58/4Lvbbh6Hhv0MTq+FLs4X8QsNeD2SOwLfl13RjTpcKI0y YE6ZoMIV9hYywovK80+b0tiCZTk7rSLVLo4kP0O5ylEiL/tA3K93WqW7daufRGIt Yhe6SdkZupgn+vp2SVDONgQI/7QhvqFPsLbe/De1CxOexk82wZWYgxYTwEx+t+vD UOoVF9xKzeC/taSxtIdmaiJ4ptVKyJbo17SkRNJD5d+34jCDFWUEHfkD7GilWwwp 2CHn+rFXdO9ri+mrA4O+3fNc9SO72E1dIQG2fkAx3eL5+KIpHsYl5jXno0HBlYT1 gGUDNdCxiltvmizEf6fEk+J0M2LqFrhUUG/SOLfhLw/t51SWsgJwHIdOlIGtHG+9 ki2IbEq27IXkdQTDj2+SvhW2Ko7m8ATxEcy/tJPHSr2gNCtpwZ2MxIr0dsTG8YiU 85kw5ary0mpcaLEr7fFLuzDikZEChugSCq/vR1Mjla2n0ymVmZGNJ6cTy43J23Ow YmvoMvWdCch+GAPqUwer2uSZle8dcQ7W5w2yxD/63gX+3ST934QXHMJuPMYWYvTt WfiJD3mTTEUasGf6oAwPm363afQuvav76h85D9oVF0889be7noynUX6ytKqE4yZH Za20ZIfGxcmNyq4ZZXLXXKmLC4o8LpVAkf2F96NExbLhM1In1S8= =Tje5 -----END PGP SIGNATURE----- --cyt32vAEsH3SZzzaoVmz4vmCXOvQhzDKq-- From nobody Sat Apr 6 12:41:03 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A7F120321 for ; Sat, 6 Apr 2019 12:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0Dotk9GCen-2 for ; Sat, 6 Apr 2019 12:41:00 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 53228120353 for ; Sat, 6 Apr 2019 12:41:00 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id e6so4906517pgc.4 for ; Sat, 06 Apr 2019 12:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U2C7FOuzn94rJGNtp+ozDwhCZLNHR/5i1I6WoPLNHWU=; b=s7GS3KNJBZz1yF4qD0vHZ2ZQlfKejQZICP8qh7hAEDM59egSQfDEvOO+c7WR5qzIZD GHGg3H0rcFY4IRc5Rf7econS3jvbJCZZUOAPUt9w/VXiNqLBp7gzYftJ8D4ghrebBGLp Wwnl2/2z3ZVw4Q6gv2ROb08Bo3BzTFh7x9BheEe4OH76EBUJdhcOeZN0HVMpHHjnoS3w PU6/LuDOCHrXPQTijhKeSjIVCeujQh8nndT4UQcwh9CrEROfA4xsROrBhF0ks3KJx4Tt 5Obloo/euM8ngucigXib0qrhYG6taCbWTvksUMlhYQukH4zFnlBu+afqNu1Ra1xyDkYO N/fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U2C7FOuzn94rJGNtp+ozDwhCZLNHR/5i1I6WoPLNHWU=; b=FVJc3uxwMMr8yoRcPO8vOCtWnudPAgMevCRf8OqqrTxpMCgyw87sawwK5ZB63PHGrU +IYrNbgC2Q7U8vRo/psU9rKVpq/ehLeYTWI0vWGO2t0s/MUO42iLnubD4lffsh8/Dyq+ lVO1Tl/IUo7ON6tvFkCOqhctjd/RfNj/sb6DKMlFzRNbjgD+f3Y/QxELgRctMbmzcMD2 S3ZJ/d1Ln55k5bSYm4XS/SERDovQiu+cOLt0GGABfn3mPybj5ChFzQXmlkQk/NgDLIGm N0XY6WNfE//pFj+Wa7IP24vQw0g2SdLU9c7swUuk8hEj84tbX1O1bBsnv+NvVm+E1SeD 9oZg== X-Gm-Message-State: APjAAAWXnCj3xawvMlv9fRaIpTx5j7y0YyQM34Hjt3DdlsYYF7BuMXuX wlIA07X5VbFxr2jJLN2OakQ= X-Google-Smtp-Source: APXvYqzmvXECzZImvU/2wUpmY31smsiOnCBdX7XMZdq2EJ6VXq/831h0iA0LwVrJeKN/34qRrNMRBQ== X-Received: by 2002:a63:2a8f:: with SMTP id q137mr18937894pgq.31.1554579659778; Sat, 06 Apr 2019 12:40:59 -0700 (PDT) Received: from ?IPv6:2601:646:8881:1fb4:a916:414e:bbe:b7b0? ([2601:646:8881:1fb4:a916:414e:bbe:b7b0]) by smtp.gmail.com with ESMTPSA id f63sm37002337pfc.180.2019.04.06.12.40.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Apr 2019 12:40:58 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-582ABB09-5A67-4565-A341-3B7BA9A2B31D Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (16E227) In-Reply-To: <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> Date: Sat, 6 Apr 2019 12:40:58 -0700 Cc: Jim Reid , Watson Ladd , DoH WG Content-Transfer-Encoding: 7bit Message-Id: References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 19:41:03 -0000 --Apple-Mail-582ABB09-5A67-4565-A341-3B7BA9A2B31D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Apr 6, 2019, at 11:53 AM, Stephen Farrell w= rote: >=20 >=20 > Hi Jim, >=20 >> On 06/04/2019 19:30, Jim Reid wrote: >>=20 >>=20 >>> On 6 Apr 2019, at 19:04, Watson Ladd >>> wrote: >>>=20 >>> You know you can just turn it off the same way you configure your=20 >>> devices on your network. I also don't understand the GDRP issue >>> you raise: surely all DNS services have the same problems. >>=20 >> Read this:=20 >> https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-th= e-general-data-protection-regulation-gdpr/consent/what-is-valid-consent >=20 > Too much text there for me sorry:-) >=20 > FWIW, I also don't get the GDPR angle here. If it's meant as > an issue of consent related to selection of DNS server, ISTM > more or less the same - if by picking an ISP I'm supposed to > have consented to the ISP's choice of recursive that same > argument seems to apply for a browser-chosen recursive since > the user chose the browser. (And I'd actually argue there is > no valid consent as to choice of recursive in either case, > since IMO a person cannot consent to use of something they > don't know exists, and people in general do not know that > DNS recursives exist.) >=20 > So can you explain the specific GDPR-related issue that you > think is relevant? >=20 Stephen,=20 It didn=E2=80=99t take me more than about 30 seconds of reading the linked a= rticle to get to the heart of the issue. It has to do with whether something that requires consent is a necessary par= t of the service or transaction. It has been clearly demonstrated that browsers do not have to provide DNS re= solution (since they have not done so for about 25 years). This means that requiring the user to use the browser=E2=80=99s selection of= DNS resolver, and implementing a DNS forwarder in the browser, would not be= covered by the general acceptance of the browser=E2=80=99s terms. In other w= ords, an extra level of informed user consent would be required for GDPR, an= d not accepting that second set of terms should not prevent the use of the b= rowser. Tying the two together would be a violation, at least as I understan= d it as explained by the link Jim provided. >>=20 >> If you need further advice on GDPR, consult a Data Protection >> Authority or a lawyer who specialises in this field. >>=20 +1 Brian= --Apple-Mail-582ABB09-5A67-4565-A341-3B7BA9A2B31D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent from my iPhone

On Apr 6, 2019, at 11:53= AM, Stephen Farrell <stephe= n.farrell@cs.tcd.ie> wrote:


Hi Jim,

On 06/04/2019 19:30, Jim Reid wrote:
=

On 6 Apr= 2019, at 19:04, Watson Ladd <wa= tsonbladd@gmail.com>
wrote:
<= /blockquote>

You know you can just turn it off the same way you configure yo= ur
devices on your network. I also don't understand the G= DRP issue
you raise: surely all DNS services have the same= problems.

Read this:
https://ico.org.uk/fo= r-organisations/guide-to-data-protection/guide-to-the-general-data-protectio= n-regulation-gdpr/consent/what-is-valid-consent
<= span>
Too much text there for me sorry:-)

FWIW, I also don't get the GDPR angle here. If it's meant as<= /span>
an issue of consent related to selection of DNS server, ISTM=
more or less the same - if by picking an ISP I'm supposed t= o
have consented to the ISP's choice of recursive that same<= /span>
argument seems to apply for a browser-chosen recursive since=
the user chose the browser. (And I'd actually argue there i= s
no valid consent as to choice of recursive in either case,=
since IMO a person cannot consent to use of something they<= /span>
don't know exists, and people in general do not know that
DNS recursives exist.)

So can= you explain the specific GDPR-related issue that you
think i= s relevant?


Stephen, 

It didn=E2=80=99t take me more tha= n about 30 seconds of reading the linked article to get to the heart of the i= ssue.

It has to do with whether something that requ= ires consent is a necessary part of the service or transaction.
It has been clearly demonstrated that browsers do not have to p= rovide DNS resolution (since they have not done so for about 25 years).

This means that requiring the user to use= the browser=E2=80=99s selection of DNS resolver, and implementing a DNS for= warder in the browser, would not be covered by the general acceptance of the= browser=E2=80=99s terms. In other words, an extra level of informed user co= nsent would be required for GDPR, and not accepting that second set of terms= should not prevent the use of the browser. Tying the two together would be a= violation, at least as I understand it as explained by the link Jim provide= d.



= If you need further advice on GDPR, consult a Data Protection<= br>
Authority or a lawyer who sp= ecialises in this field.


+1
<= div>
Brian
= --Apple-Mail-582ABB09-5A67-4565-A341-3B7BA9A2B31D-- From nobody Sat Apr 6 12:51:48 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E74120357 for ; Sat, 6 Apr 2019 12:51:45 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D2eKoL22Ghs7 for ; Sat, 6 Apr 2019 12:51:42 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 A812E120363 for ; Sat, 6 Apr 2019 12:51:41 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id l7so7962528ljg.6 for ; Sat, 06 Apr 2019 12:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t2kOqlWI6xO8sCSMNP4irnsoBpg/kvsvTibp5jBzCbY=; b=hR5nll91Pi9wPkMCEJq5PqtwBeF0ZuNyU+lRzpObxOUUmgOv1iLfqTfCyoO+xLAg5U jkF8y0Pku25uZfhGDDJcEQDmN8zjYhoRn9zoH1xJlo+QvnYDifbfizWBKfCFMp1DH3cH qiOXY7aEMgAI/GwbRsOZErqM9jtTqbLw1WpeZgorkclwXrQUYETLdGcXOV6IVv5m+HgU wHrsVqMQ5hvhyaYspKyG3PZyJVUiuk86KTN4twuT0njjwrOb13vKyJBjb7Bq8Ef9pn5r jsYM930wAuwvETlCI+EhGp6JaI0C27e3X8ossmXjwG5TcwLpqV/75Vtuz5tAiLBxFIM0 qXMw== 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=t2kOqlWI6xO8sCSMNP4irnsoBpg/kvsvTibp5jBzCbY=; b=tmtPLv1oPcKDZlgi9mvAGwSC6JviULiWKvsj3iS++q3CtBRbBJznRUSVC+FkAB382Q JQv9AbZt2/csJ0mC8LtWhNBFb5YaJZuaJVSxjl94733O0Jx6I5si6aNcyi70V+yMj6wz yx3m8ma9K4UB4gupsjX9isLTrI6E3cKdy0MDSxzBHN2BG1tFNzP0NkN/6H0s0CyHQ58T sviGXgG1enETuHQvqhn044f6Cv8484MFMJr3JH4DMvqo/CQBOUPhad5deZmGeEkE9f9x 9mSCw474EDTrkGIK9oJFImMD5+r6+W32WAScHvATcKuTWyggip0hyWJ2qkSHPyVG6C+y O7JA== X-Gm-Message-State: APjAAAUH0cqXNdZ1fRxHDDE2dqXebbl/SD0mCr9Fi1Z1+udD7Z/22Kdt ytx5ld/SI5lzfX3aW2MV1T6hGg2yaiCYq2vTlnF4hg== X-Google-Smtp-Source: APXvYqzskCSzKGrnTtQIpqctYtxag9ximJ3LqyNsIGQgQH3QNDCL9o3TpE1AO9UnGg2dA+R4mgDD3qQeV6nODtfbkCs= X-Received: by 2002:a2e:3c0a:: with SMTP id j10mr10723713lja.164.1554580299853; Sat, 06 Apr 2019 12:51:39 -0700 (PDT) MIME-Version: 1.0 References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> In-Reply-To: <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> From: Watson Ladd Date: Sat, 6 Apr 2019 12:51:27 -0700 Message-ID: To: Stephen Farrell Cc: Jim Reid , DoH WG Content-Type: multipart/alternative; boundary="0000000000008c355e0585e1ee30" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 19:51:46 -0000 --0000000000008c355e0585e1ee30 Content-Type: text/plain; charset="UTF-8" On Sat, Apr 6, 2019 at 11:53 AM Stephen Farrell wrote: > > > Hi Jim, > > On 06/04/2019 19:30, Jim Reid wrote: > > > > > >> On 6 Apr 2019, at 19:04, Watson Ladd > >> wrote: > >> > >> You know you can just turn it off the same way you configure your > >> devices on your network. I also don't understand the GDRP issue > >> you raise: surely all DNS services have the same problems. > > > > Read this: > > https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/consent/what-is-valid-consent > > Too much text there for me sorry:-) > > FWIW, I also don't get the GDPR angle here. If it's meant as > an issue of consent related to selection of DNS server, ISTM > more or less the same - if by picking an ISP I'm supposed to > have consented to the ISP's choice of recursive that same > argument seems to apply for a browser-chosen recursive since > the user chose the browser. (And I'd actually argue there is > no valid consent as to choice of recursive in either case, > since IMO a person cannot consent to use of something they > don't know exists, and people in general do not know that > DNS recursives exist.) There seems to be a lot of confusion about what actually shipped. I just opened firefox. To use DoH I had to go to settings, change the settings, and select either the default resolver or put in a free form URL. By contrast joining a Wifi network on my phone changes my DNS settings with absolutely no involvement of my part whatsoever. I'm sure Mozilla has a general consul who has considered this carefully. > > So can you explain the specific GDPR-related issue that you > think is relevant? > > Thanks, > S. > > > > > > If you need further advice on GDPR, consult a Data Protection > > Authority or a lawyer who specialises in this field. > > > > Note that the cast of thousands has been trimmed and this new thread > > is not cross-posted to other WG lists. > > > > > > _______________________________________________ Doh mailing list > > Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh > > -- "Man is born free, but everywhere he is in chains". --Rousseau. --0000000000008c355e0585e1ee30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Apr 6, 2019 at 11:53 AM Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:
>
>
> Hi Jim,
>
> On 06/04/2019 19:30, Jim Reid wrote:
> >
> >
> >> On 6 Apr 2019, at 19:04, Watson Ladd <watsonbladd@gmail= .com>
> >> wrote:
> >>
> >> You know you can just turn it off the same way you configure = your
> >> devices on your network. I also don't understand the GDRP= issue
> >> you raise: surely all DNS services have the same problems. > >
> > Read this:
> > https://ic= o.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-da= ta-protection-regulation-gdpr/consent/what-is-valid-consent
>
> Too much text there for me sorry:-)
>
> FWIW, I also don't get the GDPR angle here. If it's meant as > an issue of consent related to selection of DNS server, ISTM
> more or less the same - if by picking an ISP I'm supposed to
> have consented to the ISP's choice of recursive that same
> argument seems to apply for a browser-chosen recursive since
> the user chose the browser. (And I'd actually argue there is
> no valid consent as to choice of recursive in either case,
> since IMO a person cannot consent to use of something they
> don't know exists, and people in general do not know that
> DNS recursives exist.)

There seems to be a lot of confusion about what actually shipped. I just op= ened firefox. To use DoH I had to go to settings, change the settings, and = select either the default resolver or put in a free form URL. By contrast j= oining a Wifi network on my phone changes my DNS settings with absolutely n= o involvement of my part whatsoever.

I'm sure Mozilla has a general consul who has considered this ca= refully.

>
> So can you explain the specific GDPR-related issue that you
> think is relevant?
>
> Thanks,
> S.
>
>
> >
> >=C2=A0 If you need further advice on GDPR, consult a Data Protecti= on
> > Authority or a lawyer who specialises in this field.
> >
> > Note that the cast of thousands has been trimmed and this new thr= ead
> > is not cross-posted to other WG lists.
> >
> >
> > _______________________________________________ Doh mailing list<= br> > > Doh@ietf.org https://www.ietf.org/mailma= n/listinfo/doh
> >



--
"Man is born free, but everywhere he is in chains".
--Rousseau.
--0000000000008c355e0585e1ee30-- From nobody Sat Apr 6 12:54:15 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1E7120363 for ; Sat, 6 Apr 2019 12:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 HlNT0jGq9DRw for ; Sat, 6 Apr 2019 12:54:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21BC120089 for ; Sat, 6 Apr 2019 12:54:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AF435BE56; Sat, 6 Apr 2019 20:54:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPGivG7k3R4Y; Sat, 6 Apr 2019 20:54:07 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 140A6BE50; Sat, 6 Apr 2019 20:54:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554580447; bh=lgVhmFlEhWroqqpDjgFvWz6m6qDLHU/S5WNQKF4CW7A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=g/mTyikHeIeXJhyKjsFqGOzMj2ed0QNH7aXUMv0sczGgoeZKxLfPHJ6HeK/o/tb2G +UHEFCJTW2EgCvsPbwuavaurSy9nZE6fO6lMSNQkL3q6BTYejlwCbnuZBiwqX65e62 VEMPOBVe7dgVCvPbNZFjQ5Qg7UafhdCfugFVwR28= To: Watson Ladd Cc: Jim Reid , DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <08c76ece-227b-7d0c-b864-9d0835f5f7a9@cs.tcd.ie> Date: Sat, 6 Apr 2019 20:54:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aEesPRK2Aq2lMwbWbF0wNNdq3VDEqdHJE" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 19:54:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aEesPRK2Aq2lMwbWbF0wNNdq3VDEqdHJE Content-Type: multipart/mixed; boundary="AW7BJttrmBxW8X4qG76qq4JIcUC3wg96i"; protected-headers="v1" From: Stephen Farrell To: Watson Ladd Cc: Jim Reid , DoH WG Message-ID: <08c76ece-227b-7d0c-b864-9d0835f5f7a9@cs.tcd.ie> Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> In-Reply-To: --AW7BJttrmBxW8X4qG76qq4JIcUC3wg96i Content-Type: multipart/mixed; boundary="------------DE3806B814C147CBE560CBBA" Content-Language: en-GB This is a multi-part message in MIME format. --------------DE3806B814C147CBE560CBBA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/04/2019 20:51, Watson Ladd wrote: > There seems to be a lot of confusion about what actually shipped. I jus= t > opened firefox. To use DoH I had to go to settings, change the settings= , > and select either the default resolver or put in a free form URL. By > contrast joining a Wifi network on my phone changes my DNS settings wit= h > absolutely no involvement of my part whatsoever. >=20 > I'm sure Mozilla has a general consul who has considered this carefully= =2E Yes. That was discussed on the list before. I guess maybe I should've been clear that I was questioning whether any GDPR issues were relevant, even if a browser did ship with DoH turned on by default. (Which to be fair, mozilla have said is something they'd like to do if they can.) Cheers, S. --------------DE3806B814C147CBE560CBBA Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------DE3806B814C147CBE560CBBA-- --AW7BJttrmBxW8X4qG76qq4JIcUC3wg96i-- --aEesPRK2Aq2lMwbWbF0wNNdq3VDEqdHJE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlypA94ACgkQWrL68XsX K+polA/9H84pht3TyIABJOgTsk/1uDnTzDgEJgWhKJ5hAz25MyAMBsh3nUI9kYAD XAoIeQtTX1JqG1WDU7oyogMR8ygYM+6S/PG7938HyVeUt4yyI78mDibX44Bf7FA5 mcOsBEc1+nwOyQqM06dh/WS+9HOkhwzus+fs4S/KXBc44WiBZ8DEdYpl9xNHX5KE pQRH9LuTmMOt1bsF4SCtHLoDEDddYxbYCGqqG3fnBdQEsQ3rbgfC89BzXBy/zW4y U3NxSWXZMZWxeGfXLL4Vbks6VPb0T84O3zcxcycNoLixr8kAnPTiCYQr4G4c1Mav CtjF/tN0muSUOG5fnvP1VGFOAC6lSfE2ezJmzSS7lsi3GdlO/iZ3EbxXmma4ooJW MScNSAWAVpqzxEWvmWqWsU5PDXy2zgS698+NH1WKeUI4Thnbm6FNe5L7bhSBGyIq EAEp0qS2dLe/hHC8jZ3P0lyxmJ/N2WnaOBsU5O23BIU8i8dCtOijwmGHSfZYohqh 0du7xRJRnoc3YB3bFROb7Xl4ZdOwmozLnRWUWHFvBFxNU+TdYdWOuL2APBqk+wUs lgkvQgcigQtpHunjZogU6bQC/5Bchhso3PxgMCPLv4Y4boiU7ftfpTgcf+EXWFAZ 8hwpkfqG5z1uB9H2uRjqV85xNmItBmmKhDaczevJGo9xUubAksw= =XmRo -----END PGP SIGNATURE----- --aEesPRK2Aq2lMwbWbF0wNNdq3VDEqdHJE-- From nobody Sat Apr 6 12:57:46 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6758A12036A for ; Sat, 6 Apr 2019 12:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gPjRpLCIIbDU for ; Sat, 6 Apr 2019 12:57:42 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 E67EB120369 for ; Sat, 6 Apr 2019 12:57:41 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id y6so4889651pll.13 for ; Sat, 06 Apr 2019 12:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mHvu0DvIKf+yCNsX8QyPfZNEHVC9lXp/1HWi/3/xr5w=; b=FLcIODap1PcigsoQFENSC8gR2gLaYWJ1smDc6X1tWW4bo+vl8GLg78ItI51QkN4ClH seJXM9U3+o73cLN4Dtt2lIhYWbAQNJP7hjIjpk8M0FGOgMtPZyO80nyU1sdMrBql5sVe +AlYAwfLvaghTaI4K2Np/3GNAPp4V1dLzbCAvBjuwwq0VWDjy0BTMB7JCdD38BPtXvyZ Wpg0nIc0NutCqIf61qTaqY3Ovw4QJJQGZVG+sw69eOv01+mYq7M1gsYBulzPq8wyLQ/5 DA6hx1UlneNQ+WvhAMPtF+E/E5LPQyHmul7TiqMFRsjn14zyNMXsK4upzZBzfOs4UA8l t0Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mHvu0DvIKf+yCNsX8QyPfZNEHVC9lXp/1HWi/3/xr5w=; b=HNbinN5FTsHmuvdV3HcR5z0S9gONUhUsn/yg/XxKZ7sjKaKw0Y8D/pvzf4EBc2QiCa 8lJnbiyiCe5aUquBemodaVVpin42VSvlSSIYII8Y969ylcrntYu0DztoCcg+EZRRL3zL 8QgoLA9nd3Q+P5bJER9YyD/dIU9WsyzU9kJP5cRldyRfCwJg1gIFgbEtSKELyjQJu8R7 WZr4SoLaTac5otVaJoB/dr8Qa5w2K+gLgUqSRmhVKy5b23pYoORZbRmMxAqp7txSt7Lm 70A/kly91woUo6Wb0xrfByHSQNvgb2u/BDYPZ5vL7JmBwlSS0XljbqhZ2XkKopor39mS X+6w== X-Gm-Message-State: APjAAAU78qRRBmeimkWGXaOwlOgOdHX0HRoyXWE9+90pwEoG8V3x01oM zKNdLtEBdDhsvwuRQIEiVcgcVnnw X-Google-Smtp-Source: APXvYqwlf0AYNHJHiUwo+Ggqj9kncMAgmS527bsjOhtuGaZ8DASYNB1h4E8nougFa7ilT+SCbVYoaw== X-Received: by 2002:a17:902:70c8:: with SMTP id l8mr20982392plt.177.1554580661391; Sat, 06 Apr 2019 12:57:41 -0700 (PDT) Received: from ?IPv6:2601:646:8881:1fb4:a916:414e:bbe:b7b0? ([2601:646:8881:1fb4:a916:414e:bbe:b7b0]) by smtp.gmail.com with ESMTPSA id f6sm22350747pgq.11.2019.04.06.12.57.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Apr 2019 12:57:40 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F78DD7FF-71A3-4B7C-801D-D70D6EEB95F1 Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Sat, 6 Apr 2019 12:57:40 -0700 Cc: DoH WG Content-Transfer-Encoding: 7bit Message-Id: <840A9DDA-DD95-421B-B330-2E0934ECD304@gmail.com> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 19:57:45 -0000 --Apple-Mail-F78DD7FF-71A3-4B7C-801D-D70D6EEB95F1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Resending Sent from my iPhone > On Apr 6, 2019, at 11:53 AM, Stephen Farrell w= rote: >=20 >=20 > Hi Jim, >=20 >> On 06/04/2019 19:30, Jim Reid wrote: >>=20 >>=20 >>> On 6 Apr 2019, at 19:04, Watson Ladd >>> wrote: >>>=20 >>> You know you can just turn it off the same way you configure your=20 >>> devices on your network. I also don't understand the GDRP issue >>> you raise: surely all DNS services have the same problems. >>=20 >> Read this:=20 >> https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-th= e-general-data-protection-regulation-gdpr/consent/what-is-valid-consent >=20 > Too much text there for me sorry:-) >=20 > FWIW, I also don't get the GDPR angle here. If it's meant as > an issue of consent related to selection of DNS server, ISTM > more or less the same - if by picking an ISP I'm supposed to > have consented to the ISP's choice of recursive that same > argument seems to apply for a browser-chosen recursive since > the user chose the browser. (And I'd actually argue there is > no valid consent as to choice of recursive in either case, > since IMO a person cannot consent to use of something they > don't know exists, and people in general do not know that > DNS recursives exist.) >=20 > So can you explain the specific GDPR-related issue that you > think is relevant? >=20 Stephen,=20 It didn=E2=80=99t take me more than about 30 seconds of reading the linked a= rticle to get to the heart of the issue. It has to do with whether something that requires consent is a necessary par= t of the service or transaction. It has been clearly demonstrated that browsers do not have to provide DNS re= solution (since they have not done so for about 25 years). This means that requiring the user to use the browser=E2=80=99s selection of= DNS resolver, and implementing a DNS forwarder in the browser, would not be= covered by the general acceptance of the browser=E2=80=99s terms. In other w= ords, an extra level of informed user consent would be required for GDPR, an= d not accepting that second set of terms should not prevent the use of the b= rowser. Tying the two together would be a violation, at least as I understan= d it as explained by the link Jim provided. >>=20 >> If you need further advice on GDPR, consult a Data Protection >> Authority or a lawyer who specialises in this field. >>=20 +1 Brian= --Apple-Mail-F78DD7FF-71A3-4B7C-801D-D70D6EEB95F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Resending

Sent from my iPhone


On Apr 6, 2019, at 11:53 AM, Stephen Farrell &= lt;stephen.farrell@cs.tcd.ie> wrote:

<= /span>
Hi Jim,

On 06/04/2019 19:30= , Jim Reid wrote:


On 6 Apr 2019, at 19:04, Watson= Ladd <watsonbladd@gmail.com= >
wrote:

You know y= ou can just turn it off the same way you configure your
d= evices on your network. I also don't understand the GDRP issue
<= span>you raise: surely all DNS services have the same problems.

Read this:
https://ico.org.uk/for-organisations/guide-t= o-data-protection/guide-to-the-general-data-protection-regulation-gdpr/conse= nt/what-is-valid-consent

T= oo much text there for me sorry:-)

FWIW, I a= lso don't get the GDPR angle here. If it's meant as
an issue= of consent related to selection of DNS server, ISTM
more or= less the same - if by picking an ISP I'm supposed to
have c= onsented to the ISP's choice of recursive that same
argument= seems to apply for a browser-chosen recursive since
the use= r chose the browser. (And I'd actually argue there is
no val= id consent as to choice of recursive in either case,
since I= MO a person cannot consent to use of something they
don't kn= ow exists, and people in general do not know that
DNS recurs= ives exist.)

So can you explain the specifi= c GDPR-related issue that you
think is relevant?
<= span>

Stephen, 
<= div>
It didn=E2=80=99t take me more than about 30 seconds of r= eading the linked article to get to the heart of the issue.

It has to do with whether something that requires consent is a nece= ssary part of the service or transaction.

It has be= en clearly demonstrated that browsers do not have to provide DNS resolution (= since they have not done so for about 25 years).

Th= is means that requiring the user to use the browser=E2=80=99s s= election of DNS resolver, and implementing a DNS forwarder in the browser, w= ould not be covered by the general acceptance of the browser=E2=80=99s terms= . In other words, an extra level of informed user consent would be required f= or GDPR, and not accepting that second set of terms should not prevent the u= se of the browser. Tying the two together would be a violation, at least as I= understand it as explained by the link Jim provided.


If you need furthe= r advice on GDPR, consult a Data Protection
Authority or a lawyer who specialises in this field.<= /span>


+1

Brian<= /div>
= --Apple-Mail-F78DD7FF-71A3-4B7C-801D-D70D6EEB95F1-- From nobody Sat Apr 6 12:58:43 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B073512036B for ; Sat, 6 Apr 2019 12:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 6xSb4szbYfSS for ; Sat, 6 Apr 2019 12:58:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80343120089 for ; Sat, 6 Apr 2019 12:58:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31F3DBE56; Sat, 6 Apr 2019 20:58:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNqHIGCD2E2G; Sat, 6 Apr 2019 20:58:36 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3BE4BBE50; Sat, 6 Apr 2019 20:58:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554580716; bh=meHPeZI9pL/wCxWCxWvImI4H64+/4ERhw8PDTzX7Af4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dWkNfMdM5wArUYYnnypHcCQoLnQ6S6pS2j+SK5SEKHLqoyFpFbKBJUZ/qTOQx2RHb U8PWNRqZkP9qtezZMY4B5ff1MGcFoq9VddZhFarFbUjRxg50etfzXtfSOZ0Zs/eje8 bBy9mv2zX4GRkGMWEE4qUc+vW0u3bWtyQ16VkHyM= To: Brian Dickson Cc: Watson Ladd , Jim Reid , DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> Date: Sat, 6 Apr 2019 20:58:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TMiJb1DS9aqHMVIbSXih3CNXa4Inmtkrv" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 19:58:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TMiJb1DS9aqHMVIbSXih3CNXa4Inmtkrv Content-Type: multipart/mixed; boundary="U00IXZnyPk1VIiWFPiirx8xQy47xuAsfr"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson Cc: Watson Ladd , Jim Reid , DoH WG Message-ID: <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> In-Reply-To: --U00IXZnyPk1VIiWFPiirx8xQy47xuAsfr Content-Type: multipart/mixed; boundary="------------21ACC5B3C8B82213FD913010" Content-Language: en-GB This is a multi-part message in MIME format. --------------21ACC5B3C8B82213FD913010 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 06/04/2019 20:40, Brian Dickson wrote: > It didn=E2=80=99t take me more than about 30 seconds of reading the lin= ked > article to get to the heart of the issue. If that's the heart of the issue, then I remain unconvinced that there is any real issue;-) IOW, I'm still none the wiser as to what GDPR issue is supposed to exist here. >=20 > It has to do with whether something that requires consent is a > necessary part of the service or transaction. Resolving DNS names is needed for a browser. > It has been clearly demonstrated that browsers do not have to provide > DNS resolution (since they have not done so for about 25 years). Sure. But they are allowed innovate. > This means that requiring the user to use the browser=E2=80=99s selecti= on of > DNS resolver, and implementing a DNS forwarder in the browser, would > not be covered by the general acceptance of the browser=E2=80=99s terms= =2E=20 I don't believe the above is a good argument. First, "requiring the user" isn't what's at issue, the situation of interest is where DoH is on by default (which is not the current scenario). Second, I've no idea what T&C's have to do with this - if there is a GDPR issue, then T&C's that nobody reads can't avoid that. S. > In > other words, an extra level of informed user consent would be > required for GDPR, and not accepting that second set of terms should > not prevent the use of the browser. Tying the two together would be a > violation, at least as I understand it as explained by the link Jim > provided. >=20 >=20 >>>=20 >>> If you need further advice on GDPR, consult a Data Protection=20 >>> Authority or a lawyer who specialises in this field. >>>=20 >=20 > +1 >=20 > Brian >=20 >=20 > _______________________________________________ Doh mailing list=20 > Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh >=20 --------------21ACC5B3C8B82213FD913010 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------21ACC5B3C8B82213FD913010-- --U00IXZnyPk1VIiWFPiirx8xQy47xuAsfr-- --TMiJb1DS9aqHMVIbSXih3CNXa4Inmtkrv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlypBOsACgkQWrL68XsX K+pyTA/+NC9myaHg+NI0ie/KnGfxsS9oLmjhIFRmBYv0cJz1SZACNkDX47MOeVNA 6GMZaZPzvDYB3BaklQ2S9BH6A75dBnD4iZGuUCGK+YSrzD712GArICytApymRdQb zam3GK8BfIlND0BCaLnnolXteMIRf8MHHyk7u/ERwUrFRV/OaX1P+7HT4uSIiHmB JiFAKjeUzPqdaEXTToTlXL2VO0TUXkcaLVZn3NIXapXip9EDFz0d+NUCC3ggTwXT CRxbecig3bn0Q5kpZyfc3ZjG7P/6MaR5mLgfTUJZCoZs2U51Bg//hvDUUqX4u7+w vJl7N7Zvj14SaNKhESWJX0NWGDlWhZIgmq3DZozcx6SakIkbPXbHzWTHlLZ2BLfn FHd0FNcW0eRXhIIsxSZ5Fh7POczeQOCkcuop6XG/hA81EbIFVARvl+oKDUCsso2c TZLTdc4+Kob8GfNBbkTUBy8NSTyCP9I7d85T4EG8s2KAF2zHASkkKUGLJm5WCoOo 9j+n037h0l6abGda2sv3FyiTlEArDAV+7RG4t9kSicEbNxWKfCDdz+eHIai65oFk wswWw5CBWxfoukr0XVHb8C8j/DlFSS8gVGlG13qIMozGjLN57KS8YoGy5fnZ2RCi YAfEyxRbdt+XflPaZvGXjCJ5FC9qXun2RmEGra7KvnFDxCtX3dk= =v2rr -----END PGP SIGNATURE----- --TMiJb1DS9aqHMVIbSXih3CNXa4Inmtkrv-- From nobody Sat Apr 6 13:13:17 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE69A120073 for ; Sat, 6 Apr 2019 13:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 755NJAYn6qw6 for ; Sat, 6 Apr 2019 13:13:13 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 AF2F5120046 for ; Sat, 6 Apr 2019 13:13:13 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id n8so355175plp.10 for ; Sat, 06 Apr 2019 13:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=revWTMDRhcspzSkoiNSowz0I1FWHT5Yyw/M/VmXv8XU=; b=LYL9W8fvxe1w10tU9ww1rakVk2L4yEMrFQXScpSQEb1Nh9OVVMZizQRzuwVZw3XbBH ZvpiD+oFJpdahKVGnIvBxDiKV+q41cjyphiQlG8T0X0u/IGhCb7exip4Lx4dIXmphUPf 6XBdrS0k7paMWdDUCRbFQQMkC3lnmX2exO4ffp2ZNLZZrD/X5oIbBvAzNcbQuweGgBai xI67ZnpzSzaxwNwxSLHA1GVDr8OsvP21znoKHGaRlwBE61D5LewwYDeNjSdo1VfZWyLi 418RHbZ5DiXxQsPJRS7iozDYgLn0ERakUixSo74VUxlu0kKtKcItIspQPf1QEhFs08dK i6bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=revWTMDRhcspzSkoiNSowz0I1FWHT5Yyw/M/VmXv8XU=; b=bhbsjJ0qjlNwL57JCmmmU2JSicwrJ96r/Srlxx1y72017tV8jotxlhvxaLAIv1PGq+ JrbihKe2C0FsMITA2KKom8pG+rseu7EM2GqJt5LcQX7WZErCWy9noibvilICsqqY2gGE q5RvkYHh8CAxo3vkk8DzcTEPJUgK7KvNIIKmYIKHcLnNiU0MU+eLgOn0IZuA49uGPfA1 pwfJqipVvTjqWUgwHAVsBVk+zFSb4yVDgXJB55+vWwNwNk74ZrqDbRUARBnXVVFy88tj PooRqeNzbmPY23VS7yZcYHg/7B9w2IgElHAAPiExRp81Q6qOvRSY8CkUULhM1kdqmL1E 797Q== X-Gm-Message-State: APjAAAViTT5xABwHyNjyc/Pm2u6VxGcDHtqZVpNUMRAt8wKK3M3Zq+cy mzAcpeTiEw6W6by8S+dxrXU= X-Google-Smtp-Source: APXvYqw4Oiq7H0O/WS07GNoH5QkXla7oayrCDTinQfzOU+HY68X8mKwY8Ew/1TaQJJOK10Rgl/f41w== X-Received: by 2002:a17:902:2ac3:: with SMTP id j61mr21086419plb.112.1554581593189; Sat, 06 Apr 2019 13:13:13 -0700 (PDT) Received: from ?IPv6:2601:646:8881:1fb4:a916:414e:bbe:b7b0? ([2601:646:8881:1fb4:a916:414e:bbe:b7b0]) by smtp.gmail.com with ESMTPSA id 143sm47527013pge.50.2019.04.06.13.13.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Apr 2019 13:13:12 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-BB96B046-F386-4569-8D65-81F1FD893C4C Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (16E227) In-Reply-To: <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> Date: Sat, 6 Apr 2019 13:13:11 -0700 Cc: DoH WG Content-Transfer-Encoding: 7bit Message-Id: References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 20:13:16 -0000 --Apple-Mail-BB96B046-F386-4569-8D65-81F1FD893C4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Apr 6, 2019, at 12:58 PM, Stephen Farrell w= rote: >=20 > Second, I've no idea what T&C's have to do with this - if there > is a GDPR issue, then T&C's that nobody reads can't avoid that. I believe that is what the GDPR issue is. You keep making this point for everyone else, not sure you realize that. =F0= =9F=98=80 In order for T&Cs to be applicable: they have to be read; the user has to un= derstand them; and has to agree to them. (Those are themselves nontrivial UI= issues.) So, unless it is possible to explain DNS resolver choice so that an ordinary= user can understand it, the user can=E2=80=99t give informed choice. =20 This implies that any app bypassing the system choice of resolver (notwithst= anding your concern over =E2=80=9Cchoice=E2=80=9D), at a minimum would need t= o attempt to do so, or clearly run afoul of GDPR. Whether that attempt clear= s the bar would likely be an issue for lawyers and courts. The ISP issue isn=E2=80=99t relevant. Two wrongs don=E2=80=99t make a right,= and bringing ISP DNS choice into this is deliberately conflating the issue,= IMNSHO. Brian= --Apple-Mail-BB96B046-F386-4569-8D65-81F1FD893C4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent from my iPhone

On Apr 6, 2019, at 12:58= PM, Stephen Farrell <stephe= n.farrell@cs.tcd.ie> wrote:

Second, I've no idea what T&C's have to do with thi= s - if there
is a GDPR issue, then T&C's that nobody rea= ds can't avoid that.

I believe that is= what the GDPR issue is.

You keep mak= ing this point for everyone else, not sure you realize that. =F0=9F=98=80

In order for T&Cs to be applicable: they have to b= e read; the user has to understand them; and has to agree to them. (Those ar= e themselves nontrivial UI issues.)

So, unless it i= s possible to explain DNS resolver choice so that an ordinary user can understand it, the user can=E2=80=99t give informed c= hoice.  

This implies that any app bypassing t= he system choice of resolver (notwithstanding your concern over =E2=80=9Ccho= ice=E2=80=9D), at a minimum would need to attempt to do so, or clearly run a= foul of GDPR. Whether that attempt clears the bar would likely be an issue f= or lawyers and courts.

The ISP issue isn=E2=80=99t r= elevant. Two wrongs don=E2=80=99t make a right, and bringing ISP DNS choice i= nto this is deliberately conflating the issue, IMNSHO.

<= div>Brian
= --Apple-Mail-BB96B046-F386-4569-8D65-81F1FD893C4C-- From nobody Sat Apr 6 14:23:32 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4984C1200A0 for ; Sat, 6 Apr 2019 14:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 sYRPAYGrccZs for ; Sat, 6 Apr 2019 14:23:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BB612006B for ; Sat, 6 Apr 2019 14:23:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 213FEBE56; Sat, 6 Apr 2019 22:23:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fvTVVVhet6y; Sat, 6 Apr 2019 22:23:24 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9931EBE53; Sat, 6 Apr 2019 22:23:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554585804; bh=qGk7fpCxFQJ1aqDzrKaMyV35TlfHK+qD/QjiT19TdPU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=1jWAIalSyyxsWDo8HhBdldm1mn0TmX6n5YfpLb7lazBn/uqHiUJg4SHumk+FSIb2A hw2QSjm/AvY7d/fTtUEpU1x0KRY5NRG0srNmF+s6UOH8nGNhigIKan8zdqLGEFP/za 2UIJo2aLNwMAn4paJ1nvpaE2zY9WrSI3mNq1aagM= To: Brian Dickson Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sat, 6 Apr 2019 22:23:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bRJeZFx9u3Ccn3gCkqn5lBaCa5iHzDwhp" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 21:23:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bRJeZFx9u3Ccn3gCkqn5lBaCa5iHzDwhp Content-Type: multipart/mixed; boundary="HKjwZumrXxylmL9ph5Eflk2zynJirwreL"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson Cc: DoH WG Message-ID: Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> In-Reply-To: --HKjwZumrXxylmL9ph5Eflk2zynJirwreL Content-Type: multipart/mixed; boundary="------------6A1D5D06F64EBECC4B138FEE" Content-Language: en-GB This is a multi-part message in MIME format. --------------6A1D5D06F64EBECC4B138FEE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/04/2019 21:13, Brian Dickson wrote: > The ISP issue isn=E2=80=99t relevant. Two wrongs don=E2=80=99t make a r= ight, and > bringing ISP DNS choice into this is deliberately conflating the > issue, IMNSHO. Ok, that's where we disagree then. I think both ISP or browser choices of DNS recursive are the same in terms of (lack of) real consent. That doesn't mean either or both are "wrong" but I think it does mean that there's no really new consent issue here. (And btw, it's not great that you accuse me of "deliberately conflating" - to do so would mean discussing this dishonestly, and I am not doing that - it might be stylish of you to retract that accusation.) S. --------------6A1D5D06F64EBECC4B138FEE Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------6A1D5D06F64EBECC4B138FEE-- --HKjwZumrXxylmL9ph5Eflk2zynJirwreL-- --bRJeZFx9u3Ccn3gCkqn5lBaCa5iHzDwhp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlypGMsACgkQWrL68XsX K+pFhA//c4oA4M+nhY+wQMvQZpquFR1uOCFJ0lnj496iTONn02K4xVuDpLsT7f8l 4YSJjiIdMhH//R8MGcegXUo6ouWlSHzHv1bvktDsDNpeSs1SvjjLaE7W/S7C4Flp jtz2u0jCgas4CQ1mF9x9Do1KwmpBYuNEsb0MgOpYOa+e1stO46mBKjfCzVGhtDUx m6Y0zLQJGqoD7UKe/nkZPR440Gwe6e2IxN21GwAJidtvjpDyLYOYkWt4sM//JJus FK5tB21BAazM2mmp56Nq3gsrwAU4M4a2rK3YXFQca31nPt/RGWrXNV4vI/Y6GCBM mspc/IqgREJOHoxrDLBo8UAduOPpu2rYZB/TOG1NltR1cUfe+g7REfi8S8ohzF+S E3RWXcA3L542UMBin6ZqO/ichJE9iHUF6SSVCtBLWPSy1rcgCvvVyXXbxqi5sr8c 1eCbZMkB5edSv2lGMtabWCPp36HZ1pB98gkK102IcCMKkhTJJ/xo4bh8DFjE/ep6 eV2hXqynIMA4mpjrC4lavFtI60VJuABLRH2uAcSUtREu1pHcwrErXXounL7DzxqP ixfBq6IZUtLPDvu+kufC9G+yoHJnKhEv4bD4rUF6wVcXUvGXgvU/DFg2Wb7P8tiU EviU3jpUQ51vaYMIw/74RmzqehnGVDBruPrF5tnQw4E/2h32dD8= =DMzZ -----END PGP SIGNATURE----- --bRJeZFx9u3Ccn3gCkqn5lBaCa5iHzDwhp-- From nobody Sat Apr 6 15:08:46 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8E8120075 for ; Sat, 6 Apr 2019 15:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ywQjIxR1SUZV for ; Sat, 6 Apr 2019 15:08:33 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 DCCC9120003 for ; Sat, 6 Apr 2019 15:08:33 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id b3so5310546pfd.1 for ; Sat, 06 Apr 2019 15:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VW7XKXyWvyzfFSp+Uc2tYcoJGd1wxsFoUMujYIVFIWY=; b=G4Rfs95R+pQcHwDud8GNi7+1Mi64dRMdgmpXn5dsakooSJ4C4Yt5HMkdPPLaFMr9pi kNiDR2mRMmN6NMP+NiBEQJM0yA+XUGwCfL+eXmuv8WwDXQ26SkgQzYP7zoNPflp7NHqs Hq9SUgggJXOONIauIgPfidEgOiRbjk5vzgmAAo1yLPCC55TovOax2eKTN/s/OeDnVtwi mt6kQjr9mXpLpeYmZn03VtuAQPiuS0Sg4qGiQ89jiJoqjlIV5ebldGc3trxcKD3vemwc E8fRnHHSgzvjmUZKy9Oa40TWSh5860Gp8NCBAr2AXhhShJeN3X0tXqMyy8L67fuNgIjE XPJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VW7XKXyWvyzfFSp+Uc2tYcoJGd1wxsFoUMujYIVFIWY=; b=nqtQ85fEr/TYYR1u2vBu0ARzU0S9cZw6Yv3pEWh4scYQhfxR4yU3jnsQjjvn+WVvoU 1kP2T+S134mIjEvHZCM+/WWJQHg91zLYgta9hAZN4RMbQ887jRmoAbO48/uigP5N0/JO xf5cVSup0KU0/PFUY8/Yul/LBeENRfuHVaL4lh6I74MoYnV2CS/w10ZU3V8HMjvVArDK cMluV3PZ4X16JPJvVYvbPXRzoq9lpWb8zbJJzFiUthM4gJUeVFeb85WW2q1gIsOHOBX4 e/EP7fkbABYqC0H4zTXo5ptwqQVdFSvuQZJLREco9eCx7XTCKm3PZ9LO1/4ogZBY7cSQ lXtw== X-Gm-Message-State: APjAAAWTeEJwd/51BokZ/63+rC4sMrgtZLhJcQl71VtBGOP/iXAjPgC4 bkZcZ8uwdMqeyfIhIeya9u1VuV2n X-Google-Smtp-Source: APXvYqwjkshBB5oneJSf7+mjlIflO1nekx6rZFiMjfzRUJWQpjqNzbjOKIWCQq7o7MSRnXoBFRBC5A== X-Received: by 2002:a63:4f52:: with SMTP id p18mr19662090pgl.333.1554588513318; Sat, 06 Apr 2019 15:08:33 -0700 (PDT) Received: from ?IPv6:2601:646:8881:1fb4:a805:6ffd:bde7:a00b? ([2601:646:8881:1fb4:a805:6ffd:bde7:a00b]) by smtp.gmail.com with ESMTPSA id v20sm38458076pfn.116.2019.04.06.15.08.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Apr 2019 15:08:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Sat, 6 Apr 2019 15:08:31 -0700 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 22:08:36 -0000 Sent from my iPhone > On Apr 6, 2019, at 2:23 PM, Stephen Farrell wr= ote: >=20 >=20 >=20 >> On 06/04/2019 21:13, Brian Dickson wrote: >> The ISP issue isn=E2=80=99t relevant. Two wrongs don=E2=80=99t make a rig= ht, and >> bringing ISP DNS choice into this is deliberately conflating the >> issue, IMNSHO. > Ok, that's where we disagree then. I think both ISP or > browser choices of DNS recursive are the same in terms > of (lack of) real consent. That doesn't mean either or > both are "wrong" but I think it does mean that there's > no really new consent issue here. The distinction is similar vs new. They may be similar or even identical, bu= t the browser one is very literally new. Regardless of how the system choice of resolver/stub is done, it preexists a= s a/the mechanism for DNS resolution. Making changes to that choice (regardl= ess of whether the previous choice was informed or explicit) IMHO requires a= dditional consent, and that is what is new. Lack of consent on the ISP does not justify, excuse, or convey implicit perm= ission for an app to bypass the consent issue.=20 Again, the above is MHO, but also, this consent problems is an issue that cr= osses over the line where leaving it unsettled by stating it is an issue we d= on=E2=80=99t agree to, does a disservice to the community of users of DNS. >=20 > (And btw, it's not great that you accuse me of "deliberately > conflating" - to do so would mean discussing this dishonestly, > and I am not doing that - it might be stylish of you to > retract that accusation.) >=20 It is possible to conflate things honestly, and=20 I apologize if you or anyone else may inferred otherwise. I withdraw the =E2= =80=9Cdeliberately=E2=80=9D from my previous statement, with apologies. Brian= From nobody Sat Apr 6 15:20:40 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CCB120003 for ; Sat, 6 Apr 2019 15:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 eqp1eC5aYLo2 for ; Sat, 6 Apr 2019 15:20:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4FB2B120075 for ; Sat, 6 Apr 2019 15:20:37 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x36MKT2M023151 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 6 Apr 2019 17:20:30 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554589231; bh=BQV52LAvBw6IFo4nL0GKoEL6je8/KHkf3XEgx4rj92g=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=cUkK6ZxwFdXNmXwwnHwk9O2h7/W4y8c5BRAEKzb7xqU4clUtkfHlCPg6Oy95RqC6K U/UYBDf1WyaGlnNyniI8XLMQaDLisn98BWITzPmWdsdpHJzvZ7FmGG6YP+7hWt3sgu VIhG0UH9iMdz6+80L9pxMqGmaKkF4zSsf9JOYmUc= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Brian Dickson , Stephen Farrell Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> From: Adam Roach Message-ID: <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> Date: Sat, 6 Apr 2019 17:20:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 22:20:39 -0000 On 4/6/19 5:08 PM, Brian Dickson wrote: > Again, the above is MHO, but also, this consent problems is an issue that crosses over the line where leaving it unsettled by stating it is an issue we don’t agree to, does a disservice to the community of users of DNS. Engineers and lawyers practice rather different professions, both of which require extensive training and experience. When all the dust settles, it really doesn't matter what *we* think on these topics, in much the same way that it's not terribly important what the American Bar Association might think about TCP window size management. Jim and Watson both wisely deferred, at least in the abstract, to legal experts. I advise that this is the proper tactic. /a From nobody Sat Apr 6 16:10:39 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0AC120167 for ; Sat, 6 Apr 2019 16:10:37 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kskMqbkil69d for ; Sat, 6 Apr 2019 16:10:34 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 A9494120096 for ; Sat, 6 Apr 2019 16:10:34 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id s15so3134303qtn.3 for ; Sat, 06 Apr 2019 16:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uzan6MJi9CKNdXthjPO2JC7+xGXyK+q1cp6Sbv41mvc=; b=UtjPAAfB9+vTnYiAIhBmvqtasaJHNpo4uv78rrvjtH3gkiy6EH3sninkKlDXUAl+Wi eFhDhAm05KhSJwRHnJVvVeCplPAB/HGtFZGZKUHKZXIcZShVDlb1UM/WouNSP3Vm0i4p 9McZ0IZWkr9bBRXabSAWmd3K+uB95vFWKYOVOOQRVuAMNsGjJPa3BiWUQMpmWCQpEGY1 CIXPU3n7gw3vO/HKF5q5+nh+2AaqUU+MQ68oakZ+CLBhXeIt5SY4ghhNlhPaN2njjyJF OMwkRwjj6pc+w1TaJKlhC+aegyX1MI31chH8PiN1gjJkeh40oljQ595A9rUmGYDTRMff vPhQ== 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=uzan6MJi9CKNdXthjPO2JC7+xGXyK+q1cp6Sbv41mvc=; b=rlGW5M8ygyOQKzxvkITJPZ280olOof0UVLEcsfN7FsDoAvkc8YG0jW4w4GtRwlPGbk A0plG1/ApSFqJ4HrPRz0zQrFjUTEz/wf7qYqT79nA+Ez+LYJt6MIH1DCqUFAo1TSWJOx WeQ1THzi6rQy9j7FKo3a4A6sQCp1/f+IXVor5um91ZT3rUCsVAPbZvWCzqK0iguCJh11 IHDKNA2ymYVW273TfS0WAc4GZE9DPufzkQiCv40X+9bJMSatAcGuHWKL1N9OWadEBLhV jHinCLbNdyUaHwexNH8Qp3UCp0EN58q+XSQ+Y2qwEVFuvctifcz7JswXcysjee6TULcH JNBg== X-Gm-Message-State: APjAAAUcMkWoXJmLc5/A4OO2Z7/FdH00Wqx7uM8An/FYk0KOoyT78oci puTHXMMZULTfpERz4d67KuNXGrm7AbYPvy/IIQQ= X-Google-Smtp-Source: APXvYqycpbUpolPvTQP0q8KDBnVDIjywts/4GcicsI8XtOF4Q/qFuNJDGTEqovlWni/6uZPv3dh395eQ5a5XsmUb3Zw= X-Received: by 2002:ac8:1a34:: with SMTP id v49mr17840869qtj.236.1554592233825; Sat, 06 Apr 2019 16:10:33 -0700 (PDT) MIME-Version: 1.0 References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> In-Reply-To: <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> From: Brian Dickson Date: Sat, 6 Apr 2019 16:10:22 -0700 Message-ID: To: Adam Roach Cc: Stephen Farrell , DoH WG Content-Type: multipart/alternative; boundary="000000000000de29550585e4b5d3" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 23:10:37 -0000 --000000000000de29550585e4b5d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 6, 2019 at 3:20 PM Adam Roach wrote: > On 4/6/19 5:08 PM, Brian Dickson wrote: > > Again, the above is MHO, but also, this consent problems is an issue > that crosses over the line where leaving it unsettled by stating it is an > issue we don=E2=80=99t agree to, does a disservice to the community of us= ers of DNS. > > > Engineers and lawyers practice rather different professions, both of > which require extensive training and experience. When all the dust > settles, it really doesn't matter what *we* think on these topics, in > much the same way that it's not terribly important what the American Bar > Association might think about TCP window size management. Jim and Watson > both wisely deferred, at least in the abstract, to legal experts. I > advise that this is the proper tactic. > Maybe, yes, and no. The problem in the above is the use of pronouns. :-) But seriously, there are multiple variations on the issue, where the need for lawyers, and/or the length and depth of those discussions, vary considerably. The possibilities I see include the following (and possibly others, such as DoT): - DoH is off by default, and the DoH server field is empty (requires explicit user entry) - DoH is off by default, and the DoH server field is a drop-down list plus "other" (user entered), with no selected choice - DoH is off by default, and the DoH server field is a drop-down list or user-entry field, pre-populated with the system's configured DNS entries (static or DHCP-provided) - DoH is off by default, and the DoH server field is a drop-down list or user-entry field, pre-populated with something other than the system's configured DNS entries - DoH upgrade is on by default, and the DoH server field is a drop-down list or user-entry field, pre-populated with the system's configured DNS entries (static or DHCP-provided) - DoH is on by default, and the DoH server field is a drop-down list or user-entry field, pre-populated with something other than the system's configured DNS entries In the above cases where there is no pre-populated entry, or the system server is what is pre-populated, I would expect a conversation with a lawyer knowledgable in the field to be very brief. "The only way the user can change their DNS resolver choice is by actively typing text or doing a list-select? Okay, sounds good." "Turning on DoH doesn't change the DNS provider? Great." "Can the user force the resolver operator to use DoH, or does the operator also have to enable DoH? Has to enable it? Great." For the other cases, I agree with Jim and Watson. I wanted to make the distinction above, since those are apples and oranges (rooted in changing the DNS provider, irrespective of anything else). Brian --000000000000de29550585e4b5d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Apr 6, 2019 at 3:20 PM Adam R= oach <adam@nostrum.com> wrote= :
On 4/6/19 5:08= PM, Brian Dickson wrote:
> Again, the above is MHO, but also, this consent problems is an issue t= hat crosses over the line where leaving it unsettled by stating it is an is= sue we don=E2=80=99t agree to, does a disservice to the community of users = of DNS.


Engineers and lawyers practice rather different professions, both of
which require extensive training and experience. When all the dust
settles, it really doesn't matter what *we* think on these topics, in <= br> much the same way that it's not terribly important what the American Ba= r
Association might think about TCP window size management. Jim and Watson both wisely deferred, at least in the abstract, to legal experts. I
advise that this is the proper tactic.

= Maybe, yes, and no. The problem in the above is the use of pronouns. :-)

But seriously, there are multiple variations on the = issue, where the need for lawyers, and/or the length and depth of those dis= cussions, vary considerably.

The possibilities I s= ee include the following (and possibly others, such as DoT):
    =
  • DoH is off by default, and the DoH server field is empty (requires expl= icit user entry)
  • DoH is off by default, and the DoH server field is= a drop-down list plus "other" (user entered), with no selected c= hoice
  • DoH is off by default, and the DoH server field is a drop-dow= n list or user-entry field, pre-populated with the system's configured = DNS entries (static or DHCP-provided)
  • DoH is off by default, and th= e DoH server field is a drop-down list or user-entry field, pre-populated w= ith something other than the system's configured DNS entries
  • Do= H upgrade is on by default,=C2=A0=C2=A0and the DoH server field is a drop-d= own list or user-entry field, pre-populated with the system's configure= d DNS entries (static or DHCP-provided)
  • DoH is on by default, and t= he DoH server field is a drop-down list or user-entry field, pre-populated = with something other than the system's configured DNS entries
=
In the above cases where there is no pre-populated entry, or the syste= m server is what is pre-populated, I would expect a conversation with a law= yer knowledgable in the field to be very brief.
"The o= nly way the user can change their DNS resolver choice is by actively typing= text or doing a list-select? Okay, sounds good."
"Turn= ing on DoH doesn't change the DNS provider? Great."
&quo= t;Can the user force the resolver operator to use DoH, or does the operator= also have to enable DoH? Has to enable it? Great."

For the other cases, I agree with Jim and Watson. I wanted to make t= he distinction above, since those are apples and oranges (rooted in changin= g the DNS provider, irrespective of anything else).

Brian
--000000000000de29550585e4b5d3-- From nobody Sat Apr 6 16:39:34 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B312024A for ; Sat, 6 Apr 2019 16:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham 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 jPfWpgu9bklb for ; Sat, 6 Apr 2019 16:39:30 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2AC6612023B for ; Sat, 6 Apr 2019 16:39:30 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hCuuE-0002vX-L7 for doh@ietf.org; Sun, 07 Apr 2019 01:39:27 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1hCuuB-0002g4-Um for doh@ietf.org; Sat, 06 Apr 2019 19:39:24 -0400 Received: (qmail 6456 invoked from network); 6 Apr 2019 23:39:21 -0000 Received: from unknown (HELO [172.20.5.18]) (Authenticated-user:_huitema@huitema.net@[63.64.30.197]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Apr 2019 23:39:20 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Sat, 6 Apr 2019 16:39:18 -0700 Cc: Adam Roach , DoH WG , Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: <60D48133-8B84-42BA-BE45-464448115D32@huitema.net> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> To: Brian Dickson X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5p33l10nfHJXP1F2INxAPXd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO25BUjnzxeaqnrPDaA78u19VMZsRZacTbJPGp/MBC6BxUbTo3PayzAiqrejaKsAWXUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2TVBS2vrwtWcdwsh8YEcVdPvRa7MR4hgRIg8N 1QlY4G4/E7SMkAew92PUfpE24E7rwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMTc/0DL0kGticgfK7BXdIl5xnsMi381k+gKZDYa33nZ/Vg0XbbclXqN XyBM+egShRtk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsfj3cQFz5QBYZW/yDwrWuVZYSpQQtCkh8qZ SV0LCxte0izqaqktMWLWpBplm6d3QAAgQwCTByJrbjHMNe80eXQhu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK//KzSfzfwEldM3jWkCPmDu9UshveVgoiypAicYsWUtd9a2LHJVD1n7GG0fP 4s+aIo4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 23:39:32 -0000 =20 > On Apr 6, 2019, at 4:10 PM, Brian Dickson w= rote: >=20 > For the other cases, I agree with Jim and Watson. I wanted to make the dis= tinction above, since those are apples and oranges (rooted in changing the D= NS provider, irrespective of anything else). As a general principle, we could certainly agree that the flow of DNS reques= ts provides lots of sensitive information about the usage of the device, inc= luding means of identifying the user. So yes, the choice of a specific resol= ver has important consequences on the user's privacy. As much as possible, t= he user should be informed of the consequences and able to choose. But then, the choice of staying with the default network configuration also h= as consequences. And it has different consequences on different networks. So= ideally the user should be informed of these consequences too and given a c= hoice.=20 -- Christian Huitema=20= From nobody Sun Apr 7 01:43:14 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA31202E9 for ; Sun, 7 Apr 2019 01:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 Alwg7XoqUpaC for ; Sun, 7 Apr 2019 01:43:09 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 16CE41202E8 for ; Sun, 7 Apr 2019 01:43:08 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 9613C6A26A; Sun, 7 Apr 2019 10:43:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554626586; bh=I5gwywpfhKhSO1YnpjYYr9tg+htjS8gknhYeLb5VS9w=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=0FV48AHkLD7mhur8sWIidvX5FiSDl4bk7NBwSWs7qCw4gtXvTXtIvN2DvVnWk6rrC bd8DxBKEXM3159p3uU2uIf8Xim3ugyWIwuOyZCp7+u8BDkXnprTEIwkSlOKEOZePHP mMF96HWYkAfQh4ex+IQMHSBoRMG9v9dpVksA8hAd4V6rtpfb9V0NixZ7f83evYjCOf DBIiWKxQaNJwty8u04hw+LyBYtNKmdDZQki0xR4P4cmgASoOlkqnwr9Cy2FS5WPF4r geGkGCxZFPA6cu1aCv2qVpfgyLVB7hml5wSGaPKLu98Hz9p/0nm82A5ksHU6MhBtaf d4CyvnyWr5wFA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 7E46D3C0045; Sun, 7 Apr 2019 10:43:06 +0200 (CEST) Date: Sun, 7 Apr 2019 10:43:05 +0200 (CEST) From: Vittorio Bertola To: Adam Roach Cc: DoH WG Message-ID: <608310409.9575.1554626586437@appsuite.open-xchange.com> In-Reply-To: <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 08:43:12 -0000 > Il 7 aprile 2019 alle 0.20 Adam Roach ha scritto: > > Jim and Watson > both wisely deferred, at least in the abstract, to legal experts. I > advise that this is the proper tactic. First of all, I agree: we are not lawyers, and even if we were, GDPR sets the basic principles but its application to concrete situations is often arguable, and clarity only appears when a competent data protection authority examines a specific case and comes to a decision, and even then, the decision could still be challenged and go all the way up to the highest national and European courts. This said, since I am also one of the people that raised the GDPR issue, let me provide a general view. GDPR (article 6.1: see http://www.privacy-regulation.eu/en/article-6-lawfulness-of-processing-GDPR.htm ) requires that any processing of personal information related to a European citizen happens only after the citizen has provided explicit and informed consent (as defined in article 4.11 http://www.privacy-regulation.eu/en/article-4-definitions-GDPR.htm#a4_nr11 ), except for a number of situations in which consent is not required (legal obligations, life at stake, "legitimate interest"...). It is hard to see how the processing of DNS queries could fall in any of the non-consensual cases, though indeed the DoH operator could look for one of these exceptions, or try to argue that DNS queries are not personal information. But if we assume that consent is necessary, then the operator needs to acquire it before starting to process any personal information. When someone signs up for Internet access with an ISP, the ISP gets them to sign a contract, which, in Europe, definitely includes privacy clauses; that is the place where the user provides explicit and informed consent to data processing, including for the DNS. When the user connects to a random wifi network, usually they get to go through a captive portal which requires them to accept terms and conditions, which, again, include the consent for data processing. When the user changes the recursor manually in a configuration entry (even today, even with standard DNS), no terms are shown and no consent is asked, but there is an explicit action by the user; so the operator can argue that the consent was explicit, though not informed ("informed" in GDPR terms requires the showing of certain information, such as the name and contacts of the entity that treats the data). So this is IMHO not GDPR-compliant, but since there has been no controversy and there is at least the most important half of the consensus (the "explicit" part, i.e. "specific, freely given, unambiguous" in GDPR terms), no one complained about this yet. If the application changes the name server by default, then the situation is worse, because the consent is neither explicit nor informed. Installing the application cannot be taken as "specific, freely given, unambiguous" consent, especially if the application never processed DNS data before and so this cannot be expected by the user. So IMHO this is definitely not GDPR compliant. This however is not a problem that cannot be solved; it will be enough for the application to show a more detailed, GDPR-compliant request for consent when it wants to change the recursor and use one for which the user has not provided consent yet, rather than just tell the user "we are giving you better DNS, ok?". And I guess that Mozilla's lawyers are aware of this and we will see this happening if they actually decide to turn DoH on by default in Europe. Still, apart from the legal details, the principle underlying the GDPR consent requirements is that if you want to claim that you do something on behalf of the user, you have to ask the user properly. This is the objection that led several people to raise this point in the discussion, and I think it is a valid objection even if we are not lawyers. But, as I said, there are ways to address it. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Sun Apr 7 06:34:12 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29DD120491 for ; Sun, 7 Apr 2019 06:34:10 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham 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 BIE2Plb22UWE for ; Sun, 7 Apr 2019 06:34:08 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7AB120490 for ; Sun, 7 Apr 2019 06:34:07 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id A903B242109D; Sun, 7 Apr 2019 13:34:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> Date: Sun, 7 Apr 2019 14:33:56 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 13:34:11 -0000 > On 6 Apr 2019, at 19:53, Stephen Farrell = wrote: >=20 > FWIW, I also don't get the GDPR angle here. If it's meant as > an issue of consent related to selection of DNS server.... >=20 > So can you explain the specific GDPR-related issue that you > think is relevant? Hi Stephen. When has relevance ever mattered on an IETF list? :-) =46rom a strict protocol design perspective, GDPR issues probably never = matter for the IETF. After all the IETF doesn=E2=80=99t exist so it = can=E2=80=99t be sued or prosecuted. GDPR does however have an impact on = how IETF protocols get used and deployed. Sometimes that might impact = need to be assessed in an IETF setting, just like how IETF docs are = expected to have security and human rights considerations these days. GDPR is already covered in the T&Cs between an ISP and the end user. Or = should be. [You=E2=80=99ve probably been bombarded by GDPR tweaks to the = T&Cs for your bank, utility providers, etc.] When DoH is used, this is = likely to introduce third parties - the DoH service provider and a DoH = client. GDPR compliance will be an issue for them, particularly the = requirement to get meaningful consent from the end user. How these third = parties do that is unlikely to be a topic for the IETF. That said, I think it=E2=80=99s important that this WG is at least aware = of these problems and documents them somehow. ie It produces an RFC = which somewhere says something like "If you=E2=80=99re responsible for a = DoH platform, make sure you=E2=80=99ve sorted out the GDPR concerns=E2=80=9D= .= From nobody Sun Apr 7 06:39:29 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506461200B1 for ; Sun, 7 Apr 2019 06:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 q39z6KHc9RLl for ; Sun, 7 Apr 2019 06:39:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A717B120049 for ; Sun, 7 Apr 2019 06:39:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F0655BE51; Sun, 7 Apr 2019 14:39:20 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWMAPi0spsO0; Sun, 7 Apr 2019 14:39:19 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 32039BE3E; Sun, 7 Apr 2019 14:39:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554644359; bh=XHHtfLE2tYpMYMRrH6Ux5BGOk0lWzDmLLuhMrVkysG8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=x4UCJcLy6ZqHdIgWcyW/sIQbjqR3e70goS4RhMiO++ckEij8lO2vUI83ZpNi1GwSx 6Lw8jfiTphwfZT93LLKiYBCLbaKdaT+LArDf6smuzWYuoPCcb+Ag5ievcLWD+CeIIJ 9Y30lbalDjFfxxvYWFMDVvoSiae3w6RCf/q5ArCI= To: Vittorio Bertola , Adam Roach Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> <608310409.9575.1554626586437@appsuite.open-xchange.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sun, 7 Apr 2019 14:39:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <608310409.9575.1554626586437@appsuite.open-xchange.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lofoQwgd4V3Dh3Qu6xa3Q48uJnZRR4t4J" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 13:39:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lofoQwgd4V3Dh3Qu6xa3Q48uJnZRR4t4J Content-Type: multipart/mixed; boundary="Nzr7i9QnZGSiKu3SDN3M9MIzux8ruBDKn"; protected-headers="v1" From: Stephen Farrell To: Vittorio Bertola , Adam Roach Cc: DoH WG Message-ID: Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> <608310409.9575.1554626586437@appsuite.open-xchange.com> In-Reply-To: <608310409.9575.1554626586437@appsuite.open-xchange.com> --Nzr7i9QnZGSiKu3SDN3M9MIzux8ruBDKn Content-Type: multipart/mixed; boundary="------------2B313F974E774017098082EB" Content-Language: en-GB This is a multi-part message in MIME format. --------------2B313F974E774017098082EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/04/2019 09:43, Vittorio Bertola wrote: > When someone signs up for Internet access with an ISP, the ISP gets > them to sign a contract, which, in Europe, definitely includes > privacy clauses; that is the place where the user provides explicit > and informed consent to data processing, including for the DNS. I just checked my ISP account's privacy policy and "contract options." There is no mention of DNS at all. I didn't go chase down the actual contract text but am happy to bet a beer that DNS query privacy won't be mentioned there either. So while I do agree that the centralising aspects of some kinds of DNS deployment are a concern, I see no reason why that's any different in real privacy or GDPR terms from the current situation. That said, it's maybe a hopeful sign that at least we're starting to think about having operators publish policies as to their handling DNS query info. If the mozilla/CF DoH setup prods DNS operators to do that, that'll be good. (Do we have any examples of DNS operators publishing such policy information for Do53? Be good to see some if they exist.) S. --------------2B313F974E774017098082EB Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------2B313F974E774017098082EB-- --Nzr7i9QnZGSiKu3SDN3M9MIzux8ruBDKn-- --lofoQwgd4V3Dh3Qu6xa3Q48uJnZRR4t4J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyp/YYACgkQWrL68XsX K+pIxRAAkEK+wsadfRPzfoXbxlVFZtaaMpAmwWAhxkk/4LxvAia5e4NpHTtrnORD oBxmmWI+N5qE7TcZzKa+RtQFuaU0xtmWB8egHqvcLPCfyf4KhQsriYkz134VK25Q oSJyve/Wy7OQjXdd5+wz28Sdnrc2d2gSfYkfORTvQKnOIN3vboVX+JcFjnwiQOR4 JkBPpfFF5SE/8IOTPl4BMmQY6X97ubBQiZ+uo65Rr+fSFo6/xbyLlMCQ71329AFj jegGlfdesqL5RQRAm1PBTrSTlfsPLgFcNjN71s/WiWI+bwiN84KbI8b8Xp5quj5w 8s+cdkC0Gtw6ZjDONxMUfQZw1RseBtAAw6IXW8Cs9BlPWCm1ciOEUdzeEnIiKUiU Ozqq6juXCAEYZbU6Aa6Y+q5tZnaLlPzyqTi/PJgrMhZtYNd64gjdgIQhQN4dkC7C 7y0J3WsB4RqEBp1DVXAGSySwC9z2t3wLVuCThFJ/dFrkybSbzksHZmL4eqIZpmLh hSqIvvcVYTDo3lLqGGEf58rLR1hhsF3c6bfum/sYHCyP00mO3ZSjfOtrm/HSyqqB llQ2U2qKwXOyRZK6eHyI3ZgXzNFhtgkx2zK+kE2ypCXiEaqU1TfdfaNj3Hw4OZbX 5Z4cXMIFlRxiXqYO/viXY5jdBUalsCQXyfLMs5BpEHc8O5Vh+dQ= =vPFi -----END PGP SIGNATURE----- --lofoQwgd4V3Dh3Qu6xa3Q48uJnZRR4t4J-- From nobody Sun Apr 7 06:45:55 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718F812008C for ; Sun, 7 Apr 2019 06:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Na5O11emYLH4 for ; Sun, 7 Apr 2019 06:45:51 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 80175120049 for ; Sun, 7 Apr 2019 06:45:51 -0700 (PDT) Received: from xsmtp11.mail2web.com ([168.144.250.181]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hD87I-0008Wr-Fi for doh@ietf.org; Sun, 07 Apr 2019 15:45:50 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1hD87B-0005oZ-8i for doh@ietf.org; Sun, 07 Apr 2019 09:45:45 -0400 Received: (qmail 24115 invoked from network); 7 Apr 2019 13:45:38 -0000 Received: from unknown (HELO [172.20.5.18]) (Authenticated-user:_huitema@huitema.net@[63.64.30.197]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Apr 2019 13:45:38 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Sun, 7 Apr 2019 06:45:35 -0700 Cc: Stephen Farrell , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <21030952-B21B-4C68-86DE-394A58D59DAB@huitema.net> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> To: Jim Reid X-Originating-IP: 168.144.250.181 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5n+kZ2eZK0wbJvW8qVe1jN5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO25BUjnzxeaqnrPDaA78u19VMZsRZacTbJPGp/MBC6Bxs1+e9B2CVrcNe0x19kT5P0h5 mNm/WjPqhYqCeBiCKwwnRtk/d5gNfEtjtud5V8jp1xqbZLEGLaCXe0cUig+3Ox/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJ+GOjRbZsGJKIJ8+QoGlarPwUimsNGvJJilSn4u6QSZBBifL0Ws97a TlZh99mseIEs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53lZWWe9M6tyvdWqynpLWE6XAMgFPp7+h3kLe NmBV53UGeTBuUaUqh8n4ucfkN4zA2k50L5c/FUTo6ajFr7l877ZRXxKF5tPxTxfD0dMN+t5ZAhpR IOiolR3/ONciC+CvY5DCfByzrTqykgeH6fEj97IoR+PypV5Z5Sfz/IlJBgJ68rMgFGxC0xSok+fi i+Mknt40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 13:45:54 -0000 =20 > On Apr 7, 2019, at 6:33 AM, Jim Reid wrote: >=20 > That said, I think it=E2=80=99s important that this WG is at least aware o= f these problems and documents them somehow. ie It produces an RFC which som= ewhere says something like "If you=E2=80=99re responsible for a DoH platform= , make sure you=E2=80=99ve sorted out the GDPR concerns=E2=80=9D. How is that specific to DNS over HTTPS, compared to setting the default prov= ider to 8.8.8.8, or using DNS over TLS? Also, I seem that I am hearing two contradictory statements. On one hand, I h= ear that using 3rd party resolvers would do economic harm to the ISP and pre= vent them from monetizing the DNS metadata. On the other hand, I hear that s= witching to a user chosen DNS provider would affect the user privacy, even w= hen that provider publicly states that it won't be collecting user specific m= eta data. Somehow, the ISP monetizing privacy sensitive data would be GDPR c= ompliant, while the third party respecting the user privacy would not be. Re= ally? -- Christian Huitema=20= From nobody Sun Apr 7 07:07:15 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EBD120493 for ; Sun, 7 Apr 2019 07:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 H7um0ywK0MPn for ; Sun, 7 Apr 2019 07:07:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9985F120049 for ; Sun, 7 Apr 2019 07:07:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 81B70BE51; Sun, 7 Apr 2019 15:07:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUxNzYeumYAB; Sun, 7 Apr 2019 15:07:05 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4EAF9BE50; Sun, 7 Apr 2019 15:07:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554646025; bh=/8l83PtQHcEAQAQI04Lqc+OoexrXUgZZe/HJV9PNDy0=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=lppZttZuWoBQGQjuaefIvMo9c+tRa5/MfmW6+ZIj8ePUBj4m/ZRHsUXOqfIEAn0Un nBAXrcf8nElB2WCh9YcUn/ZDbwXV74PQD0vJrCbAfR8tzNZnSQH9T/5t6+bVxoIyGZ XlfdvcNmym1CsMNqgVyjZoTrxhSZDNS+uOL6C8Y8= To: Jim Reid Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> Date: Sun, 7 Apr 2019 15:07:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sTboWOgTUTBDW6nzsf5gqkRvgXC1nvZ9Z" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 14:07:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sTboWOgTUTBDW6nzsf5gqkRvgXC1nvZ9Z Content-Type: multipart/mixed; boundary="ujkjdFqsScZKeExNXSGeb1mUvCJicFYu7"; protected-headers="v1" From: Stephen Farrell To: Jim Reid Cc: DoH WG Message-ID: <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> In-Reply-To: --ujkjdFqsScZKeExNXSGeb1mUvCJicFYu7 Content-Type: multipart/mixed; boundary="------------229FF82F0B28BDBB487088D7" Content-Language: en-GB This is a multi-part message in MIME format. --------------229FF82F0B28BDBB487088D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/04/2019 14:33, Jim Reid wrote: >=20 >=20 >> On 6 Apr 2019, at 19:53, Stephen Farrell >> wrote: >>=20 >> FWIW, I also don't get the GDPR angle here. If it's meant as an >> issue of consent related to selection of DNS server.... >>=20 >> So can you explain the specific GDPR-related issue that you think >> is relevant? >=20 > Hi Stephen. When has relevance ever mattered on an IETF list? :-) Either never or always, depending who you're arguing with:-) >=20 > From a strict protocol design perspective, GDPR issues probably never > matter for the IETF. After all the IETF doesn=E2=80=99t exist so it can= =E2=80=99t be > sued or prosecuted.=20 Didn't you notice the LLC thing? :-) > GDPR does however have an impact on how IETF > protocols get used and deployed. Sometimes that might impact need to > be assessed in an IETF setting, just like how IETF docs are expected > to have security and human rights considerations these days. I agree that we need to consider GDPR issues, where they exist. The question I'm posing here is whether there are any new GDPR issues caused by DoT/DoH and I'm just not seeing them. I can totally accept that there are privacy/GDPR issues in providing DNS service that have been largely or totally ignored until very recently. (Security considerations btw are needed in drafts, but human rights considerations are not a requirement, and nor should they be IMO.) >=20 > GDPR is already covered in the T&Cs between an ISP and the end user. > Or should be. As far as DNS query privacy is concerned, that doesn't appear to be explicitly mentioned by my ISP. Maybe that's an outlier but I'd be surprised. So I don't accept that "already covered" is correct, for DNS query privacy. (Separately, I also don't accept that one can get informed consent from a person who doesn't understand the question being asked. So from my POV, all this "click to accept" crap is just crap and no more. I do realise that some lawyers likely disagree.) > [You=E2=80=99ve probably been bombarded by GDPR tweaks to the > T&Cs for your bank, utility providers, etc.] When DoH is used, this > is likely to introduce third parties - the DoH service provider and a > DoH client.=20 An ISP could as easily be forwarding all my queries to a quad-N service, and/or be providing a sample-point for passive DNS, so ISTM these aren't really new issues at all. (WRT passive DNS, even if no stub IP addresses are provided, I suspect one could identify or re-identify based on patterns of QNAMEs and timing.) > GDPR compliance will be an issue for them, particularly > the requirement to get meaningful consent from the end user. How > these third parties do that is unlikely to be a topic for the IETF. Except people keep raising this as an issue, but without being specific enough for me at least to understand if there is or is not any effect on protocols. =46rom the above, it sounds like you agree there is no effect on the DoH WG. If that's right then we should accept that there is no GDPR discussion to have here. >=20 > That said, I think it=E2=80=99s important that this WG is at least awar= e of > these problems and documents them somehow. ie It produces an RFC > which somewhere says something like "If you=E2=80=99re responsible for = a DoH > platform, make sure you=E2=80=99ve sorted out the GDPR concerns=E2=80=9D= =2E=20 I think that's way too vague to be useful in an I-D. An I-D that had such text could be described as possibly baselessly generating FUD, which'd be bad. I think [1] could provide a fine place to discuss these issues, but perhaps it needs a permutation applied to the title so that becomes "Privacy Recommendations for DNS Service Operators." I'm not sure if we'd find rough consensus to try tackle all the issues that'd raise though. S. [1] https://tools.ietf.org/html/draft-ietf-dprive-bcp-op > _______________________________________________ Doh mailing list=20 > Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh >=20 --------------229FF82F0B28BDBB487088D7 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------229FF82F0B28BDBB487088D7-- --ujkjdFqsScZKeExNXSGeb1mUvCJicFYu7-- --sTboWOgTUTBDW6nzsf5gqkRvgXC1nvZ9Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyqBAgACgkQWrL68XsX K+qOKRAArOHQrElaf/aRbcDG93z2L8t/euVSRGaYVV4RBlDVTlrdA8nTdoIUR+qF b9S9AmsFcuA/MKe/4iDrhwZvmvoVJzElFUthL6R6Bm/0S79SQ7oLLTVPhorUAVj3 ofcNwnhmNuyQ0xzKPU2fUXAiTvBi+OEHElPbJVi8fyMGreItQeY1OVoCM6tLcYVD ZmTXCrgu94dCCmyE8BXBA8BWyAKMrrWxhHXRl0fAP6BtaPnaiROrkXk+wqtJChXY Aah5H4SjeVNVLMrqMMlUhDIgUxlpJ0/3AXHjJvuEpxT57GylT48ulxvgXaUcXQwm jEiZ5kfrMpQjR8xEciexKjnx1sjlKg1OVbUyjiaXLVLVtudl6cUbeBBX3/XRNcQn 7Fkl2EILRPB2fUM4uwp79UNoIn7wkEWIUT3AGl6bNi+m2wNzdziCIIV42i67SL2V pd54Q14IqXU20HbZ7Jz2aFbQWMm8dEJ69stEzr71VDvqzvkirMBSdAkICBQzMtqB FaWw1qy4xOLCT1I6RK5kMDzPuOMFCdxOf3A+KB/3kBF56nrtdE8dU56Vgz400PvG D9cxlN9xJ/WiZJiJKIxxB4SiFX1dO42s6ocnf+jE3hzWPaHrUZFFuw2kVUjZ05hA RVJMwKfTE1aWvxo1QLubq0+KYLLAOvMxPnEXlwOOh95kjs7mBYc= =WqUi -----END PGP SIGNATURE----- --sTboWOgTUTBDW6nzsf5gqkRvgXC1nvZ9Z-- From nobody Sun Apr 7 07:46:34 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E661120049 for ; Sun, 7 Apr 2019 07:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 Lcther9YE8pS for ; Sun, 7 Apr 2019 07:46:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D4E1F120005 for ; Sun, 7 Apr 2019 07:46:30 -0700 (PDT) Received: from Orochi.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x37EkSp0087585 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 7 Apr 2019 09:46:29 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554648390; bh=klNkwNLlBQ5sEOMx9qJbBlSJLaoqtIjDJa4D2koeU9o=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=NGPmF6L1TzzkSHv8q930SGVBYK9SvjZH/Ta2swR3JCoy3umOH6EXMnhDMWqCKFBUR Rt4wLDFCirLzkHwkv2+Dav9fKO3eyt4wJHs+3HwY4UaCUUTFuzDMxOYX61x1/WHunL 6zklkke+IazNxWsMwukbl+93CePHxdb4JNiftFQg= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.roach.at To: Vittorio Bertola Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> <608310409.9575.1554626586437@appsuite.open-xchange.com> From: Adam Roach Message-ID: Date: Sun, 7 Apr 2019 16:46:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <608310409.9575.1554626586437@appsuite.open-xchange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 14:46:32 -0000 On 4/7/19 10:43, Vittorio Bertola wrote: > This is the objection that led several people to raise this point in the discussion, and I think it is a valid objection even if we are not lawyers. There was context to my reply: Stephen had provided his rationale for why he thought that Brian's interpretation of the GDPR was not necessarily correct. Brian responded by saying that this disagreement in the IETF over GDPR consent applicability was a disservice to users. The point of my response is that it's really not: even if the IETF were to form a consensus position on the topic of GDPR applicability, it wouldn't be worth the paper it's written on. As a technical standards body, we're just not the experts here. To be clear, I think we should and do take into consideration issues of user privacy and agency and several closely related topics. What I'm objecting to is the attempt to parse applicability of finer points of the GDPR: these are legal issues, and we are not lawyers. The line I'm drawing here is roughly the one between Natural Law and Positive Law. I would advise that anyone who wants to discuss the Natural Law implications do so in a thread with a different subject line, and that those who want to discuss GDPR applicability do so in a legal forum rather than a technical one. /a From nobody Sun Apr 7 07:56:14 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A248B120049 for ; Sun, 7 Apr 2019 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 SGVKKJnztVR9 for ; Sun, 7 Apr 2019 07:56:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 92151120005 for ; Sun, 7 Apr 2019 07:56:11 -0700 (PDT) Received: from Orochi.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x37Eu4nl089130 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 7 Apr 2019 09:56:07 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554648968; bh=dL4AXDgDk8umVLas0J03oZRFvhVSQVoOo0zz603TvT4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=qaa+UZC4+4Sl1Pq1yKYUV1T1p7eZpaFYALgcaMhhYbCrG5ijRsVuKMLywGuFX57H4 ysWigYFKmqmBbiTkuLP9d+0uCOuWob3ekQkR0uD7jEDpdpsV+agF/DNznBecYNVdMH fyq+1h1tSzfAhZ0Holh/FsqFtXhXnsPJwMXNI1go= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.roach.at To: Jim Reid , Stephen Farrell Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> From: Adam Roach Message-ID: Date: Sun, 7 Apr 2019 09:55:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 14:56:13 -0000 On 4/7/19 15:33, Jim Reid wrote: > That said, I think it’s important that this WG is at least aware of these problems and documents them somehow. Are we going to do a survey of privacy regulations in the other 167 countries also? How frequently do you see us updating such documentation? /a From nobody Sun Apr 7 08:53:04 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB44B12015A for ; Sun, 7 Apr 2019 08:53:02 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham 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 kvW_KHeE8kzd for ; Sun, 7 Apr 2019 08:53:01 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF10120103 for ; Sun, 7 Apr 2019 08:53:01 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 91840242109D; Sun, 7 Apr 2019 15:52:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Sun, 7 Apr 2019 16:52:56 +0100 Cc: Stephen Farrell , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> To: Adam Roach X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 15:53:03 -0000 On 7 Apr 2019, at 15:55, Adam Roach wrote: >=20 > On 4/7/19 15:33, Jim Reid wrote: >> That said, I think it=E2=80=99s important that this WG is at least = aware of these problems and documents them somehow. >=20 > Are we going to do a survey of privacy regulations in the other 167 = countries also? IMO no. That=E2=80=99s clearly impractical. Even if the IETF had the = appropriate legal expertise. Which it doesn=E2=80=99t. I think we should approach these issues on a case-by-case basis when = they emerge and are brought to the IETF=E2=80=99s attention. EU = regulations might need closer consideration because: (a) they tend to be = at the vanguard on data protection/privacy issues; (b) other countries = often cut & paste (pretty much) EU data protection/privacy stuff into = their own legislation. > How frequently do you see us updating such documentation? As and when the need arises? Like we do with every RFC. :-) The sort of documentation I had in mind would be something like: = =E2=80=9CHere=E2=80=99s what we as protocol experts think the impact of = GDPR (or whatever) might be on deployment of protocol X: .... This is = not legal advice. For definitive information, consult your DPA and/or = suitably qualified legal advisors. The IETF hopes the info above may be = useful input to those discussions that need to take place elsewhere.=E2=80= =9D. From nobody Sun Apr 7 09:29:04 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA8E1200EF for ; Sun, 7 Apr 2019 09:29:03 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham 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 T4_XkywYPEGj for ; Sun, 7 Apr 2019 09:29:02 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A5512000E for ; Sun, 7 Apr 2019 09:29:02 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id D4ABE242109D; Sun, 7 Apr 2019 16:28:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> Date: Sun, 7 Apr 2019 17:28:54 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 16:29:03 -0000 On 7 Apr 2019, at 15:07, Stephen Farrell = wrote: >=20 > =46rom the above, it sounds like you agree there is no effect on > the DoH WG. I didn=E2=80=99t say that Stephen. IMO GDPR has no impact on the DoH *protocol*. GDPR does have an impact = on how that protocol gets used and deployed. This needs to be discussed = at the IETF and the obvious home for that discussion seems to be the DoH = WG - at least for now. The WG is explicitly chartered to work on DoH=E2=80= =99s security and privacy issues. If not there, then where? You said you "agree that we need to consider GDPR issues, where they = exist=E2=80=9D and seem to be saying that there are no new GDPR issues = caused by DoT/DoH. Well, the issues are new. Sort of. Although they=E2=80=99= ve been around for a while, as you said they =E2=80=9Chave been largely = or totally ignored until very recently=E2=80=9D. Maybe they should have = been discussed earlier. But that earlier non-discussion doesn=E2=80=99t = seem to me to be a valid reason for dismissing these concerns now that = they have been raised. YMMV. From nobody Sun Apr 7 09:35:06 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A721200EF for ; Sun, 7 Apr 2019 09:35:04 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham 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 dBPnO-3en_t5 for ; Sun, 7 Apr 2019 09:35:02 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463A5120047 for ; Sun, 7 Apr 2019 09:35:02 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 717F7242109D; Sun, 7 Apr 2019 16:34:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <21030952-B21B-4C68-86DE-394A58D59DAB@huitema.net> Date: Sun, 7 Apr 2019 17:34:58 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <2A200CEB-2CAD-4DBD-8CEB-B605CEC1C36D@rfc1035.com> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <21030952-B21B-4C68-86DE-394A58D59DAB@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 16:35:05 -0000 > On 7 Apr 2019, at 14:45, Christian Huitema = wrote: >=20 >> On Apr 7, 2019, at 6:33 AM, Jim Reid wrote: >>=20 >> That said, I think it=E2=80=99s important that this WG is at least = aware of these problems and documents them somehow. ie It produces an = RFC which somewhere says something like "If you=E2=80=99re responsible = for a DoH platform, make sure you=E2=80=99ve sorted out the GDPR = concerns=E2=80=9D. >=20 > How is that specific to DNS over HTTPS, compared to setting the = default provider to 8.8.8.8, or using DNS over TLS? Because we=E2=80=99re just talking here about DoH deployment Christian. = :-) As you rightly point out the self-same issues arise for 8.8.8.8 (other = anycast providers are available) and DoT. These are for consideration by = the dnsop and dprive WGs respectively. Maybe. From nobody Sun Apr 7 10:09:14 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071C4120328 for ; Sun, 7 Apr 2019 10:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 LL62LRtQ5GOn for ; Sun, 7 Apr 2019 10:09:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B471C12031D for ; Sun, 7 Apr 2019 10:09:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9274ABE55; Sun, 7 Apr 2019 18:09:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0w20hZCEgbb; Sun, 7 Apr 2019 18:09:02 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ADC6FBE53; Sun, 7 Apr 2019 18:09:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554656942; bh=ZbRyPR+RFIFwx7CWqxLGcuugjOwQqNYUFkd6kTbvHl4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=TyHm5/8Hz5wuGPF7kdY0x12LzAB6yfk9aOU2ypVjaY8nPp+AUkvt3TDQstPdx05ht s4/1FxMbMHRUXxnV3ZBY2Khe6o7tBmA0nWnTRxgpGS20tk+28x50M26f6Cfdjnp5m4 li2cV1H4SsKtbWwngFha2OP47bVu7uQeQbR8BlJA= To: Jim Reid Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <30689ea3-66a5-644c-dd77-0f9671105710@cs.tcd.ie> Date: Sun, 7 Apr 2019 18:09:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9OoVIstZwKvjxL9xpnosqurAsqI3ha1vZ" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 17:09:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9OoVIstZwKvjxL9xpnosqurAsqI3ha1vZ Content-Type: multipart/mixed; boundary="r2heDgs4daoYVjW7biPtylWAghfkljhNp"; protected-headers="v1" From: Stephen Farrell To: Jim Reid Cc: DoH WG Message-ID: <30689ea3-66a5-644c-dd77-0f9671105710@cs.tcd.ie> Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> In-Reply-To: --r2heDgs4daoYVjW7biPtylWAghfkljhNp Content-Type: multipart/mixed; boundary="------------0A0D37DA4CA184F8B9322C33" Content-Language: en-GB This is a multi-part message in MIME format. --------------0A0D37DA4CA184F8B9322C33 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/04/2019 17:28, Jim Reid wrote: > On 7 Apr 2019, at 15:07, Stephen Farrell =20 > wrote: >>=20 >> From the above, it sounds like you agree there is no effect on the=20 >> DoH WG. >=20 > I didn=E2=80=99t say that Stephen. Sure, but I figured it might follow from what you did say. (That said, your mail to Christian clarifies a bit for me where we may disagree here.) >=20 > IMO GDPR has no impact on the DoH *protocol*. Agreed. > GDPR does have an impact on how that protocol gets used and deployed. True, but I disagree:-) Where I disagree is I don't think it makes any sense to try analyse the privacy or GDPR issues of DoH in isolation (that's sort-of been done and the DoH-specific issues only relate to the HTTP framing and how that provides more tracking tooling if a service provider wants to try use those and if a client isn't a bit more strict than a typical web UA). So those DoH-specific issues are really just a footnote to the main concerns which mostly relate to service selection, centralisation and perhaps transparency. OTOH, it makes total sense to do such analysis for the DNS more generally, perhaps splitting out the stub/recursive scenario as was done when we started DPRIVE. > This needs to be discussed at the IETF and the obvious home for that > discussion seems to be the DoH WG - at least for now. The WG is > explicitly chartered to work on DoH=E2=80=99s security and privacy issu= es. If > not there, then where? That's one for the IESG, and after Prague they do know for sure that that's one for them. I'm hoping they do that bit of steering soonish. >=20 > You said you "agree that we need to consider GDPR issues, where they=20 > exist=E2=80=9D and seem to be saying that there are no new GDPR issues > caused by DoT/DoH. Well, the issues are new. Sort of. Although > they=E2=80=99ve been around for a while, as you said they =E2=80=9Chave= been largely > or totally ignored until very recently=E2=80=9D. Maybe they should have= been > discussed earlier. But that earlier non-discussion doesn=E2=80=99t seem= to me > to be a valid reason for dismissing these concerns now that they have > been raised. YMMV. Mostly agree, with two caveats: - I think the newness here is really driven by other concerns with the kind of change exemplified by the mozilla/CF setup, and is not solely/primarily driven by concerns with privacy/GDPR, where I continue to maintain that there aren't really new issues. - I am not "dismissing" privacy/GDPR concerns - I'm claiming that they are a) not new b) not specific to DoH c) equally apply to services using Do53 as well as DoT and lastly d) are only worth analysing in that broader context. Bottom line is I think we're mostly in agreement about the meat of the issues here, but seem to still disagree about the best venue and scope for discussion. And that last bit is the IESG's to fix, so we don't have to:-) Cheers, S. >=20 >=20 --------------0A0D37DA4CA184F8B9322C33 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------0A0D37DA4CA184F8B9322C33-- --r2heDgs4daoYVjW7biPtylWAghfkljhNp-- --9OoVIstZwKvjxL9xpnosqurAsqI3ha1vZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyqLq4ACgkQWrL68XsX K+oCEhAAqLYrsYPinBzEBhEsqUeEvJUm4EXl+jXF24TUxIrt38sCxogxD9e60f6p nWv1AzutqY5/mcom7SBVY9VsHGBzDHAWTajXKbmwMfPsBZvmLxIKV2ysso3faqc3 /hQf4n+lV7t9UGj5thL4nqctqgMg8nqfweacNoy3h4UIb+tLnaLV5jP2rnfqwvmb oeHJdHY9PD4Dp5PfAIMp+cwYBMhw/z++ZZ3+ZM+H+sYNNbHz/Q/caw7wgikcyX9I uJxfS2mK6nkxbxz0P9kg/QPZ40kpR/aBto1Z44Pl5XhZlshAIVpdLNoZrrFYjPdF s/RidzQEQ1z9BpbPuBmFr42KDYOrb0S26jfkyVe2uNkHKK3nbFl4Vdk+97tFJvqH RNfinS//PGhfehxd7flCZGXDYeQOtQzpOQ/cXrMIji/96/Ev1kBesq1pocJpHIKI v19qiQK+to0+b8W2jplPrLs9zVbIHa2aVpw3pneET/zFJT2s2pRlq+i8/QpSeymF Q1e6EkwYNM7GVuNLPfufMgt5HM4GMWrxxX211gfRAUsuOKw9H3I/Tayxwh7CNYld HclC8R7Fc8us/9Mmcd/cZeXyHXzFsAgJyJg/SUplwkwNcI+5fuh4XU61UOd0BOIz 99WMucP7eXo1843fC5cj2jJMAHNdeVPdeNfa8k98bivONJdySpQ= =1wbw -----END PGP SIGNATURE----- --9OoVIstZwKvjxL9xpnosqurAsqI3ha1vZ-- From nobody Sun Apr 7 10:23:21 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0E1120334 for ; Sun, 7 Apr 2019 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 N3ufdyk0MSVo for ; Sun, 7 Apr 2019 10:23:16 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 7BBE81202C4 for ; Sun, 7 Apr 2019 10:23:16 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id D65286A264; Sun, 7 Apr 2019 19:23:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554657793; bh=ReTbDVxB/xZ302NbuLecF8uOYyexds4KWaEWA4PDbbI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=0PaAdo20WHZz01zat3LOgAFveu/eyJOJHr1yxDC2LCZ8D2B1MdMNyz1oHQj457HXv kloQr/CYVCuWJ+u78fuvRWQtD/Ceya/oOnmIdAnUHW6xh0G7sCCJXti+X7THrD+TfW goxAwFcBf+GZaxSSqRw9dmDstZ4pdK9TXmFyv1OeND/CBNM8kswJGOBuWiIj8oG44p kIA/kBuX2ym9k68BzTP4b367UA/PLAclznCybU0YWZZq1EO5m2/Kv6IDnAyI/BrDyk nlnZaCbZPOQ+V8/Wwt6Ncy+gZ9yHGSEbYwQbXs3Xnb6I3qAs4EjvmQ0JDeHVCXDQpd 5SCqqkNMSpiMw== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id C10203C00AB; Sun, 7 Apr 2019 19:23:13 +0200 (CEST) Date: Sun, 7 Apr 2019 19:23:13 +0200 (CEST) From: Vittorio Bertola To: Stephen Farrell Cc: DoH WG Message-ID: <1950293896.9703.1554657793727@appsuite.open-xchange.com> In-Reply-To: <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9702_1665162217.1554657793718" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 17:23:20 -0000 ------=_Part_9702_1665162217.1554657793718 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 7 aprile 2019 alle 16.07 Stephen Farrell < stephen.farrell@cs.tcd.ie mailto:stephen.farrell@cs.tcd.ie > ha scritto: > > On 07/04/2019 14:33, Jim Reid wrote: > > > > > > > > > > GDPR is already covered in the T&Cs between an ISP and the end user. > > Or should be. > > > > > As far as DNS query privacy is concerned, that doesn't appear > to be explicitly mentioned by my ISP. Maybe that's an outlier > but I'd be surprised. So I don't accept that "already covered" > is correct, for DNS query privacy. > I suspect that your ISP has a general consent request in their contract or privacy annex, in which they ask you for consent to treat any personal information that you provide or generate in the context of the Internet access service you are acquiring, for the purpose of what is necessary to provide you such access. That would cover treating DNS queries for giving you back IP addresses, though it would not cover any monetization of them, unless they also ask you for consent for the purpose of targeted advertising or other types of processing (except possibly any processing connected with network security, as that would likely fall under the exceptions to consent listed in the GDPR, as a legitimate interest and/or as necessary to comply with cybersecurity laws). However, this would mean that DNS is already covered in legal compliance terms, but less so in terms of specific communication of what the operator does with your queries, and I agree with you that this is a different problem than legal compliance, though I disagree that it cannot be solved: > > (Separately, I also don't accept that one can get informed > consent from a person who doesn't understand the question being > asked. So from my POV, all this "click to accept" crap is > just crap and no more. I do realise that some lawyers likely > disagree.) > One positive outcome of this discussion could be a collective attempt to define standard terminology and ways to communicate DNS operator behaviour and policies to final users. It would be great to see all recursor operators, ISP or OTT, communicate their DNS data policies clearly to final users, and uniformity would facilitate user education a lot. > Except people keep raising this as an issue, but without being > specific enough for me at least to understand if there is or is > not any effect on protocols. > I think this was raised in the context of the discussion of DoH deployment policies and of the drafts that were meant to formalize the concerns and discuss best practices, and that, as I understand, are now frozen (hopefully not for long) waiting for the IESG to tell us if and where they can be discussed. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_9702_1665162217.1554657793718 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 7 aprile 2019 alle 16.07 Stephen Farrell < stephen.farrell@cs.tcd.ie> ha scritto:

On 07/04/2019 14:33, Jim Reid wrote:
GDPR is already covered in the T&Cs between an ISP and the end user.
Or should be.
As far as DNS query privacy is concerned, that doesn't appear
to be explicitly mentioned by my ISP. Maybe that's an outlier
but I'd be surprised. So I don't accept that "already covered"
is correct, for DNS query privacy.
I suspect that your ISP has a general consent request in their contract or privacy annex, in which they ask you for consent to treat any personal information that you provide or generate in the context of the Internet access service you are acquiring, for the purpose of what is necessary to provide you such access. That would cover treating DNS queries for giving you back IP addresses, though it would not cover any monetization of them, unless they also ask you for consent for the purpose of targeted advertising or other types of processing (except possibly any processing connected with network security, as that would likely fall under the exceptions to consent listed in the GDPR, as a legitimate interest and/or as necessary to comply with cybersecurity laws).

However, this would mean that DNS is already covered in legal compliance terms, but less so in terms of specific communication of what the operator does with your queries, and I agree with you that this is a different problem than legal compliance, though I disagree that it cannot be solved:

(Separately, I also don't accept that one can get informed
consent from a person who doesn't understand the question being
asked. So from my POV, all this "click to accept" crap is
just crap and no more. I do realise that some lawyers likely
disagree.)
One positive outcome of this discussion could be a collective attempt to define standard terminology and ways to communicate DNS operator behaviour and policies to final users. It would be great to see all recursor operators, ISP or OTT, communicate their DNS data policies clearly to final users, and uniformity would facilitate user education a lot.
Except people keep raising this as an issue, but without being
specific enough for me at least to understand if there is or is
not any effect on protocols.
I think this was raised in the context of the discussion of DoH deployment policies and of the drafts that were meant to formalize the concerns and discuss best practices, and that, as I understand, are now frozen (hopefully not for long) waiting for the IESG to tell us if and where they can be discussed.

Ciao,

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_9702_1665162217.1554657793718-- From nobody Sun Apr 7 10:53:58 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9FF120329 for ; Sun, 7 Apr 2019 10:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 skVboiSodlFz for ; Sun, 7 Apr 2019 10:53:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61ADD12006E for ; Sun, 7 Apr 2019 10:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D288BE2C; Sun, 7 Apr 2019 18:53:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW2on-oh3jTT; Sun, 7 Apr 2019 18:53:48 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AD91ABE24; Sun, 7 Apr 2019 18:53:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554659628; bh=vtGClc7KrE7O3sjTLUIYBEDY+u1mkeDiFmsLBdggKck=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=F7k9nNs1LUqEzxusJCUKJTZNRZWc89KFL8bKmqZesRE11jjFhTAmthPAoBhekbuNf sFnbPEgPgvvyG2OcDkG/FotxT2HodYvRAWkvNfL0SX6zwMjH1Ts/b9KqmIfJ3sy3bO Yir4GxY3Q3Y6rBJJMlpFDOjPdh7tCatQoOs2dOZA= To: Vittorio Bertola Cc: DoH WG References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> <1950293896.9703.1554657793727@appsuite.open-xchange.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <89d3a500-2a12-aff8-fe55-24fbba89a745@cs.tcd.ie> Date: Sun, 7 Apr 2019 18:53:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1950293896.9703.1554657793727@appsuite.open-xchange.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DavD3wxRV6GGMBHgswUs9GQj9ec5uXEQ2" Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 17:53:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DavD3wxRV6GGMBHgswUs9GQj9ec5uXEQ2 Content-Type: multipart/mixed; boundary="87LZ5SJp5vGTiQGzn5j1jR4mtfKU7lbGF"; protected-headers="v1" From: Stephen Farrell To: Vittorio Bertola Cc: DoH WG Message-ID: <89d3a500-2a12-aff8-fe55-24fbba89a745@cs.tcd.ie> Subject: Re: [Doh] GDPR and DoH References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <7a8bceaf-b224-257e-52fc-154d45c28305@cs.tcd.ie> <1950293896.9703.1554657793727@appsuite.open-xchange.com> In-Reply-To: <1950293896.9703.1554657793727@appsuite.open-xchange.com> --87LZ5SJp5vGTiQGzn5j1jR4mtfKU7lbGF Content-Type: multipart/mixed; boundary="------------13C9557B3B1D35FE6D071394" Content-Language: en-GB This is a multi-part message in MIME format. --------------13C9557B3B1D35FE6D071394 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/04/2019 18:23, Vittorio Bertola wrote: > I suspect that your ISP has a general consent request in their > contract or privacy annex, in which they ask you for consent to treat > any personal information that you provide or generate in the context > of the Internet access service you are acquiring, for the purpose of > what is necessary to provide you such access. That would cover > treating DNS queries for giving you back IP addresses, though it > would not cover any monetization of them, unless they also ask you > for consent for the purpose of targeted advertising or other types of > processing (except possibly any processing connected with network > security, as that would likely fall under the exceptions to consent > listed in the GDPR, as a legitimate interest and/or as necessary to > comply with cybersecurity laws). >=20 > However, this would mean that DNS is already covered in legal > compliance terms, but less so in terms of specific communication of > what the operator does with your queries, and I agree with you that > this is a different problem than legal compliance,=20 I read their privacy policy and a bunch of other information they make easily available and am none the wiser as to what they do or don't do with DNS data. I'm pretty sure that nobody who didn't know that DNS exists could appreciate these issues based on the text that ISP makes available. (Maybe I'll ask them about it for a laugh, but that tends to be very time consuming with little payoff. I'll see how bored I get in the next few days:-) > though I disagree > that it cannot be solved: I never said there were unsolveable problems here. I said that DoH doesn't create any new privacy/GDPR problems. The interesting privacy/GDPR problems related to DNS aren't DoH specific. Those can definitely be analysed objectively (i.e. without trying to make DoH seem bad:-) and we could document the results so that operators could more easily make clear statements about this (or be called out for not doing so). I also said that I think most of how the IT business treats so-called "consent" is rubbish. That could be fixed in theory if we had an epidemic of honesty, so while the solution is utterly obvious, I'm not at all hopeful there;-) Cheers, S. --------------13C9557B3B1D35FE6D071394 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------13C9557B3B1D35FE6D071394-- --87LZ5SJp5vGTiQGzn5j1jR4mtfKU7lbGF-- --DavD3wxRV6GGMBHgswUs9GQj9ec5uXEQ2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyqOSsACgkQWrL68XsX K+rabw/9HnYr9zkX8NgJJWRfNipPHFuhH6O7iXN3zvymBgVioEtHP9yLATnijjjg Lp1dCDTJ+bU3ITjGr41eZNyj5haT3xNZvAY/QFdIMsngwyIbR05KKkpESP9Q16Cl VwkgFAMwKdvha0k2W0pSrV9HZ/DKvwql7KCXb0Mj2OS8EWbWOBChXWr3yDu79j8D chIdZx2s+/S3y57p/mM5+L8OJct1D+LwQhBtS0fv9Yz76hVxlfF4DLSG4632Q3Ie WMR56tK/GiGxjUJFCPYU/WG6WmT1J2MAE8WzZHzGPwywhq4nWZ7tV40sUaDq8xBX YPDQQeYhTqv8pja6s2EyAs1b5xTFVO2WMkBslNyI4taBFk+r/eKK/A/EIBzc8Qgh 9siOc4SZk/e+hlW8XE4Ti6L3KQlsghTp4/8BWNzZnplC0XnqFsTQXtP1C0tqSbMR BQ6svN77J6rWY+jiWffnnPF3d78mEARzQA6PA9vtT73U6Rff7Bh4XlKqk53MnxuX pTbAeOodXgwIuO2PMpMUszHckXWvWy5oetZMIGC3pNhVVlOcyBz/if9/Lxi7k9nz GOmJEsbVEJA1tK5qaCwqO3CcKo2RJI+6qJ/J3uhUdBlNQOAeJzcFBNfNoCDdOphu 7fLY/oROhzxP5EoMtI4NhmCwIwb+AxqT5/EM1Ow9JYPU8GvYUNw= =vCc+ -----END PGP SIGNATURE----- --DavD3wxRV6GGMBHgswUs9GQj9ec5uXEQ2-- From nobody Sun Apr 7 12:16:41 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF20812036F; Sun, 7 Apr 2019 12:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 uDdlJWSzNE0y; Sun, 7 Apr 2019 12:16:21 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFB7120340; Sun, 7 Apr 2019 12:16:21 -0700 (PDT) Received: from [10.226.185.109] (80-254-69-45.dynamic.monzoon.net [80.254.69.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1053E892C6; Sun, 7 Apr 2019 19:16:17 +0000 (UTC) To: william manning Cc: nalini elkins , Stephen Farrell , doh@ietf.org, dnsop , Christian Huitema , dns-privacy@ietf.org, Vittorio Bertola , "Ackermann, Michael" References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> From: Paul Vixie Message-ID: <77cbdb35-aa06-a918-96c3-d25a4f5391d2@redbarn.org> Date: Sun, 7 Apr 2019 12:16:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.13 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 19:16:23 -0000 william manning wrote on 2019-04-05 09:43: > Every now and then, Paul Vixie and I are in complete harmony. i am in no way concerned about that. > In my > current slot, we are one of thousands of entities that are being held > accountable to a series of regulatory requirements that have significant > fiscal impacts on the exfiltration of private/patient data.  We are > starting to focus on three distinct areas to reduce the impact that DOH > presents to our security posture.  ... sadly, there are some here, and many elsewhere, who consider that you already had that burden, because the opacity of HTTPS especially with TLS 1.3 and encrypted SNI, means that the exfiltration risk preexisted, and was not made worse by DOH. those considerations are naive and incorrect. however, it's necessary to explicitly re-dismiss them every time you mention the imposed costs of DOH. it is the _standardization_ aspect of DOH, and the possibility of encountering it inside HTTPS TCP IP DST addresses that did not offer it pre-standardization, that imposes the _new_ exfiltration and other risks. > This genie has not signed BAA or supplier agreement with us and we will > not allow it to dictate our business processes or affect our liability > without the DOH enabler shouldering fiscal and legal exposure when DOH > is shown to be the culprit in exposure of private data.  I can't see how > DOH is going to pass GDRP muster inside the EU either, but that is for > others to debate.  I have told my GDRP affected counterparts about the > privacy risks with DOH deployment. i hear your pain. -- P Vixie From nobody Mon Apr 8 11:20:11 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9881201E6; Mon, 8 Apr 2019 11:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 fYItcDuzXSCS; Mon, 8 Apr 2019 11:20:02 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 E6A541200A1; Mon, 8 Apr 2019 11:19:58 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id p16so11923625iod.2; Mon, 08 Apr 2019 11:19:58 -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:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=n7PXX5w8k50J/E8Pymhjie+q5xHUwUi7o5Ex45cxw58=; b=BiyFo23NO9Dnmmsg4dBn2cmhO9sFirx6Kpz1zkiJisNw+lE/ykaCMNengypS2/XTrE 7nuDzeyb26xTBjOQVCpAQkf8TSgFUykl7V/1l1AibriNisZfhUv90WKCuc4qq1r5Iqsp qMW62UsJ3z+/ZN7OY280z1u/uLuHJXeGpAzUyIMo9a6qgRU4tF8p0fKe9ijbYbJRtNiP hJ71MQWYH5sp/OphVxzZG1zy/R9HdevCEJhozZkCH1vuagKTh1TQDmbFRD+OtYQbF9YN BEfo3rITHQNVReS2mRkF+vSZkBwUvC3eQ65UdulG0NQjuc53ZNaf9A38aeXg59fcK+sr 8jCg== X-Gm-Message-State: APjAAAVsr60j1gkwludIx25Kg13W+nf/zyCI3maXzABNKxdVDB+myu6U 4GpSfL/IMtEkd1rKpjkHu4PSA7/Cpi8ubGkd4K9tUyL1 X-Google-Smtp-Source: APXvYqzLCsCMpNEHvs2ms85uQwuwOzMBrIWAiF0cWSF37DwMRBCCTpej8qUb01wCvGmUjY5Vz0n+/lDCHAnvjG9hPQc= X-Received: by 2002:a6b:7417:: with SMTP id s23mr21147710iog.2.1554747597606; Mon, 08 Apr 2019 11:19:57 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Mon, 8 Apr 2019 14:19:46 -0400 Message-ID: To: doh@ietf.org, dprive@ietf.org, dnsop@ietf.org, add@ietf.org Cc: doh-chairs@ietf.org, dprive-chairs@ietf.org, dnsop-chairs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 18:20:04 -0000 A mailing list has been created for the ongoing discussion of issues with DNS over HTTPS, DNS over TLS, implementation choices for those, application usage, operational concerns, privacy concerns, performance concerns, and any other such. Please take all that related discussion to the new list and please stop discussing it on DOH, DPRIVE, DNSOP, and any other lists =E2=80=94 that will keep the related discussion in one place, and avoid fragmenting it and having people repeat themselves because of the fragmentation. The new list is called ADD =E2=80=94 Applications Doing DNS: https://www.ietf.org/mailman/listinfo/add ...and it's in the "to" list of this message. Subscriptions are now open. With this message I=E2=80=99m asking the working group chairs for DOH, DPRI= VE, and DNSOP to be strict about stopping discussion of these topics on their lists, and directing people to the new =E2=80=9CADD=E2=80=9D list. Of course, work directly relevant to the charters of these working groups should continue on their respective lists, as usual. For the longer term, the relevant ADs are discussing the right path. At the moment that looks like a BoF in Montreal (IETF 105) aimed at forming an =E2=80=9CADD=E2=80=9D working group, most likely in the ART Area= but with significant crossover expected and desired from Ops, Sec, Int, and probably the rest of the solar system IETF community. Barry Leiba, ART AD From nobody Tue Apr 9 08:16:09 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2B9120469 for ; Sun, 7 Apr 2019 05:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 k5SOSRCdX_JE for ; Sun, 7 Apr 2019 05:30:16 -0700 (PDT) Received: from board.afrinic.net (board.afrinic.net [IPv6:2001:42d0:0:404::83]) (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 B95C0120098 for ; Sun, 7 Apr 2019 05:30:15 -0700 (PDT) Received: from [197.226.55.247] (port=57759 helo=DESKTOP-K6V9C2L.afrinic.net) by board.afrinic.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1hD6w6-0006Nx-5f; Sun, 07 Apr 2019 16:30:10 +0400 Message-Id: <6.2.5.6.2.20190407040436.0ee955e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 07 Apr 2019 05:29:42 -0700 To: doh@ietf.org From: S Moonesamy Cc: Vittorio Bertola In-Reply-To: <608310409.9575.1554626586437@appsuite.open-xchange.com> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <6654d063-de2d-9aeb-2ad5-bea3d5c7bea3@cs.tcd.ie> <346c2bdb-1c9c-369f-1959-a3ec964c0c52@nostrum.com> <608310409.9575.1554626586437@appsuite.open-xchange.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-Mailman-Approved-At: Tue, 09 Apr 2019 08:16:07 -0700 Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2019 12:30:18 -0000 Hello, At 01:43 AM 07-04-2019, Vittorio Bertola wrote: >This said, since I am also one of the people that raised the GDPR >issue, let me provide a general view. > >GDPR (article 6.1: see >http://www.privacy-regulation.eu/en/article-6-lawfulness-of-processing-GDPR.htm >) requires that any processing of personal information related to a >European citizen happens only after the citizen has provided >explicit and informed consent (as defined in article 4.11 >http://www.privacy-regulation.eu/en/article-4-definitions-GDPR.htm#a4_nr11 >), except for a number of situations in which consent is not >required (legal obligations, life at stake, "legitimate interest"...). >When someone signs up for Internet access with an ISP, the ISP gets >them to sign a contract, which, in Europe, definitely includes >privacy clauses; that is the place where the user provides explicit >and informed consent to data processing, including for the DNS. There is a privacy clause in a contract with a service provider when the latter has to comply with the data protection regulations of the country in which it is operating. The contract I am familiar with mentions the law which applies instead of the E.U. General Data Protection Regulation (GDPR). It is up to the "data controller" and "data processor" to assess whether informed consent is needed. The data protection angle of the DNS over HTTPS case is debatable. It could be argued that DNS over HTTPS could be used for privacy-unfriendly purposes. There might also be a dissonance with respect to BCP 188. Regards, S. Moonesamy From nobody Tue Apr 9 14:17:27 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C129C120456 for ; Tue, 9 Apr 2019 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=comcast.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 z4mKa_k5MfiM for ; Tue, 9 Apr 2019 14:17:24 -0700 (PDT) Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (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 3326B120232 for ; Tue, 9 Apr 2019 14:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190220p; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1554844639; x=2418758239; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qIcJZNsLiAcf83b+hUbhbiJYAFfTSa7jJvFP8dkGnog=; b=ZKEMeh0q4QfrpmAkbDn24K3PzVgTr74RRMkMj3MFJAXLzQqHWr+aKcPRZw1Gb0Qp 6MtLIKYQrdzVb1Nunf2LsokmdDwjPdeQWimQLoEzEsleYwT276oZAg0yF6yn3f0U nLsfl4+cTW/IwSi25FSeOzlZ/IvGpk0U5rQHz0YGD9b+2tBUnOsIkjvxXmq6z3oC iSkpuaBPmp9XWAz4WHPMvitWqFsMS48Rq1AQDoLLYIqgNOQ/sMAbDot2+UASHcMU Er6mdnB4Zzb8XK7Kv46ZAnFRhhXGcPhj/fOmDDLo4W0zLID6T3pKaBarrstRxVqy eJC9o4u6PRu+LEaqbTiujWpdhmcqKQEY96u1rszf8mVW++Wn28iaVRKeY2cR8TN5 4Azo420A/2ji6DmjDx7BI1GXaJgkgrUSN5vABfBzZ/x+xHPhboWWIVXiYNfFE77M Wb3iZuaKWDUDmZcKeP44HsBcI/2T05L+oYotNuQ/ffePF6v2q1KqGNMmLkoC88B6 8fFzz9QrWrGmGmcIDqWM7ovSKrPglqf4x4Kr1/eRLAe4lRzXGI+ZuQ+vDkHJZa2D nT4+5KJUlik2ZmTo/2UErkpYJ08nKMajtCXKsGQxTobFrkqqeUSKBDR7Pj/VZVE0 /EXEj4WwZH7iD+B/chW0Wcp78jLpAilpMNjL9N5sZvQ=; X-AuditID: a2962c47-d8dff70000001275-d3-5cad0bdfc41c Received: from COPDCEXC36.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 00.A0.04725.FDB0DAC5; Tue, 9 Apr 2019 15:17:19 -0600 (MDT) Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC36.cable.comcast.com (147.191.125.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 9 Apr 2019 17:17:22 -0400 Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.004; Tue, 9 Apr 2019 17:17:22 -0400 From: "Livingood, Jason" To: Jim Reid , Christian Huitema CC: DoH WG Thread-Topic: [Doh] GDPR and DoH Thread-Index: AQHU7KbhaeGhA3ndo0KG/16FtuuyWaYvvemAgAE48ACAAANBgIAAL1MAgAMwgYA= Date: Tue, 9 Apr 2019 21:17:22 +0000 Message-ID: <1AE1544E-6204-44C0-9246-B91E6F07664D@cable.comcast.com> References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <21030952-B21B-4C68-86DE-394A58D59DAB@huitema.net> <2A200CEB-2CAD-4DBD-8CEB-B605CEC1C36D@rfc1035.com> In-Reply-To: <2A200CEB-2CAD-4DBD-8CEB-B605CEC1C36D@rfc1035.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 x-originating-ip: [96.114.156.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsWSUDRnsu597rUxBn1XeCyu3b3IZjG5cTa7 xblnCQ7MHrdmnGLxWLLkJ5PH6auvmAOYoxoYbUoyilITS1xS01LzilPtuBQwgE1Salp+Uapr YlFOZVBqTmoidmUglSmpOZllqUX6WI3Rx2pOQhdTxv15W5kLJnFWXGi7y9rA+IWji5GTQ0LA RKJlYS97FyMXh5DALiaJ/pk/WSGcZiaJdTtvQWVOMUp8WtLHDNLCJmAmcXfhFTBbRMBdYlfD eUYQm1lAUuLR8UNADRwcwgLyEkfupkOUKEhc3HeEEcL2kzh3/RALiM0ioCJxcfkOVhCbV8BF 4nH7czBbSOA4q8S36fIgNqeAvcSFKZPAehkFxCS+n1rDBLFKXOLWk/lMEB8ISCzZc54ZwhaV ePn4H9gcUQF9iQdbrzBCxBUkeiZMZwY5jVlAU2L9Ln0I00ri2Ew2iImKElO6H7JDXCMocXLm ExaITnGJw0d2sE5glJyFZPEshEGzEAbNQjJoFpJBCxhZVzHyGpoZ6RmaGuiZmOiZG25iBKai RdN03Hcwfjgfe4hRgINRiYc3/MOaGCHWxLLiytxDjBIczEoivB/fAIV4UxIrq1KL8uOLSnNS iw8xSnOwKInztpWujhESSE8sSc1OTS1ILYLJMnFwSjUwFpT+MWBi1nv1SODJfRG5jXettaY9 as3YKvylOtdW6PalUoaZH2s06i8tXM6lntv/QOH60qSgm9x2lrW5WzzW5kcbZJw6rst+kes/ 65/0/VbqiVYy7QpndjsG8735Z/baInuG3pLGeP6IJ7tTVwQwKT7V/C4/z87p2uZNBx2Wsu5M 64s9b3pQiaU4I9FQi7moOBEAbIUsskEDAAA= Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 21:17:26 -0000 T24gNC83LzE5LCAxMjozNSBQTSwgIkRvaCBvbiBiZWhhbGYgb2YgSmltIFJlaWQiIDxkb2gtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamltQHJmYzEwMzUuY29tPiB3cm90ZToNCj4+IEhv dyBpcyB0aGF0IHNwZWNpZmljIHRvIEROUyBvdmVyIEhUVFBTLCBjb21wYXJlZCB0byBzZXR0aW5n IHRoZSBkZWZhdWx0IHByb3ZpZGVyIHRvIDguOC44LjgsIG9yIHVzaW5nIEROUyBvdmVyIFRMUz8N CiAgICANCj4gQXMgeW91IHJpZ2h0bHkgcG9pbnQgb3V0IHRoZSBzZWxmLXNhbWUgaXNzdWVzIGFy aXNlIGZvciA4LjguOC44IChvdGhlciBhbnljYXN0IHByb3ZpZGVycyBhcmUgYXZhaWxhYmxlKSBh bmQgRG9ULiANCg0KW0pMXSBUaGUga2V5IGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgdXNlciB3YXMg dGFraW5nIGFjdGlvbiB0byBjb25maWd1cmUgOC44LjguOC4gSW4gdGhlIERvSCBjYXNlLCBpZiB5 b3UgaGF2ZSBzb2Z0d2FyZSBtYWtlIHRoaXMgZGV0ZXJtaW5hdGlvbiBvbiBiZWhhbGYgb2YgdGhl IHVzZXIsIHRoZW4gdGhhdCBzZWVtcyB0byBiZSB0aGUga2V5IGRpZmZlcmVuY2UgYW5kIHdoYXQg cG90ZW50aWFsbHkgbWFrZXMgR0RQUiBhbmQgc2ltaWxhciByZWd1bGF0aW9ucyBpbiBvdGhlciBj b3VudHJpZXMgb3BlcmFibGUuICpJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8ga2VlcCBkaXNjdXNz aW5nIHRoZSBpc3N1ZSB0aG91Z2g7IHRoZSBpc3N1ZSdzIGJlZW4gcmFpc2VkIGFuZCBwYXJ0aWVz IGNhbiBjb21lIHRvIHRoZWlyIG93biBsZWdhbCBhc3Nlc3NtZW50cyBvZiB3aGF0IG1heSBvciBt YXkgbm90IGJlIHJlcXVpcmVkIGluIGEgZ2l2ZW4gbGVnYWwganVyaXNkaWN0aW9uLioNCg0KDQo= From nobody Tue Apr 9 14:30:17 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1121E12032F for ; Tue, 9 Apr 2019 14:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=comcast.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 NvpGBucwdGlQ for ; Tue, 9 Apr 2019 14:30:14 -0700 (PDT) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 100CF1201BD for ; Tue, 9 Apr 2019 14:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190220p; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1554845413; x=2418759013; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=viJa6lUNQ4+tJTDCbgUclw2sbrEOHNZUzg/hznLCxHQ=; b=yuVgVSnhQUTJM3A+we+t8GvaTN0PtW+CMPRVeEXsOjxWWev8tCnF04ih8KH3Ella e0Ezm69anEdj3K1FgIyEHOszBrCn4umXMGejgHeK5JoJkC/MBwxfFVlLZKPLTXws V0fRmwhdhTScl1ACbRjX14G1D23BMuVabmPDjP5C0KzNNJaCZFS1Q5znOtsCIhzw M55ojQQoYFX+ICkoU432WdqObvb1yh4MnpAxxZ4KQNb6x16ZTqk4FEE04DdO1JCx Gwxmn7LNXSqimWK2aESoRSl317yhWihlb81anBI0m0X59vG5gvJpBuAPBpV0LO+Z B1cHnpoIbzR356A24EJhh/qSOYS6HTWPr6ksk3TTdU55LXGbCNRIgxBkop3N8LUD 3OIjr6srhScrBpIGR+mfYH06o9tKkwJqfneHKNIsvzQ77pNs7OaCtOxbFZgOPY2x TM6z0cBl/nwV3PHZxlyvtzA+0SChmn1k8Nbh3cmyiJkcniejbzkCDtcFFhq0sI4I b0MP22EWwDw7FNjRg2Lvw/2dmfs2vLQNoHy4iNGV+JVCR26ftsI6bQWIRN4wikRn E1PY1ZOHEEn72PY3qUkL3jYYM5lZgD5jG7pTy9wkw53LpIkQjg0jiRSLHW9lOSg5 zdLHUP4p1cLcM1uT7upoBn2HMIJ/CT/EjdptX7R9b34=; X-AuditID: 60729ed4-ef9ff7000000403c-43-5cad0ee5648f Received: from COPDCEXC40.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 88.DA.16444.5EE0DAC5; Tue, 9 Apr 2019 15:30:13 -0600 (MDT) Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC40.cable.comcast.com (147.191.125.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 9 Apr 2019 17:30:12 -0400 Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.004; Tue, 9 Apr 2019 17:30:12 -0400 From: "Livingood, Jason" To: Christian Huitema , Jim Reid CC: DoH WG , Stephen Farrell Thread-Topic: [Doh] GDPR and DoH Thread-Index: AQHU7KbhaeGhA3ndo0KG/16FtuuyWaYvvemAgAE48ACAAANBgIADY2sA Date: Tue, 9 Apr 2019 21:30:12 +0000 Message-ID: References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <6030358E-24FF-4033-B0A1-AB1123FED964@rfc1035.com> <5ce0d730-aac2-95c9-fead-64cbffa03d52@cs.tcd.ie> <21030952-B21B-4C68-86DE-394A58D59DAB@huitema.net> In-Reply-To: <21030952-B21B-4C68-86DE-394A58D59DAB@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 x-originating-ip: [96.114.156.7] Content-Type: text/plain; charset="utf-8" Content-ID: <512406A5A89D5C488125095F92082967@comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsWSUDRnsu5TvrUxBve/6Vhcu3uRzWJy42x2 i3PPEiym773G7sDisbb7KpvHrRmnWDyWLPnJ5HH66ivmAJaoBkabkoyi1MQSl9S01LziVDsu BQxgk5Sall+U6ppYlFMZlJqTmohdGUhlSmpOZllqkT5WY/SxmpPQxZRxu3UhU8EXror9P2Yy NzBe4Opi5OSQEDCROPXuLGMXIxeHkMAuJomZDc+ZIJxmJonVl86wQzinGCUarq5mBGlhEzCT uLvwCjOILSLgLnGiawcriM0s4CbR/+k9SxcjB4ewgLzEkbvpECUKEhf3HWGEsN0kXlyfywZS wiKgInFgRSZImFfARWJ++0SoIyaxSty69BpsPKeAvcTPDYfZQWxGATGJ76fWMEGsEpe49WQ+ E8QHAhJL9pxnhrBFJV4+/gd2jqiAvsSDrVcYIeIKEj0TpjOD7GUW0JRYv0sfYoyVxJLpL1gg bEWJKd0P2SHuEZQ4OfMJC0SruMThIztYJzBKzkKyeRbCpFlIJs1CMmkWkkkLGFlXMfJZmukZ GproGZpa6BkZGm1iBCepeVd2MF6e7nGIUYCDUYmHt45nbYwQa2JZcWXuIUYJDmYlEd6Pb9bE CPGmJFZWpRblxxeV5qQWH2KU5mBREuedU7o6RkggPbEkNTs1tSC1CCbLxMEp1cBY+ufKgTTO bce0flT/XC1y4vnqB9zpfMKtB2XzF8R/6m+xFowt+F/8YFPwOevJouLVU9KWrOxO3dp+cu3h mhy/3O7CRHYbf5ez9VOffy4zNg/P++3v/ij7WPvsA6sm677aZin++qzmkve1rzTvtt42Tw9t SbKfacOSevKm7971PFbmFgmPte8osRRnJBpqMRcVJwIA1Ubfjk4DAAA= Archived-At: Subject: Re: [Doh] GDPR and DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 21:30:16 -0000 T24gNC83LzE5LCA5OjQ2IEFNLCAiRG9oIG9uIGJlaGFsZiBvZiBDaHJpc3RpYW4gSHVpdGVtYSIg PGRvaC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBodWl0ZW1hQGh1aXRlbWEubmV0PiB3 cm90ZToNCj4gT24gb25lIGhhbmQsIEkgaGVhciB0aGF0IHVzaW5nIDNyZCBwYXJ0eSByZXNvbHZl cnMgd291bGQgZG8gZWNvbm9taWMgaGFybSB0byB0aGUgSVNQIGFuZCBwcmV2ZW50IHRoZW0gZnJv bSBtb25ldGl6aW5nIHRoZSBETlMgbWV0YWRhdGEuIA0KDQpbSkxdIFRoZSBpc3N1ZXMgSSBhbmQg b3RoZXJzIG91dGxpbmVkIGRpZG4ndCBpbmNsdWRlIHRoYXQgaXNzdWUsIGFuZCBpdCBkb2VzbuKA mXQgZnJvbSBteSBwZXJzcGVjdGl2ZSBzZWVtIGRlZmVuc2libGUuIFJhdGhlciwgY291bnRlcmlu ZyB0aGlzIGJlaGF2aW91ciBieSBzb21lIElTUHMgd2FzIG9mZmVyZWQgYXMgb25lIG9mIHRoZSBq dXN0aWZpY2F0aW9ucyBtb3RpdmF0aW5nIGNlbnRyYWxpc2VkIERvSC4NCg0KPiBPbiB0aGUgb3Ro ZXIgaGFuZCwgSSBoZWFyIHRoYXQgc3dpdGNoaW5nIHRvIGEgdXNlciBjaG9zZW4gRE5TIHByb3Zp ZGVyIHdvdWxkIGFmZmVjdCB0aGUgdXNlciBwcml2YWN5LCBldmVuIHdoZW4gdGhhdCBwcm92aWRl ciBwdWJsaWNseSBzdGF0ZXMgdGhhdCBpdCB3b24ndCBiZSBjb2xsZWN0aW5nIHVzZXIgc3BlY2lm aWMgbWV0YSBkYXRhLiANCg0KW0pMXSBJIHRoaW5rIHRoZXJlJ3Mgc3RpbGwgYSBiaXQgbW9yZSBu dWFuY2UgaGVyZSAoYW5kIG1heWJlIGFwcHJvcHJpYXRlIHRvIHRoZSBBREQgbGlzdCksIGFzIG9u ZSBvZiB0aGUgaXNzdWVzIG5vdGVkIGF0IHRoZSBzaWRlIG1lZXRpbmcgd2FzIHRoYXQgdGhlc2Ug cG9saWNpZXMgYWRkcmVzcyB0aGUgRE5TIHF1ZXJ5L3Jlc3BvbnNlIGxheWVyIGJ1dCBub3QgbmVj ZXNzYXJpbHkgdGhlIEhUVFAgbGF5ZXIgd2l0aGluIHdoaWNoIHRoYXQgaXMgY29udGFpbmVkLiBT byB0aGF0IG1heSBtZXJpdCBmdXJ0aGVyIGV4cGxvcmF0aW9uLiANCg0KDQogDQoNCg== From nobody Thu Apr 11 10:41:44 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240A120607 for ; Thu, 11 Apr 2019 10:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 sMMIcP82L5g7 for ; Thu, 11 Apr 2019 10:41:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 A9A06120608 for ; Thu, 11 Apr 2019 10:40:56 -0700 (PDT) Received: from [192.168.42.125] (ip-89-102-31-19.net.upcbroadband.cz [89.102.31.19]) by mail.nic.cz (Postfix) with ESMTPSA id D81B260710; Thu, 11 Apr 2019 19:40:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555004452; bh=JMHQk5HpZHmPVyNfZmH4c8GMZXR0Yb9XIh/+ZeS0fnc=; h=From:To:Date; b=BPzSfG6yuyisrZDdPvFW5gc6S6YDBea/phYMOaeIXso+EZQok0sFsk3VBjq2DYXLS /0dmyeXwxjyq0PG4QDCPIl1XTc7wdtb7hQ3o9XzyftaC7vIH9OGF2PjuqSAErH2I8R 1rdXIDRZ5cqlOVieKMtkhJA8ZWTD6DaPaTEp2uYg= From: Tomas Krizek Openpgp: preference=signencrypt Autocrypt: addr=tomas.krizek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhITjsBEACn+jYk59OSa7eul+bIaZERXTfhgfC6esfC5WPV0NmCig0W1JbunWglYX3B s1FJR4OCpchrbAQW3bEYDsddvy5rCbaG0IoOqNsd5GEhCmegDLNU/l36P83UUw8kkSJhlKr/ U+EO+bFyKljmF+dE+OvIky1A+wd1zgRkcljr9DOfdLsAqL4nIb/LC99ZD27laSEAoaZagHXW MVP0EExM3+T4V5sPJ3ghrK1hAk5spAX9yHUSF242zo+5Sj/l/dGL/PXDeCJPHjfdQNUkKcRT VlbAIjfl5mk//73z3XmRSKp9R5HsCKQjBC5Q38a/ZVDdaiSwIxw2sDLrI4+91ycsJ3gjtyiq yO43a4Y6mQHw9VZxudYG1hJ1+pAEPyLo/xIpGIlOo6BmmSz7gYgTPKB/dmGFOx/Qtrt8jNti y3oyRRMPdQ2Vl/MRAZ+OVSsSplf0uGFrhWOX6OPl6h7hu1mMbmHrQtgs835ZVfMf2IoK6QkF NFkn6HbdgF+4IZaX4br1WqZN2c51hKcIE4AHTSVSXwXRgdN/7Q2bmOH2IvfqTOX3HyfrIqUL nqUuD4tZB5Q+z7V5H6vzG5GR2CFlwkSgaayoplLG7h4Xh6Hyman95tl/xS61TeSfnv7NYIZj 6fw4veUUALQlTwDkOh17wByJitvYfBkoiCY7ShAxYyBckGGFxQARAQABtCJUb21hcyBLcml6 ZWsgPHRvbWFzLmtyaXpla0BuaWMuY3o+iQJXBBMBCABBAhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAAhkBFiEESoukjCrtkzvUlcUJoful9++MSGkFAlwZInQFCQXe2rkACgkQoful9++M SGnRWw//f6g+dd4ddcsocUpn4dCJGOQ9HqWMhAKItTq4UI8H337LATFCB8vKPmaDkKXIJYtw +4eZzhlZqTIzH6VUUnZWdM/Aifwnj2nCnfUD1wHUuEU7ZwNUEenl6YZfFHFqKaThcv8UNOss TUdWL752LwRMvaBscert2Jnc4siOYTRNcLJiqev36LXFwc/pbuH8TBrLVszB3MGrrMNv+NCy yCrk5vgGlzBXGJWwVKwf/7pPjN+0DiEeSbSFnxnFCUiyMYTVOhs5DanxNcdYu7cBMbLwp1cw EP+RzUSeOOrKcVdb839EXb0KtXQ6w9dAkpp7XeQs+os6bq8M9Mx6tdIv7bX/KUJWVRUed5ow SG6AJvRdSdvxpKom14CgWLM96tJVdz+Pttc29ObSGcucEvmAIAUtdFSmxYLnKVXq1EGfkZXX PDr/cSr2Lfedc+kb7GDqal6St4uYTo0Q3nVFwiHs19ZRqvf+6TCbOvv8PStxD4YbwlzNkcyF nKceU2a8dyvOhDR3s/5OONsjLT5srEmnArZy/0gtlzPEhserHhnnE7o0dnzy02QmktLaqhw2 MXX1zIifR4tf+MGY2rAm2YtilD78fcsFPOZ5w7GDufflxz2uzOQ1CtPiazoI7tNYSYJELTxD g9Es2KUNnT5sja5gKPpGSjK4mhOzvYrxIZnG4p7i5gO5Ag0EWimwOAEQANIie73DMB4rO0WE mJ4qXfJotkZEViX7MUMo+gh1Gb+zcC08gsY2rdtVXwydkjHimk90qupL0WvP2caYpGyeZrn8 4fuiNpbzDWM3r/EhArizGWgpiEh8B9Pp0Q7K1meA7Rkwk6C1O+Jns9RhXJFE2KPIPBBqwWG5 rNIChnPOt/ZpSmQ9fnqplMT+N83xeN9GDU9EwEPcwzLsq+nCgVcAam1zMUUGKNeiHj9pcg+U TfvTROSKkRQ0UGTKm7+vYi9+jbQDGeTNSoEUp/wqgneryhKISfBODTqCn5mjoBqWJqQB3u8G Kj0R1WNK/kmmNA5cNDZmzfx24a3I8DI110AoKBGvGkmzR+c1F3ScjrCrBf3ce4wj0tAVtpmr h1Zj8DA9Waa2MxYi2BNVH0nJf2m7xrc7K/NsCC3zdMLML7KF8oBmiVFMJCxozla1e1iDq/F8 aCjkeX6qtdycdYulVcQqgaXRpe821yYRreTjAdO9j05CSfqQ0CZUmPq/Ff5YJ928FJF4rJOU g6djm4CYaDH9/1kcIiAczpUvvd8U643oKOiN5cEooFKqc3uOLaiTQFc09pZm19rGY2wmn7qE Q6KoMuPXkrFOHkCpyqtW6dfHHJeimLBbvxLotdWrUaMtKjmwG61MueKCRPlysaA2HWcaqQiA Jk5U16eKb2ImjpO9UBepABEBAAGJBHIEGAEIACYCGwIWIQRKi6SMKu2TO9SVxQmh+6X374xI aQUCXBki0QUJA/15GQJAwXQgBBkBCAAdFiEEFe8t8KwPEBnPn+loGFnIJjkFVmwFAlopsDgA CgkQGFnIJjkFVmya5BAA0JPGtGHpCLnLPjxdLnIpUbQbaKA7AiYskJReIEqPOXWb9WguXYa0 j8PsO8d7sn/tBMqw7XdezjWcJWKutipV9tw6bWQfsx37dyplLwQ6FvuaAMAEXBdxS2Zvf5ff nq1/Sy+TZSRzVH9GkkP7LgjFfjt4sXTi6KT3zv25ILblJk/Am8qpBt5Iia6hLibDtaz54o3C motHi2JQLayWwQZ6A1a4/hlI7DczsEZfANxd2AItQOQQHvoTEuxFR0ew0dIdv5pLWrW2HfPi LCFUk2tPImpLvUsmHTQ0kRp5RunObplWIkb7MqCb8DhJ7rbU4eur+qW046pNxci94m0zpEBh dsgC2P+gYSfohYvpEdVMmUOETdxbEUREF1aud72+onyPSvLR6nTwM3Br/v1NK3o8t6K9zkUn BFDtjqXn7vsf0CA1eszcygsAi06CSgpv8qnU4j7YoBspbCjEINhip5iNigI3SN49gA9ON+0+ FszDZU3sokvIu2xfvePyZ7OhQD6lu+KITlwUH2EDIVpirH1ubO3VhxY6M9qBWs49UuCQbBaG BwpHlhg7n+wggx+k6Z59kU+4cd1Q9XNfbk2hVvYdCvHbtH78rh8maLBdGsiyoWrLvcDF+z3G /afej3QVAP2LdWkurAxhUp7sAf7VBKvcXCQ0/PGrfRpgdofxmNcQG1sJEKH7pffvjEhpdFUP /0dEjCqXFocJh+brbecd5UOAxZ8LmmBKcxyB0jr4oeiZBjhBy7Id55YwGRRAYm6MYW6S+g9g yoH5qw0u1fmAcxanXq3i7tLp6NZP+O4ZN0UP7G145VfgTU7qpj6KszvFaoWhMDIQk7ADry1k FrOPpB0q8fc2kIdcsTmAvl3l3oKrq4pEeUGuBoKZpoF/5tG6krv1tOjYXAmZ/hxR6ktBG3PK B1Q/rWu5RLhwrEofTtoxAGOL2XKm0FdvMlE0KWxSKgmJzZbQokm2mF1WbY2xCJLjaqUgaDpT tzGvihOlomFENrkQsWy75ywkcZoxXRKux6SU3xmodVeXTwI2BiPkwp+eaj3luZyfgD/f3x3Z MfNY3txJX1EATbF/0PM/EqJN3ZfdUu7fBfdKlf5tNnM+nfvHGG0VX6gooC2JzEjJARIl32rb WPdaNxOSkgWqXnH0YNv4195bAFet1wFjls3xbiFqwQr39ExwOQ8pneQ4pAOlq8evY8VDf6wh pjWyr5eNQNUjex1n2chF8GWLGTAggNpAxhO9QxXgKWvtg8uD1qyUPGc+S0kRwHtgGmbtVmPu TDk8kzECxV6x2tCnvqDwfGmX9DWfT+Aivu1n+0zigFQJbaJ4thhrZj7ls0jX0gqO720ogjCk SnRQFWnvzUH5Z4nhfq0nELZDO11mSAJuf3mCuQINBFopsMIBEADTHIG17I/eGluDtAgq5ryD bXc2q8NMNWotsNJvj9MbT6sCOq7gwHCrsbPMylxPTAsz/LIfaFzF5eIKJs4BfQJkgLrNPN6D r40zq/+rfl4tjrfpEzxFRYrqTRHIVEhc2TETdBkQNf351H+dAMrctjFvCzoEhap0MorxWmub uHLXqdsNPCAmnLCkn4nuBm49qBPtxZOalbKQx2OpBxkrvhHvTYh078WNqBFi3y2EW2RYqxVr I5u4fL2A2b505uaavup2gQIOuIgsnUciIw1iGUDRHlQt15w2H1y6w0rI5qYDKwVbO8cM6g3R CCh1A+sYYyXhPtxAqk+zcCswU15fuaf4PmcdS8js7CJxXJVeUD/1xrXDVMLSyrTJCLDT5Ki+ jAToqt8UzGeDyP6kUvz7f25O2eeR+myy8yDw8dF/CPHQLorHIczeQNRxvbWEwuBgMKNDQvyB Tx9jpmAjZ+oAc7n6eALwZF06hlhAu+T7aTg2DHCoobDSSG1xWfv1esBPjSMr4QpurTONMJXJ BMiBubVI7jsLltAIagpggimmZfDTO+lmI+/u69iK/LZTd0r960HhixmmHccNkc7wWnrSJr0s 6zTNi7ddscLdL+z9+g61g2LunQze4wHO9Bd5xcoDWUOY7TYKXKxkwapfHHdBG9oK6F3IZO/q vt4BALiSw0+KLQARAQABiQI8BBgBCAAmAhsMFiEESoukjCrtkzvUlcUJoful9++MSGkFAlwZ ItIFCQP9eI8ACgkQoful9++MSGkeTQ/9F5mW8VPQf6XOraSigIqfjb4WrrGc0kQwYlzILWiA 9jdmINHnX6gFriMkUuOcuntROmNUxOPxrTkBLZYvdF502O68LT2Je9aPo4loPyZancbIZAMN bYRp76zQHFjSJEdSW5I/rSsV7iufFQZ9Q7f6+UdSFfLmNBnlKKBYGfj7TmnyOk9u//J22nV0 Sinu1cmsYwcBSoHydu89YbSFs5Tu4vgbkA1D+ggCE9/XkoS+0nPEoyBalRKmm4oXt91+ArLn b62RxPYwo28axDAcg1jk4IC1kdRKa+X7dWfYFcknRa932m+SK2MY0yPNECZdva897yo1IylX y50zRSw4gujo+3cExFUuyfX71L4yG9ndQOPEtXJt2kQbbdvVOMFmNJjA4+l8DUyiRBwLfjhW VAF2WUI7YGbrwIxW5AqogBgFvx/iV3fgUHTeEU5/Jmzok/BI9cjlrd1ialNwyjQqBls8cjgk hGnPB8cZSUYiWm1WN6gqCmXTDzXVRoqaV68TJF2QMhficAHq1PgD9cFnOz9cfMaqVUputKUR R3anYpkxlDe8MGvoS3HCfnQwiOWRDDWfsmFfB64RROMDvojkhrJ6vgcpPH3R4lh8ZomGJUWS b9+pupY0mI26hpV4woYD0nQCGXJ58Hfh84DmufQuppdfoJwS50O9WO9B6Mpns/Ab61+JAjwE GAEIACYCGyAWIQRKi6SMKu2TO9SVxQmh+6X374xIaQUCXBki0gUJA8IjjgAKCRCh+6X374xI aY5tD/9Fw9WHqaFvcNu41M5oQjUbWl1jY6FutXgm+tapmHsWdQ6nTEA8Ch93HRUJC4I8grNR e4xd9qEZLGw+lrlmKhhroNqrzoaCIbl2/zRE4Pl0UOaMV/xR8x01Jr9kE6rrkHQt9HuSMffJ M76sqHEh95ZTfTWW6m228gRN3Wduqt2Mu0vlSQSdegog8DP7KnR5i/LcdgUfAm5D5NlBvJwR W55PJ24bp/zFCFZAQXMN75so4OLiig/yWgsnz2yxEsg/79aRf6p4R4jOy+aP/V43iJJKQkDx BG5X08kh+QBaGTaUHqalnOccIX9DcM4G9bz2WZySg3njmXVjRyD5ayNmy+WixhaMjKgudAAv zKqHpT6qKBwc4r+kqGxySvsVIU6IUxs9zzrUrwgyB5WRO45JZ5ZOXPOOFyEEIfb+VcMSzu5N 4U9vOAxGCTBhjEjJyai7Zz4hgx3c48rNMDmByHL9sd8GwwGoCdoCDiZti62fBYxUfsHtoaxb kSnXMtN0LeQclHSjQpDMO/k2Ow8/19sG8XqW+d4nLz+7se4QjmNEf8xAkice+t7hEtu8sqcu vfISaURjPOEYzPdTymo7Bd9aYICCewHgCJEP1n0Fk5dj6ZMmUR86vDE2wm7qaEDc9M5sDqV3 pHNUGPUm3ANtW8nHF/R57lLE9IGZBe82eO9g+s9qtg== To: doh@ietf.org Message-ID: Date: Thu, 11 Apr 2019 19:41:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K2rrw6pkMrRybeHphJmOBkfgJ5Mq7I56u" X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 17:41:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K2rrw6pkMrRybeHphJmOBkfgJ5Mq7I56u Content-Type: multipart/mixed; boundary="Pip1Dtj6DJOrdOra52xoMryFRyszc2YLx"; protected-headers="v1" From: Tomas Krizek To: doh@ietf.org Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Message-ID: Subject: Dedicated DoH port --Pip1Dtj6DJOrdOra52xoMryFRyszc2YLx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Disclaimer: I don't adocate the use of a dedicated DoH port rather than using port 443 for most DoH traffic. I'm simply trying to establish reasonable defaults as a software developer and packager. Knot Resolver will use 44353 as the default port for DoH. We've considered using port 443 by default, but it presents many challenges. If an admin is already running an https service on the machine, the clash with DoH resolver can be quite problematic. In best case scenario, the admin runs into an error (not able to bind to port 443 - quite cryptical for someone trying to run DNS resolver who's not up to date about DoH development). In a worse case scenario, the DoH service might actually seem to successfully start and run alongside the unrelated https service (e.g. when both services use systemd socket activation with ReusePort=3Dtrue - basically SO_REUSEPORT under systemd). Those who know what they're doing will have no issues configuring their DoH service to run on port 443. However, I think it's reasonable to use a different, dedicated port as DoH default for packaging, documentation e= tc. Since there is currently no IANA assigned DoH port, I've filed the following user port request with IANA to establish a common default that could be used among DNS vendors. Service Name: [domain-doh] Desired Port Number: [44353] Description: [DNS query-response protocol over HTTPS] --=20 Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 --Pip1Dtj6DJOrdOra52xoMryFRyszc2YLx-- --K2rrw6pkMrRybeHphJmOBkfgJ5Mq7I56u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEFe8t8KwPEBnPn+loGFnIJjkFVmwFAlyvfFYACgkQGFnIJjkF Vmx6mhAAqr4LeGd4qG7pQrKE11NZbKIPOdNO2uhWR77GuUXMaJ1XxmvfuAxceho6 063jndvB1t/sfgJ7DkXKrdY7+CH0e8g8tgLa+MuBxeC2JMxZ3GAEGqfNczmvzXVO ZovwHUazEii8XSnOTyo+J/kMUps6OMLw0gUNYgSj6+NtjVt3fwYQh7Dz7tYg798e ulD/IJoy+JAKWPD2hB/oJU1XCkeqwdK1CP89kvOSytG8CpCWiT9k3IF220+q8c0k itAjdJZzfIp8vn3h9ZR1ozB4ftqveSeWIoAfGITcuc5fa/UuM8DPhmOKIn9v/or2 N/5mCWDWEv8/O5cTd+KIBnWcLvck4zgNbsA2l2asei4ygLkNDDPEH+haz2di92H5 vErwhJsjOJ69JxzLGSNZhq844K73fe4U0Ng7HHDg7BoILxg2TzBLzqCajiluzQNj fOLOzfHpNbjMR7CFirFziALmC+unsXe/yuIAtLFkMhbQPdP1dN3VxtUAX0tfZZmM UnnSaW9XpBVi/dkBvlh0xmBaqyV9yRWg8RzaXmKWHSy4zS4RDAX19zvY8LzhNFCq tz+ODGTpynWksMpn66P4LdYcqBZSS6PhAx+K7QzUR4voT8wI/1xT+p9+prr/6PSz Pwq+bvDPxKDUfwBosXAy+k1n9F9s/H3ouzH6ra3O/eP69f956R8= =5uX8 -----END PGP SIGNATURE----- --K2rrw6pkMrRybeHphJmOBkfgJ5Mq7I56u-- From nobody Thu Apr 11 10:56:35 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5448F1206C6 for ; Thu, 11 Apr 2019 10:56:32 -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 gcb_sqnsK0EI for ; Thu, 11 Apr 2019 10:56:30 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.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 6F460120683 for ; Thu, 11 Apr 2019 10:56:30 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id y7so8494542wrn.11 for ; Thu, 11 Apr 2019 10:56:30 -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=Mz9qicHi52P3gg14SvdGoiKIbHTl+Kl3mtgx6JQx8Xs=; b=XWIjnUPtB7ad3/aYCC+SgXboO1pplM9T/z+AcJovZjQwVHNR7Y+WNFgbE4Hn+b7uSw JuN7/guCHb4hhCsulJ56kjgrLfHQjCRFlVIXk+/aqit1VTdR8SaCLDyymPOF7DIfctKH JNRUCpJAoxIEgupZLmBbP+kI2yzUmKxTHmcwO2fzL40VleNcg/ftfe6UBFX+t/vvut9q vAvUIOtN/IeGAs9NcIW0q5WIwhzRKeoANYG/r5DqIxx3mhpCKb3LXuTJR0u17WOCNI14 3Pgy2y77yZdDbuzUDjxaxfetEt/KNiHGivxH7z7bntv9tq+Qp4XEPHGi7syGGrWx35Jt KhvQ== X-Gm-Message-State: APjAAAUPioFStbZFiljWOzwu9QPHBSatbh9F7ZSSzES+GbavMyfttXJh C259v7oKpSXjY5oX/J/Jqd1nwTrJrwTVk/D8lRS9q9Pj X-Google-Smtp-Source: APXvYqwAfytJDUjwYVjYljwfznN2fXIYmPI5PN2klnu7Lku7hAABN+9KKxnUqIDTY9FaZrdWYPzjKPnY3TYOk7V1Sy8= X-Received: by 2002:adf:f48d:: with SMTP id l13mr27326145wro.2.1555005388542; Thu, 11 Apr 2019 10:56:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Nygren Date: Thu, 11 Apr 2019 13:56:16 -0400 Message-ID: To: Tomas Krizek Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000ced85e058644e7cd" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 17:56:33 -0000 --000000000000ced85e058644e7cd Content-Type: text/plain; charset="UTF-8" Would it make more sense to request something out of the well-known ports range, or at least outside of commonly-used ephemeral port ranges? Erik On Thu, Apr 11, 2019 at 1:41 PM Tomas Krizek wrote: > Disclaimer: I don't adocate the use of a dedicated DoH port rather than > using port 443 for most DoH traffic. I'm simply trying to establish > reasonable defaults as a software developer and packager. > > Knot Resolver will use 44353 as the default port for DoH. We've > considered using port 443 by default, but it presents many challenges. > > If an admin is already running an https service on the machine, the > clash with DoH resolver can be quite problematic. In best case scenario, > the admin runs into an error (not able to bind to port 443 - quite > cryptical for someone trying to run DNS resolver who's not up to date > about DoH development). In a worse case scenario, the DoH service might > actually seem to successfully start and run alongside the unrelated > https service (e.g. when both services use systemd socket activation > with ReusePort=true - basically SO_REUSEPORT under systemd). > > Those who know what they're doing will have no issues configuring their > DoH service to run on port 443. However, I think it's reasonable to use > a different, dedicated port as DoH default for packaging, documentation > etc. > > Since there is currently no IANA assigned DoH port, I've filed the > following user port request with IANA to establish a common default that > could be used among DNS vendors. > > Service Name: [domain-doh] > Desired Port Number: [44353] > Description: [DNS query-response protocol over HTTPS] > -- > Tomas Krizek > PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000ced85e058644e7cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would it make more sense to request something out of the well-kn= own ports range,
or at least outside of commonly-used ephemeral port ra= nges?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


On Thu, Apr 11= , 2019 at 1:41 PM Tomas Krizek <t= omas.krizek@nic.cz> wrote:
Disclaimer: I don't adocate the use of a dedicated Do= H port rather than
using port 443 for most DoH traffic. I'm simply trying to establish
reasonable defaults as a software developer and packager.

Knot Resolver will use 44353 as the default port for DoH. We've
considered using port 443 by default, but it presents many challenges.

If an admin is already running an https service on the machine, the
clash with DoH resolver can be quite problematic. In best case scenario, the admin runs into an error (not able to bind to port 443 - quite
cryptical for someone trying to run DNS resolver who's not up to date about DoH development). In a worse case scenario, the DoH service might
actually seem to successfully start and run alongside the unrelated
https service (e.g. when both services use systemd socket activation
with ReusePort=3Dtrue - basically SO_REUSEPORT under systemd).

Those who know what they're doing will have no issues configuring their=
DoH service to run on port 443. However, I think it's reasonable to use=
a different, dedicated port as DoH default for packaging, documentation etc= .

Since there is currently no IANA assigned DoH port, I've filed the
following user port request with IANA to establish a common default that could be used among DNS vendors.

Service Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[domain-doh]
Desired Port Number:=C2=A0 [44353]
Description:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [DNS query-response protocol= over HTTPS]
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495=C2=A0 C509 A1FB A5F7 EF8C 4869

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000ced85e058644e7cd-- From nobody Thu Apr 11 11:11:05 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1069120366 for ; Thu, 11 Apr 2019 11:11:03 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham 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 5dZu9JfGAxW9 for ; Thu, 11 Apr 2019 11:11:02 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2249112030F for ; Thu, 11 Apr 2019 11:11:02 -0700 (PDT) Received: from [10.46.0.104] (212-147-18-59.fix.access.vtx.ch [212.147.18.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id D9D69242109D; Thu, 11 Apr 2019 18:10:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Thu, 11 Apr 2019 19:10:57 +0100 Cc: doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <472EC8F4-A610-4FF1-825B-2427AEE31F25@rfc1035.com> References: To: Tomas Krizek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:11:04 -0000 > On 11 Apr 2019, at 18:41, Tomas Krizek wrote: >=20 > Since there is currently no IANA assigned DoH port, I've filed the > following user port request with IANA to establish a common default = that > could be used among DNS vendors. >=20 > Service Name: [domain-doh] > Desired Port Number: [44353] > Description: [DNS query-response protocol over HTTPS] This seems a bit hasty. Perhaps there should be an I-D or RFC first? = Allocating a port number from the well-known range might be a wiser = choice than arbitrarily choosing 44353. I'm not sure it's a good idea to allocate a port number just so someone = can run a web server and DoH-capable DNS server on the same box. That's = unlikely to be a common use case. Besides, the web server could just = forward inbound DoH queries to port 53 over the loopback interface. Or = something like that. Another solution might be to update the current discovery draft to = include an (optional?) port number as well as the IP address to use for = DoH service.= From nobody Thu Apr 11 11:18:06 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385B2120366 for ; Thu, 11 Apr 2019 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=riseup.net 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 iVAsUEpxZGTn for ; Thu, 11 Apr 2019 11:18:02 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5776612030F for ; Thu, 11 Apr 2019 11:18:02 -0700 (PDT) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id DE18B1B9202 for ; Thu, 11 Apr 2019 11:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1555006682; bh=dbj8S1X271A9wOgkVdq23kAIPx1nAqyFYXSTaiIpCw0=; h=To:References:From:Subject:Date:In-Reply-To:From; b=BX9k3BKpVIYOoQoR7ZJ0s1/RBkQ82iGhUM5sI0NYvBI2c5XdRBf+tv2ydizXC4av5 RT0B2vMLJm8UJqGImTaXGLLfMq4p+9jUQYqNtzQjHLm16DIuyqc72kBJeDf0Pv132g uUztI4KMFx5bqUrzEMtC/cD/KsGt7C9+z2Zp8aLQ= X-Riseup-User-ID: C7681DE33D841D10802BA66F211D8F4F7EB3CDF6A95852A7D18ADBD1023D7873 Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id BB015120CAB for ; Thu, 11 Apr 2019 11:18:00 -0700 (PDT) To: doh@ietf.org References: From: nusenu Openpgp: preference=signencrypt Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA== Message-ID: <631dbbb0-99e4-8828-9451-870b19f0a184@riseup.net> Date: Thu, 11 Apr 2019 18:17:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FsQfWf6FnUaEzgBLb5YiPfPplW6O2V3zq" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:18:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FsQfWf6FnUaEzgBLb5YiPfPplW6O2V3zq Content-Type: multipart/mixed; boundary="AfvnkEs4R21chxzaCjhfgc17Y8kJKu5MQ"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <631dbbb0-99e4-8828-9451-870b19f0a184@riseup.net> Subject: Re: Dedicated DoH port References: In-Reply-To: --AfvnkEs4R21chxzaCjhfgc17Y8kJKu5MQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Tomas Krizek: > If an admin is already running an https service on the machine, the > clash with DoH resolver can be quite problematic. In best case scenario= , > the admin runs into an error (not able to bind to port 443 - quite > cryptical for someone trying to run DNS resolver who's not up to date > about DoH development).=20 I assume knot-resolver will not enable DoH by default anyway and so it is an explicit step by the administrator to enable DoH, right? In that case the administrator will read your documentation on how=20 to enable the DoH listener and that could say that it uses HTTPS and HTTPS is on 443. > Since there is currently no IANA assigned DoH port, I've filed the > following user port request with IANA to establish a common default tha= t > could be used among DNS vendors. >=20 > Service Name: [domain-doh] > Desired Port Number: [44353] > Description: [DNS query-response protocol over HTTPS] Since DNS-over-HTTPS is specified to use HTTPS as transport and 443 has been assigned for HTTPS, I think it would cause more confusio= n to assign an additional port since it is still HTTPS. 44353 would be "default DoH port in knot-resolver" but not "DNS-over-HTTPS" as per RFC8484. I understand your motivation behind it but I believe documentation should cover most of the issue and if you really want to avoid starting if there is something else already binding on that port you could detect that at startup and refuse to start, no? --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --AfvnkEs4R21chxzaCjhfgc17Y8kJKu5MQ-- --FsQfWf6FnUaEzgBLb5YiPfPplW6O2V3zq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlyvhNMACgkQrWE4wkXN Qn4GAw//ZTOJBOM7+OQKwArcuocNfOwgYie5vwz8uq1VPA9j2jLDnvshib7yJ8qN I0cuCwEMLzYf0MnHV5RjlP3aDVoaDb/0oes2PLQSozQEC6J1cZU87dsxOLdsV3af xtJJHpO4uyQmCp7cE1NeoxamnpB0cbrUGNEAf8kOSgppkAKSN/3l0qwrT7+Dw0XT 4TQGqHUGEJiRPARTR+uZOMy71B10ebyuVJCCGDSUSbgBFoxN/mTKYlJAsPB1N952 /pOn1dvQv/nAP1gw4tlh+dm+aWQOZZzNy/N0sJcaDjT6eKNJhdfh6c/QnA895PdT bfu90DQ45qBRd4PfzGDrghlAOJWYM3JRNdfCFuJkNElctx+NFKoGAmH2vbqeiGB8 yH9JyogRTTXzThMB/zPO7qtijzA2EFrTJVA4neYbe3wsS/K/3iRCKfVToeZl9Ak2 wvmBAUs6w+Oan9FCDAMG0PiK7hVO/cyZ3SDyUhGsent19QZKqNyf5JMz0Sz6SAcN DwpI23RjnYco077s0iiB/wV6wiUi5wchjUQRfzK3RH4qJEz71cSDzV0cFdLH41+G U1JMYuOTmnS/T/PA6vBabTWu+nLD9AVXR5qpzVnHtua6gksvRb8PO+VXtdUh508F LNy/VgyiHzvXAiDiDYTkKRw/Z2I5jQyy+hykNxYEM/8jknMZweA= =2C8c -----END PGP SIGNATURE----- --FsQfWf6FnUaEzgBLb5YiPfPplW6O2V3zq-- From nobody Thu Apr 11 11:21:58 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4F8120309 for ; Thu, 11 Apr 2019 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7_37q_P6In1n for ; Thu, 11 Apr 2019 11:21:54 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 22BAB120086 for ; Thu, 11 Apr 2019 11:21:54 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id t15so2355984uao.5 for ; Thu, 11 Apr 2019 11:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d5yKodGdAGdCwphXBs7HSNLnA4Q8THGdh8xBW8hmoVQ=; b=GXvIe8QH/74iVAioQYz+1sHhXPe5Eae0UD4wklErw6hwoAxFX6iuU90+yViuFkY9ku z4J/hYdV6BRakjVnsByCdSQARudLkH2QXBI+5iuF4sfSqLvJUmG4rku90H5M6i3MyvAu VHCVUGZveV4zFWM3KvOqTj/lVIyKefCG3q78y+7anmbEuHzXV4gQxpNdUz90+NA6uIAs Bmjsva8QQ3ikEcwf4gtmjnorvrz5cDb6ysQHLYOpxnOEbCf7GKUNrCvHbxh6hnr7BMhk etFQmJpRvBLoWTuq7XyWvrK0jk5jxPGUQV9lhQh8C68uq2PdsqD278ZknbsfYV+DuRfF rZew== 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=d5yKodGdAGdCwphXBs7HSNLnA4Q8THGdh8xBW8hmoVQ=; b=XO7R+J7ZJCbWjakuaNu10YtuQrj2AAVzDaA081bxCAJPFQqXvut+ydoixgMN/fmth7 yZge3cZZ6C3wTu46+epS7qemD4vPIBUWUk2INXOsvofl8s5hfgPjYXf/osDR2eex/4Pf B4bvCUTDJLFnm+aP66wSAJg24nAce/u30quSqSyJ5Bcq/uKPd5eyVeHy5cwfU6ePaat0 U67IIQYDa4CxT/TpL7k3i8YEFIqZ/XpYnV3WrgRg7tNO2erz977AFLDel6dbNvYPmcRC xPjcgLOgIkYceucMmNxCOndqsI6LrT78CTaQXW6a6dNJThixvtL+xWASn15TELSR5gaK 0rBQ== X-Gm-Message-State: APjAAAXk6t8ThgCXWHBEG72+B1T0sTJkkAOu2wWlFKY11xoVfg/Aoscb YtI3U2XSPAUzo98DQWvoWxFdWoWKR45TXvVCHvB30rGcjIPTMA== X-Google-Smtp-Source: APXvYqzvj/DRy2UFH2sG4MMPXFk7Lv2RQjHYzcZ1ppDvw6EOMqAFa2/zAREg3g79nAlfov33i1qj9JdEYWH1IK77iz4= X-Received: by 2002:ab0:23c1:: with SMTP id c1mr20938172uan.71.1555006912695; Thu, 11 Apr 2019 11:21:52 -0700 (PDT) MIME-Version: 1.0 References: <472EC8F4-A610-4FF1-825B-2427AEE31F25@rfc1035.com> In-Reply-To: <472EC8F4-A610-4FF1-825B-2427AEE31F25@rfc1035.com> From: Ben Schwartz Date: Thu, 11 Apr 2019 14:21:40 -0400 Message-ID: To: Jim Reid Cc: Tomas Krizek , DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b1742f05864542fc" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:21:57 -0000 --000000000000b1742f05864542fc Content-Type: multipart/alternative; boundary="000000000000a8059d0586454235" --000000000000a8059d0586454235 Content-Type: text/plain; charset="UTF-8" Tomas, as you know, DNS-over-HTTPS is an HTTP service, identified by a unique path. HTTP is designed to multiplex multiple services on different paths, sharing the same port. Rather than choose a fixed port from the ephemeral range (which may already be in use if you are sufficiently unlucky), I recommend using 443 as the default for users who do not want multiplexing, and implementing FastCGI support for users who want to operate their own HTTPS frontend. This would give you compatibility with essentially all common HTTPS frontend servers: https://en.wikipedia.org/wiki/FastCGI#Web_servers_that_implement_it. On Thu, Apr 11, 2019 at 2:11 PM Jim Reid wrote: > > > > On 11 Apr 2019, at 18:41, Tomas Krizek wrote: > > > > Since there is currently no IANA assigned DoH port, I've filed the > > following user port request with IANA to establish a common default that > > could be used among DNS vendors. > > > > Service Name: [domain-doh] > > Desired Port Number: [44353] > > Description: [DNS query-response protocol over HTTPS] > > This seems a bit hasty. Perhaps there should be an I-D or RFC first? > Allocating a port number from the well-known range might be a wiser choice > than arbitrarily choosing 44353. > > I'm not sure it's a good idea to allocate a port number just so someone > can run a web server and DoH-capable DNS server on the same box. That's > unlikely to be a common use case. Besides, the web server could just > forward inbound DoH queries to port 53 over the loopback interface. Or > something like that. > > Another solution might be to update the current discovery draft to include > an (optional?) port number as well as the IP address to use for DoH service. > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000a8059d0586454235 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tomas, as you know, DNS-over-HTTPS is an HTTP service, ide= ntified by a unique path.=C2=A0 HTTP is designed to multiplex multiple serv= ices on different paths, sharing the same port.

Rather t= han choose a fixed port from the ephemeral range (which may already be in u= se if you are sufficiently unlucky), I recommend using 443 as the default f= or users who do not want multiplexing, and implementing FastCGI support for= users who want to operate their own HTTPS frontend.=C2=A0 This would give = you compatibility with essentially all common HTTPS frontend servers:=C2=A0= https://en.wikipedia.org/wiki/FastCGI#Web_servers_that_implement_it.

On Thu, Apr 11, 2019 at 2:11 PM Jim Reid <jim@rfc1035.com> wrote:


> On 11 Apr 2019, at 18:41, Tomas Krizek <tomas.krizek@nic.cz> wrote:
>
> Since there is currently no IANA assigned DoH port, I've filed the=
> following user port request with IANA to establish a common default th= at
> could be used among DNS vendors.
>
> Service Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[domain-doh]
> Desired Port Number:=C2=A0 [44353]
> Description:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [DNS query-response pro= tocol over HTTPS]

This seems a bit hasty. Perhaps there should be an I-D or RFC first? Alloca= ting a port number from the well-known range might be a wiser choice than a= rbitrarily choosing 44353.

I'm not sure it's a good idea to allocate a port number just so som= eone can run a web server and DoH-capable DNS server on the same box. That&= #39;s unlikely to be a common use case. Besides, the web server could just = forward inbound DoH queries to port 53 over the loopback interface. Or some= thing like that.

Another solution might be to update the current discovery draft to include = an (optional?) port number as well as the IP address to use for DoH service= .
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000a8059d0586454235-- --000000000000b1742f05864542fc Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBUDgkBEepUJpuJr1KTc++r ygHuoRXEh6eLYHLIxmRF/TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA0MTExODIxNTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAaPyFlTY7CREGj0U53UTSDFABlyA/mmVVGHTH00/i 8pC4uIAHqwU3DZDiyIBbrYrxNJIXuf6QFfwUsisNPH4iFUAqL4mBxhiwYJrpYg/dMKYmMVeJcjAo dNfTtPCt3Qj3/aSh70qjPRJzd6V0Y9OMXDRiXRh2VjUKNQLJee1eFMXVTFhxXZrtoP8MRpLepixm DorojzmPk8LpcMWJbFC4vOQtOMJVV45oYkzLRLg3dRNHro3WJDAFICmGoyJ6+DeuncSHkX/mEW/u Kp7rzOiiae4OsrhJQ4YTZjoL6KsDAMs6XkymQWQi1qGl6eU/anplG4mXm2LeBFBsub688lc6TQ== --000000000000b1742f05864542fc-- From nobody Thu Apr 11 11:23:04 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5145312030F for ; Thu, 11 Apr 2019 11:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 Fx1yq6vvHYkY for ; Thu, 11 Apr 2019 11:23:02 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 012C9120086 for ; Thu, 11 Apr 2019 11:23:01 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x3BIHWEH005525; Thu, 11 Apr 2019 19:23:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=rAFxyl0cu7X6bJV2RdLXYOt4oaUUW+1GpfBldesCjGs=; b=MH/5DCdg5fE9wUHCCPPByM7HmxOl7335P+N2EaY2CLK5TN4ZrdGyN7oCj8gEJHJgIWWP ChutoXsg043n/rP3qJZQdgdi3V4qibMwYSQf8q94A+scBvLxe8vmXTDifU6Tv8CDMYnR PI+pcSIHT9hGd50DaUTz6uz/DYwmHpGeaaJLtqaiqLRID+/yiSmQwTgN5rVH3Op4gQsC RuaFnB7Ad0P1JsURbUGccatIrLtm3DUTpJvY0yUnOqChs2EEAbPYmQF/tWbYwRTXMop5 zZcBZeILDgFIV7k1f64G/uKv3rgrgXWUfs6YbgUhuXJxlWxqMB55Ev1LQUnVPU84ql+I Ug== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2rspuq4b15-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 19:23:00 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x3BIIsIA024667; Thu, 11 Apr 2019 14:22:59 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2rpqevh17n-1; Thu, 11 Apr 2019 14:22:59 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 8F683817EC; Thu, 11 Apr 2019 18:22:59 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1hEeLi-0002zL-H1; Thu, 11 Apr 2019 13:22:58 -0500 Date: Thu, 11 Apr 2019 13:22:58 -0500 From: Benjamin Kaduk To: nusenu Cc: doh@ietf.org Message-ID: <20190411182257.GG6282@akamai.com> References: <631dbbb0-99e4-8828-9451-870b19f0a184@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <631dbbb0-99e4-8828-9451-870b19f0a184@riseup.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=932 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110122 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-11_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=952 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110122 Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:23:03 -0000 On Thu, Apr 11, 2019 at 06:17:00PM +0000, nusenu wrote: > > > Tomas Krizek: > > If an admin is already running an https service on the machine, the > > clash with DoH resolver can be quite problematic. In best case scenario, > > the admin runs into an error (not able to bind to port 443 - quite > > cryptical for someone trying to run DNS resolver who's not up to date > > about DoH development). > > I assume knot-resolver will not enable DoH by default anyway and so > it is an explicit step by the administrator to enable DoH, right? > In that case the administrator will read your documentation on how > to enable the DoH listener and that could say that it uses HTTPS > and HTTPS is on 443. > > > Since there is currently no IANA assigned DoH port, I've filed the > > following user port request with IANA to establish a common default that > > could be used among DNS vendors. > > > > Service Name: [domain-doh] > > Desired Port Number: [44353] > > Description: [DNS query-response protocol over HTTPS] > Since DNS-over-HTTPS is specified to use HTTPS as transport > and 443 has been assigned for HTTPS, I think it would cause more confusion > to assign an additional port since it is still HTTPS. (My understanding is that the current expert for the port registry takes a very similar stance to this.) -Ben From nobody Thu Apr 11 12:27:32 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832DC120604 for ; Thu, 11 Apr 2019 12:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=lgdtDX9g; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=rM34V0p1 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 iXMYUH9MGqSf for ; Thu, 11 Apr 2019 12:27:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04AB01203AB for ; Thu, 11 Apr 2019 12:27:29 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555010847; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=0vgp24qMN8iwNb568USfvldxpHszkkH3vcvU0TsOTwQ=; b=lgdtDX9gT7t9NKQxkv4O6hujQPrfXfa/+CN7jGLfDEf0OIS/Yy99qpGz VhFtUD79VFaPXWuqCzyRjA9N4pNyCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555010847; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=0vgp24qMN8iwNb568USfvldxpHszkkH3vcvU0TsOTwQ=; b=rM34V0p1sfl/8Syw7L5/OZ46WLjS5GebvoR9jSiv2OeY0asLHgHqvtmG 2Bls+0YmR/fMrh2JoLvywlWzh95q7alyfSsLWycWFx6ikWNy7UyK+LAg3q AC0/TEiSv3rFIVeSzvoyHjIOvUnGK1SCzajMvD7njvT6jlRXs/oLtc1+Js NKino+7NmCWGfq5C+EiUc79NB/E7c4I1Rn+UpUKY2N3EJeFLqlYoh03vaH Sry3OLjxzQCvFL15pwYHVWlO6vMqvMaiDYNG1jqKUxGuuXHPMSCE+tXQ5s 6shFTRsqH29d0pekYNA/K/fY5fQvIQFZ3NzCs9Iwrp7++7G79mVpTg== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 50B2EF99E; Thu, 11 Apr 2019 15:27:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A5896200D8; Thu, 11 Apr 2019 15:23:06 -0400 (EDT) From: Daniel Kahn Gillmor To: Tomas Krizek , doh@ietf.org In-Reply-To: References: Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 11 Apr 2019 15:23:06 -0400 Message-ID: <87tvf48hyd.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 19:27:30 -0000 --=-=-= Content-Type: text/plain On Thu 2019-04-11 19:41:42 +0200, Tomas Krizek wrote: > Service Name: [domain-doh] > Desired Port Number: [44353] > Description: [DNS query-response protocol over HTTPS] i agree with other commenters that this seems like it might not a useful allocation for a number of reasons. For knot-resolver specifically, i'd much rather it ship with DoH disabled by default. In terms of integration into a modern GNU/Linux system, an interested admin can do "systemctl enable kresd-doh.socket" to turn it on on port 443. Or, you could imagine providing a separate OS-level "knot-resolver-doh" package that depends on knot-resolver, supplies the necessary module and .socket unit file, and explicitly conflicts with the other OS-level packages that would typically listen on port 443. Either of these solutions seems better to me (and easier for an administrator) than establishing a distinct TCP port for DoH. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXK+UGgAKCRB2GBllKa5f +Dr/AQCrLl5Eyb3CwkNSQsoDvvG2NAnxg8miVpoT2bFvzGgtzwD+L/KGISaco9k9 jWi5x8sdKz/GA6z3EMnfFOAdoUuWSgs= =f8TR -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 12 03:16:00 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A11120287 for ; Fri, 12 Apr 2019 03:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 EvMpdSCOc1Rx for ; Fri, 12 Apr 2019 03:15:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 88F3512019E for ; Fri, 12 Apr 2019 03:15:54 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:67c:1220:80c:8010:dac7:96a7:dd53]) by mail.nic.cz (Postfix) with ESMTPSA id 4005662923; Fri, 12 Apr 2019 12:15:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555064151; bh=tE3UIfKh3NDVCf+K+oyxgTXfLTO4tmhzcg7maP02RzY=; h=To:From:Date; b=WYgDBqh/9XNLa/QrjVuKXDYbnEcyw/JY9C3PWy9CrqJth68zIWqxWxy6NxnYXQKgM FoTY+oeN2d9cKGwblbIprQpf1j4dfkWdsSP1RnVYD1cAoZQ1T+bMTRLxpkzOgkyJw8 HFgkouQxKtCnOmgpkQLcXa0jIk+5W28DsY/YvI2U= To: Daniel Kahn Gillmor , doh@ietf.org References: <87tvf48hyd.fsf@fifthhorseman.net> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Openpgp: preference=signencrypt Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCBQZXRyIFNwYWNl ayA8cGV0ci5zcGFjZWtAbmljLmN6PokCVAQTAQgAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIe AQIXgBYhBL4m67nL4FmzkQyjW86N1qGlCiHkBQJcEOXhBQkFp4LgAAoJEM6N1qGlCiHkxNwQ ALFyQ7Rrghf0rM9GN2+kgP92Qvot21h8/Je3bRTvoLyhYUXcAMRmODZQ/0EsjExFc+pRwn+E 0GD2TpiorDnRMpJYEmHqenYGIrZ5TE0lHwwu0fi/X3evDY4j68OFlim5Q6+7pHOlZWaRsSm5 T6blSwIaNDFYtBhI0X1ZXTGqbXIUBFuGxolo/xEgUkeDy+6D4R8yT17CTHkuGYYrfUYnoBTr j3xMVil/lNMievaklAL8kRNVl0It4M8VzHTyEdMq7pG0CJ0CfU8COizCsu4+zy8dsxMVE0Su hju05LSsClZ9X1csxSK9HjKq+TG1Hx2qciFHRB1qC2mNIvWTm10Gkj4tLTWcJp3k2Wyv+1K2 sLFxreGOwbx0uR7XtIIBTiiZAiVsjBH0D39qG2ZLz+bJkQvlTDZQuXzsMS51wROvTVxPYcXX p069hON2+/QqJasmpOHhOydGkB3uokA0crqvMOnK+EcueKQQspvdLGiFLefJPuM8VVyR9fFZ YjnX2vfGZbE+MxY8wG4mDbhgxsUORAEtNUH/G0dvTv66fzKpl5q9GIZs7el+1IU31w7KivgS 7fsWcOsdzq4KzZzNBRJtEDoxX4b9lQ8P6ttMlPi7PnQ+iN0OUxKSnAnKQiqKMFRO1zH22vn7 iiF4JMO32//0HcpsyV8oEdjDkSJsFRnDfLW2uQINBFhri/0BEADFp4ZfxSoKTAad0IkFK9CV oZ6XKywYLFNPPhzw++gbvHL2EX7QqhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQo u0FeSNnzRGb607U8OFOPQ+ei92Mm1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkh wtWU/6yo+RZs7cFRuihuLl8FuoP0A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAw GDtjWkBVawpoHWwq58OQSx5piwyOCnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdW Jw5OV9BoA7UTHG95xVHV5QiEm6q6igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8 mmKyS8E+mSh3djmqdJNHF1pJqKxAxPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03d uzocyU95DfP/lwNJr5SH918Vf1t7WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkS eXNoMlHJOIqbqm7N414I0HytbENf7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw 3f3Gn3+PDzGEHI9sfQv/mYvO77oRSGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6If ZZ0OIWKLSRa/DQARAQABiQI8BBgBCAAmAhsMFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ 5fcFCQWngvoACgkQzo3WoaUKIeTg+w/9Gyp5EcB4AoR3vKVxP0SAh1zBher3bh9uGaKTAWt0 +0v8fyZYGEPqZr//9rkodPnXbQnr9ogzjJmZpsPvGPyRZikWjYIwkfM2Vb4BCyr5wQ9++9KB kob5zCQmUw2o7s/gISpFsCC5B0eYusArVDnrCyrroyaxbN6MpUb5lzVMEOCzYljtdrPRAXPL FKRm3ijLV0RcYPzJJVOPV5EzUfCtGsGTXXRI9Y9O/7lFaJ+iWnwygo/Xoi0IgBHvOAj9Gp3Q 0BY+sI6Rgzm9dbddm8gYJ4+FjfZivI7fbdfSubTWvrtFmFdHovIPJYLvXK7hUG22ww4CneIF D4oZSVy9xUoqJf0qQNruzEqTr7y7lbZIzxgPCSVmH0jpgJ1po6RLaJllNA+ZklOQ76fCMiaD 5yQuJluwD5w+acPWTbmZX6DijGHPZSjzeUkiMKctYSRqVUo6JmK0dgwwm3l1/Orb4D3YsLVP QDa4ZrCfSldrGC3zkEJ8iCVSYQwlc0JfIxyn8C3LLxToPYeFv/bQTeDYBjaV7a0SQ/xKUdpg RFzrGrxj7CM2WHcpxCLVK0agobuUO7YXoufHRM6y0rfMwT10baDjh+hLKMshxTqsP55lWvtM SleSGjheVTiZChb3jK0rUPCC4Rg3gDTEQsptC3TgN48PtLpmhsNc4JPm64zlrreInZQ= Organization: CZ.NIC Message-ID: Date: Fri, 12 Apr 2019 12:16:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87tvf48hyd.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 10:15:58 -0000 On 11. 04. 19 21:23, Daniel Kahn Gillmor wrote: > On Thu 2019-04-11 19:41:42 +0200, Tomas Krizek wrote: >> Service Name: [domain-doh] >> Desired Port Number: [44353] >> Description: [DNS query-response protocol over HTTPS] > > i agree with other commenters that this seems like it might not a useful > allocation for a number of reasons. > > For knot-resolver specifically, i'd much rather it ship with DoH > disabled by default. Can you elaborate on the reasons, please? Do you oppose enabling DoT by default as well? It utterly confuses me that this very WG on one hand invented DoH protocol because DoT is not good enough, but then WG participants claims it should not be enabled by default. > In terms of integration into a modern GNU/Linux system, an interested > admin can do "systemctl enable kresd-doh.socket" to turn it on on port > 443. Or, you could imagine providing a separate OS-level > "knot-resolver-doh" package that depends on knot-resolver, supplies the > necessary module and .socket unit file, and explicitly conflicts with > the other OS-level packages that would typically listen on port 443. > > Either of these solutions seems better to me (and easier for an > administrator) than establishing a distinct TCP port for DoH. Can you elaborate? I do not understand where "easiness" of manual configuration comes from. Here my reasoning on this topic: Current state of DoH protocol is that it requires manual configuration on all clients. In near future it is going to rely on hardcoded values from browser vendor. I.e. actual hostname and port number are irrelevant because admin (or vendor) has copy&paste then anyway. Draft https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-03 might be different story if WG decides to go with solutions other than section 3, but honestly it seems that draft is not going to get consensus any time soon. My reading of this mailing list indicates that there is strong opposition to any insecure means of discovery, which renders the draft useless and we are back to copy&pasted or hardcoded values. So, how is it easier to copy&paste or hardcode https://doh.example.com/doh vs. https://doh.example.com:44353/doh ? Having dedicated port could allow us to do everything automatically so only copy&paste is left for admin. Default on port used by other services requires even more manual manual configuration, which goes against idea of having as many resolvers available as we can, with as little effort as possible. So, why should we make it harder for admins to make it available? I'm eager to hear reasons. -- Petr Špaček @ CZ.NIC From nobody Fri Apr 12 04:05:54 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD07A120641 for ; Fri, 12 Apr 2019 04:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 89_bKWnUx2uO for ; Fri, 12 Apr 2019 04:05:44 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (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 A0AFA120381 for ; Fri, 12 Apr 2019 04:05:43 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id x3CB5agQ026919 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Apr 2019 13:05:36 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id x3CB5Zun026915; Fri, 12 Apr 2019 13:05:36 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 12 Apr 2019 13:05:35 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: =?ISO-8859-2?Q?Petr_=A9pa=E8ek?= cc: Daniel Kahn Gillmor , doh@ietf.org In-Reply-To: Message-ID: References: <87tvf48hyd.fsf@fifthhorseman.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1129329158-2055282175-1555067136=:31156" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 11:05:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-2055282175-1555067136=:31156 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 12 Apr 2019, Petr Špaček wrote: > It utterly confuses me that this very WG on one hand invented DoH protocol > because DoT is not good enough, but then WG participants claims it should > not be enabled by default. We're all individuals here. We have different opinions and views. You'll even find that some of us disagree! -- / daniel.haxx.se --1129329158-2055282175-1555067136=:31156-- From nobody Fri Apr 12 04:39:59 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF9C1202A3 for ; Fri, 12 Apr 2019 04:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 eoc1hrRCuX25 for ; Fri, 12 Apr 2019 04:39:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832FF1202A1 for ; Fri, 12 Apr 2019 04:39:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38F26BE51 for ; Fri, 12 Apr 2019 12:39:55 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18lXpiosw_B7 for ; Fri, 12 Apr 2019 12:39:54 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D5EC6BE2E for ; Fri, 12 Apr 2019 12:39:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1555069193; bh=Qokw0DZ3AwDqFRJazlrkPUQyX0lbIHL2HYiPgsnFfVE=; h=To:From:Subject:Date:From; b=aepJp1k4Cpl9OcJItpic5XuFwulyGGJrJeFBCR2VrsnqtLrfmxVQbpJs4D4KsSgiZ Orhv0ktnRxsBFF16L8We/qj5CzX6K8oFUNGolU5BmrrZJqRxFfCiu23e4z+PQpiB6x To1VEJpaAlPWGAt0RYKo238JGgLrLJF4X6jLDQ4U= To: doh@ietf.org From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> Date: Fri, 12 Apr 2019 12:39:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ocrVPfcVvnJI25qgXNnXGJEaQkwfXp6Cp" Archived-At: Subject: [Doh] handling HTTP re-directs in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 11:39:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ocrVPfcVvnJI25qgXNnXGJEaQkwfXp6Cp Content-Type: multipart/mixed; boundary="bPHAyPiDE04lYreXGfqIAWKjSokAKOvDZ"; protected-headers="v1" From: Stephen Farrell To: doh@ietf.org Message-ID: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> Subject: handling HTTP re-directs in DoH --bPHAyPiDE04lYreXGfqIAWKjSokAKOvDZ Content-Type: multipart/mixed; boundary="------------708228B0B19C720AED37933D" Content-Language: en-GB This is a multi-part message in MIME format. --------------708228B0B19C720AED37933D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Discussion on another list prompted me to re-read 8484 to see if I can understand what's supposed to happen if a DoH server returns a 3xx. I didn't find an explicit answer in the RFC, so am wondering what implementers do in that case? Thanks, S. --------------708228B0B19C720AED37933D Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------708228B0B19C720AED37933D-- --bPHAyPiDE04lYreXGfqIAWKjSokAKOvDZ-- --ocrVPfcVvnJI25qgXNnXGJEaQkwfXp6Cp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyweQkACgkQWrL68XsX K+pRvg//fEO0VIHHuY3g3m9bLkWMq8y0xfezQZP7ix3N6GpVmiCsynZl4b0Zc9gf p/MzB20VLpzt2h9XnCzjBt8Bn4emUZkPSvkuhjNhIdcq79WZL+011nROL/uKKYOW gMIwx6LQcM8HIIDOnZynXg5jbZubp2tLKYZtqEQshQhUUAZhRptuzjwvM5J4bTV5 G7X8knjQietY+9Kff+dqFZEhZlWfGlCDnNPDvUDeeJKwfFt0ZW2+TmlcTtVSsvht tFgT+17QkgxAYEArUBshonTLlyaOZjW2WNp5tmFzvIgEukD90cKlps/4GHP2VYwD eQFH1vkt4J9O2mP82ThM9AR/KmXMopcvCEi6mdSdyH3piwFLIpBAGOG5pA/tJZj9 lkZJDZYNVmDjtH6owiHyJGJgTpTo1MVzfQ5oAY6Qep5JPS6vX8J+UIAwpGak40PY U8i6ULVZVTFbHkroUnVvNgZyONoflRr4hMGry3ZQhooNB0pIapf9e9mPstvO4fiV YGo256tUQQY+OF9NQaJL2HBlcNxqe7L8ERZxEf9MyzdDA/1seaGMGwImNOfCr0WX CjE8i9uotut8eIUpEd7zJzJaJmrCo2ducX6hV/Hp6ZoW554GbBpxslNHd9vu9NlL er3bZd0AQJD07Bto68bC6PrkHv9EwpY6fgxRs0prX/fbjY0zONU= =wQk1 -----END PGP SIGNATURE----- --ocrVPfcVvnJI25qgXNnXGJEaQkwfXp6Cp-- From nobody Fri Apr 12 05:44:34 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED931203A1 for ; Fri, 12 Apr 2019 05:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 aYxfW-dYErvP for ; Fri, 12 Apr 2019 05:44:30 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (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 EC294120373 for ; Fri, 12 Apr 2019 05:44:29 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id x3CCiO3L003421 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Apr 2019 14:44:24 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id x3CCiOo0003380; Fri, 12 Apr 2019 14:44:24 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 12 Apr 2019 14:44:24 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Stephen Farrell cc: doh@ietf.org In-Reply-To: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> Message-ID: References: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] handling HTTP re-directs in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 12:44:32 -0000 On Fri, 12 Apr 2019, Stephen Farrell wrote: > Discussion on another list prompted me to re-read 8484 to see if I can > understand what's supposed to happen if a DoH server returns a 3xx. I didn't > find an explicit answer in the RFC, so am wondering what implementers do in > that case? I *think* the Firefox implementation will follow them if received. The curl implementation does not (mostly because of doing as little as possible until proven necessary). I've not seen any DoH server implementation actually send any redirects (but I also haven't looked very hard). 3xx responses are part of HTTP so why shouldn't they be acknowledged? I'd say that also goes for 1xx responses, 401 responses and more. -- / daniel.haxx.se From nobody Fri Apr 12 07:54:45 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DF01207D7 for ; Fri, 12 Apr 2019 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 t9-D1tneJLUu for ; Fri, 12 Apr 2019 07:54:43 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 D752112006F for ; Fri, 12 Apr 2019 07:54:42 -0700 (PDT) Received: from [10.32.60.122] (50-1-99-176.dsl.dynamic.fusionbroadband.com [50.1.99.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x3CEqnD7074344 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Apr 2019 07:52:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-99-176.dsl.dynamic.fusionbroadband.com [50.1.99.176] claimed to be [10.32.60.122] From: "Paul Hoffman" To: "Stephen Farrell" Cc: doh@ietf.org Date: Fri, 12 Apr 2019 07:54:32 -0700 X-Mailer: MailMate (1.12.4r5594) Message-ID: <7B1712E7-114A-431E-809F-DCD612627FB8@vpnc.org> In-Reply-To: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> References: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Doh] handling HTTP re-directs in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:54:44 -0000 On 12 Apr 2019, at 4:39, Stephen Farrell wrote: > Discussion on another list prompted me to re-read 8484 to > see if I can understand what's supposed to happen if a DoH > server returns a 3xx. I didn't find an explicit answer in > the RFC, so am wondering what implementers do in that case? DoH is HTTPS. A DoH client is an HTTPS client. Redirects, caching, everything is plain HTTP and TLS. --Paul Hoffman From nobody Fri Apr 12 07:56:08 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE0F1207E0 for ; Fri, 12 Apr 2019 07:56: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=eHg6Vz3N; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=WZCyhibZ 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 2F_Y3o0cprTO for ; Fri, 12 Apr 2019 07:56:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8ED1207DE for ; Fri, 12 Apr 2019 07:56:03 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555080962; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oxplh7tMESSgIcdZ7Z6DnMamv7+lN97jIJc6loSpQjs=; b=eHg6Vz3N1DQHRXTBdUklbYqnsBu+K5iQV0hLkp/DG6n8N/J99uXCF7jy FnDJ/tY267kraXAhP4YMXxfjcwkrCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555080962; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oxplh7tMESSgIcdZ7Z6DnMamv7+lN97jIJc6loSpQjs=; b=WZCyhibZ0yqVjsXieUR3buDUywx0vVHpOqAs2kMzAtohFVleBV/jK6r4 Eaya4naITIH0zYmuRd5clWKW5IQV/WB0+m915mF02HxvN4t1lEgC3auTzW fm9V9/2pxNQkiOVBecwZ1HP3mfoqxrWu77wEdvAbGsf+Ls2a9t0Bz209b+ 0ne2JIIO3ztL5qBBAx0znq6SNrwoYLFrItIY6klPtBA7vbwl0B01pyBe2W O8ZwuK19soX/HeOUARSqhWljLQrE2mVJ9IvhaYdLS34Q4UkG4GSJnxfHaJ O0PuujYSPOoGu6vTm6YIu7Y0Whb6pKypQ0Gy2Dr8jv9MJHDMyXXCSQ== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E6257F99F; Fri, 12 Apr 2019 10:56:01 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A9FE4200E8; Fri, 12 Apr 2019 08:31:24 -0400 (EDT) From: Daniel Kahn Gillmor To: Petr =?utf-8?B?xaBwYcSNZWs=?= , doh@ietf.org In-Reply-To: References: <87tvf48hyd.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 12 Apr 2019 08:31:24 -0400 Message-ID: <877ebz8kwz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 14:56:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri 2019-04-12 12:16:31 +0200, Petr =C5=A0pa=C4=8Dek wrote: > On 11. 04. 19 21:23, Daniel Kahn Gillmor wrote: >> For knot-resolver specifically, i'd much rather it ship with DoH >> disabled by default. > > Can you elaborate on the reasons, please? * one of the advantages of DoH is that it is indistinguishable from HTTPS traffic. a distinct port defeats that advantage. * the proposed port is in the port range typically used by ephemeral port allocation, not something that would typically be assigned by IANA * system administrators who enable DoH services should probably prefer to offer other HTTPS content on the same HTTPS endpoint (e.g. at least a configuration page, so that when someone points their browser at this URL they get something human-readable). It seems plausible that this requirement means that the DoH endpoint requires coordination/integration with any local https machniery anyway. * We went through this with the OpenPGP keyserver network years ago, when we were trying to figure out how to move HKP to HKPS. The initial attempt was to put it on some special port like 11372, but that ended up making hkps less useful because it couldn't get through restrictive firewalls, so we moved to 443 instead. Almost all hkps servers today use port 443, and clients have defaulted to it as well. This is network ossification for sure, but it's also a fact of the modern, messed-up thing that we call the Internet. > Do you oppose enabling DoT by default as well? No, because nothing else is using port 853. I very strongly advocate DoT being enabled by default, because none of the concerns above apply to DoT, which was always going to be distinguishable on the wire from traditional DNS-over-UDP or DNS-over-TCP. Note that it's also possible to run DoT on port 443 in coordination with an https service, if you want to avoid the ossification concerns mentioned above (https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/). This is currently done on port 443 of dns.cmrg.net if you want to try it. > It utterly confuses me that this very WG on one hand invented DoH > protocol because DoT is not good enough, but then WG participants claims > it should not be enabled by default. I offered those mechanisms in the context of Tomas's concern that offering it automatically on the standard port (443) would be problematic for those services that run on the same machine as a different https endpoint. I already offered two different ways to make it easy for an administrator to enable DoH on the standard port with knot-resolver, including one that involves nothing more than installing an operating system package, something an admin will need to do anyway. [ trimming Petr's serious and relevant concerns about our plans for smooth configuration, which i agree with but think we should take up in a separate thread ] > So, how is it easier to copy&paste or hardcode > https://doh.example.com/doh > vs. > https://doh.example.com:44353/doh > ? it's not a question of ease -- it's a question of semantics. If you want end users to understand what they're connecting to (with all the various tradeoffs we've already talked about with DoH), you need to ensure that the string you're asking them to input is semantically meaningful. I've voiced my displeasure elsewhere about the idea that the user needs configure DoH with a full URL, and not just a hostname -- because most users (and maybe even some IETFers) don't understand what a URL is, or what the semantic difference is between entering https://doh.example.net/doh or https://doh.example.net/bananas here. (for that matter, most users don't even understand what a hostname is, but due to browser same-origin policy, public advertising campaigns, etc, they probably have at least a closer fuzzy concept of "site" than they do of "URL"). But users *definitely* don't understand what it means to enter :44353 as part of the URL. If we want to argue that these choices about who to trust with sensitive data involve meaningful user action/consent, we need make the choices that the user handles here as simple as possible. Encouraging the wider propagation of ":44353" as part of the broader ecosystem is encouraging people to make the (not insignificant) trust decision about their DNS resolver based on magic strings that they don't understand. Let's try to keep that to a minimum. Furthermore, the specific action requested here was to ask IANA to allocate a port for this -- if the port were allocated to doh, then perhaps that changes the URL from https:// to doh:// in which case the magic ":44353" is no longer needed. But the distinct port has all of the disadvantages mentioned above, and now users will have to distinguish between doh:// URLs and https:// URLs when making their choices about who to entrust their sensitive data to -- another thing that users won't understand. > So, why should we make it harder for admins to make it available? The only "harder" part you're objecting to afaict is a single administrative command, executed during configuration of the DNS resolver daemon. The tradeoff is a significant amount of complexity for the rest of the ecosystem, and potential worse interaction with the users. I don't think that's a good tradeoff. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLCFHAAKCRB2GBllKa5f +NmoAQC0a7Z0MxzVI+Dj5BHJlkhOzpEw8fAKwxhqvviH2kol1QD/dEwGhKHIJKRz 5ou2ZcUwXfPYIqqtMOMVr6kZiLWViA0= =MvDP -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 12 08:00:29 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6731208B3 for ; Fri, 12 Apr 2019 08:00:23 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham 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 p7BDnSxDAcar for ; Fri, 12 Apr 2019 08:00:18 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52864120894 for ; Fri, 12 Apr 2019 08:00:15 -0700 (PDT) Received: from [192.168.249.138] (unknown [195.15.22.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 088F8242109D; Fri, 12 Apr 2019 15:00:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <877ebz8kwz.fsf@fifthhorseman.net> Date: Fri, 12 Apr 2019 16:00:11 +0100 Cc: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87tvf48hyd.fsf@fifthhorseman.net> <877ebz8kwz.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 15:00:28 -0000 > On 12 Apr 2019, at 13:31, Daniel Kahn Gillmor = wrote: >=20 > The only "harder" part you're objecting to afaict is a single > administrative command, executed during configuration of the DNS > resolver daemon. The tradeoff is a significant amount of complexity = for > the rest of the ecosystem, and potential worse interaction with the > users. >=20 > I don't think that's a good tradeoff. +1000 From nobody Fri Apr 12 08:25:19 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E197E12083D for ; Fri, 12 Apr 2019 08:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 EfxRp3_wto4P for ; Fri, 12 Apr 2019 08:25:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B191202CE for ; Fri, 12 Apr 2019 08:25:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7BDCBDCF; Fri, 12 Apr 2019 16:25:11 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9XDRfoOtJBf; Fri, 12 Apr 2019 16:25:10 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 312ECBE2C; Fri, 12 Apr 2019 16:25:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1555082710; bh=i3QNA7AoAzfyvP+W8l86EYnmcnc4jivcvYYGQ09YebQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=3DkWiAe+NbnE4rRaoaBCHFxIqsPsNwlh25ITZRrc8dOVHXZS1GPnofi13C14eeUtp NDcz4xP5GQcdbn8YsrrwgmfLzfGj/wQFeH5A1zetcxrOLx3CGTxxhuahMPQX+Q/X6V zKXur9l0Ey4isuMsnU9G5sdlVLucEhZFrT5LNESI= To: Paul Hoffman Cc: doh@ietf.org References: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> <7B1712E7-114A-431E-809F-DCD612627FB8@vpnc.org> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <9eaf37bb-b014-9e3a-9a26-d9af8812d44b@cs.tcd.ie> Date: Fri, 12 Apr 2019 16:25:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <7B1712E7-114A-431E-809F-DCD612627FB8@vpnc.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jYQYlrutMtWUw82jVPBl6Vzg9H5ugCBrn" Archived-At: Subject: Re: [Doh] handling HTTP re-directs in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 15:25:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jYQYlrutMtWUw82jVPBl6Vzg9H5ugCBrn Content-Type: multipart/mixed; boundary="b6x07kujfougUXFUODHXZg6w4W2SF4gBR"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman Cc: doh@ietf.org Message-ID: <9eaf37bb-b014-9e3a-9a26-d9af8812d44b@cs.tcd.ie> Subject: Re: [Doh] handling HTTP re-directs in DoH References: <925aa4c9-d28d-d4b3-1461-2dfb17f40fac@cs.tcd.ie> <7B1712E7-114A-431E-809F-DCD612627FB8@vpnc.org> In-Reply-To: <7B1712E7-114A-431E-809F-DCD612627FB8@vpnc.org> --b6x07kujfougUXFUODHXZg6w4W2SF4gBR Content-Type: multipart/mixed; boundary="------------B5CD7AAF8B86233F2D528491" Content-Language: en-GB This is a multi-part message in MIME format. --------------B5CD7AAF8B86233F2D528491 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, > On 12 Apr 2019, at 4:39, Stephen Farrell wrote: >=20 >> Discussion on another list prompted me to re-read 8484 to >> see if I can understand what's supposed to happen if a DoH >> server returns a 3xx. I didn't find an explicit answer in >> the RFC, so am wondering what implementers do in that case? >=20 On 12/04/2019 13:44, Daniel Stenberg wrote: > I *think* the Firefox implementation will follow them if received. The > curl implementation does not (mostly because of doing as little as > possible until proven necessary). Thanks. On 12/04/2019 15:54, Paul Hoffman wrote: > DoH is HTTPS. A DoH client is an HTTPS client. Redirects, caching, > everything is plain HTTP and TLS. Well, a) see above, and b) I asked about what implementers are doing not what they ought be doing:-) Cheers, S. >=20 > --Paul Hoffman >=20 --------------B5CD7AAF8B86233F2D528491 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------B5CD7AAF8B86233F2D528491-- --b6x07kujfougUXFUODHXZg6w4W2SF4gBR-- --jYQYlrutMtWUw82jVPBl6Vzg9H5ugCBrn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlywrdQACgkQWrL68XsX K+rBHRAAghvPZgM/WMTB0LaNZKmQBbzbGDJKXqHVB+wytH4GTcSO7eGcxVSCqydA YT1eZIBZOtdtlgVzbBOqITIEHqEAfP+e9sgv8fPa0FlgiZ0eSrVPd2qTBQZo/nka yLKjAEzt3Ygide/wkBh3MxV6KU5HKejACF33Y/6IYGZ8be5Mio/1ytGs+9CLWdv/ cIy3MQbseBmkl166phCuNrVhrIgPGJuZlugNPjWueb4vBB16AcihBsja3kKe34cb v5oghpK7HyEn1Pk4ZvYAE+6f8N0rATgOhVuznXYl6WPK3rIbYt4FaW/YSlZo+vNl y7PL5hSetzpg86Ft6CjyC9C+GXfrCdmnVJVUfOwkHTjeheqleJQObBm8nvjAQaeJ +3tgnbP3lm1qm4cBtPlrVJw9x03Imhn2kYBCASFYRxVKZzPeYP9ijWv+hgnxMVn9 q53+NDdVMJsMVhd/PsdZYeG+TK2MTJAbdu/GpUnk2iCQiSXj2WcJakopX3KL6THa o9ArslAd8138ff6bJ3ZDVaem93KX+UuSlnFAUVo7ASWjnVIcsY7Y4PEXLn566puS Z57q8DnsRok+tI3y+w0Lrw22pZYtQMo5VEDo931JrySNRVJe7skIdS1bCZY9oEoo +qxa+j9ODjDFN5E+VSaGhO/LtRV/n0+fJvhWHXzKnVwuWjXweeY= =oXCZ -----END PGP SIGNATURE----- --jYQYlrutMtWUw82jVPBl6Vzg9H5ugCBrn-- From nobody Fri Apr 12 10:46:22 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CB21203C0 for ; Fri, 12 Apr 2019 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 tuZcboDUctMi for ; Fri, 12 Apr 2019 10:46:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 A87341200FE for ; Fri, 12 Apr 2019 10:46:17 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:67c:1220:80c:8010:dac7:96a7:dd53]) by mail.nic.cz (Postfix) with ESMTPSA id D96DB63416; Fri, 12 Apr 2019 19:46:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555091174; bh=XTTndjYB+KjeDAHdJX606IrbqFLExcmGkEhjBwUl9kI=; h=To:From:Date; b=OoWusduGKTqxNec+bZRwXkPGM4LjX0mYhtMLlGwe/MsgSdxc6ZMEDGcYg09XtS5RK lEsDyYdR6RBlSQpm5YXVB8+0xTjED9yLthIJgrJgasXmCIT9qkQ6Pg1lK5ssaS78XV RgTFxuAJTTvETWOs8rwlih2aGwuYs9DZx0iMUOHk= To: Daniel Kahn Gillmor , doh@ietf.org References: <87tvf48hyd.fsf@fifthhorseman.net> <877ebz8kwz.fsf@fifthhorseman.net> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Openpgp: preference=signencrypt Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCBQZXRyIFNwYWNl ayA8cGV0ci5zcGFjZWtAbmljLmN6PokCVAQTAQgAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIe AQIXgBYhBL4m67nL4FmzkQyjW86N1qGlCiHkBQJcEOXhBQkFp4LgAAoJEM6N1qGlCiHkxNwQ ALFyQ7Rrghf0rM9GN2+kgP92Qvot21h8/Je3bRTvoLyhYUXcAMRmODZQ/0EsjExFc+pRwn+E 0GD2TpiorDnRMpJYEmHqenYGIrZ5TE0lHwwu0fi/X3evDY4j68OFlim5Q6+7pHOlZWaRsSm5 T6blSwIaNDFYtBhI0X1ZXTGqbXIUBFuGxolo/xEgUkeDy+6D4R8yT17CTHkuGYYrfUYnoBTr j3xMVil/lNMievaklAL8kRNVl0It4M8VzHTyEdMq7pG0CJ0CfU8COizCsu4+zy8dsxMVE0Su hju05LSsClZ9X1csxSK9HjKq+TG1Hx2qciFHRB1qC2mNIvWTm10Gkj4tLTWcJp3k2Wyv+1K2 sLFxreGOwbx0uR7XtIIBTiiZAiVsjBH0D39qG2ZLz+bJkQvlTDZQuXzsMS51wROvTVxPYcXX p069hON2+/QqJasmpOHhOydGkB3uokA0crqvMOnK+EcueKQQspvdLGiFLefJPuM8VVyR9fFZ YjnX2vfGZbE+MxY8wG4mDbhgxsUORAEtNUH/G0dvTv66fzKpl5q9GIZs7el+1IU31w7KivgS 7fsWcOsdzq4KzZzNBRJtEDoxX4b9lQ8P6ttMlPi7PnQ+iN0OUxKSnAnKQiqKMFRO1zH22vn7 iiF4JMO32//0HcpsyV8oEdjDkSJsFRnDfLW2uQINBFhri/0BEADFp4ZfxSoKTAad0IkFK9CV oZ6XKywYLFNPPhzw++gbvHL2EX7QqhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQo u0FeSNnzRGb607U8OFOPQ+ei92Mm1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkh wtWU/6yo+RZs7cFRuihuLl8FuoP0A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAw GDtjWkBVawpoHWwq58OQSx5piwyOCnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdW Jw5OV9BoA7UTHG95xVHV5QiEm6q6igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8 mmKyS8E+mSh3djmqdJNHF1pJqKxAxPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03d uzocyU95DfP/lwNJr5SH918Vf1t7WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkS eXNoMlHJOIqbqm7N414I0HytbENf7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw 3f3Gn3+PDzGEHI9sfQv/mYvO77oRSGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6If ZZ0OIWKLSRa/DQARAQABiQI8BBgBCAAmAhsMFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ 5fcFCQWngvoACgkQzo3WoaUKIeTg+w/9Gyp5EcB4AoR3vKVxP0SAh1zBher3bh9uGaKTAWt0 +0v8fyZYGEPqZr//9rkodPnXbQnr9ogzjJmZpsPvGPyRZikWjYIwkfM2Vb4BCyr5wQ9++9KB kob5zCQmUw2o7s/gISpFsCC5B0eYusArVDnrCyrroyaxbN6MpUb5lzVMEOCzYljtdrPRAXPL FKRm3ijLV0RcYPzJJVOPV5EzUfCtGsGTXXRI9Y9O/7lFaJ+iWnwygo/Xoi0IgBHvOAj9Gp3Q 0BY+sI6Rgzm9dbddm8gYJ4+FjfZivI7fbdfSubTWvrtFmFdHovIPJYLvXK7hUG22ww4CneIF D4oZSVy9xUoqJf0qQNruzEqTr7y7lbZIzxgPCSVmH0jpgJ1po6RLaJllNA+ZklOQ76fCMiaD 5yQuJluwD5w+acPWTbmZX6DijGHPZSjzeUkiMKctYSRqVUo6JmK0dgwwm3l1/Orb4D3YsLVP QDa4ZrCfSldrGC3zkEJ8iCVSYQwlc0JfIxyn8C3LLxToPYeFv/bQTeDYBjaV7a0SQ/xKUdpg RFzrGrxj7CM2WHcpxCLVK0agobuUO7YXoufHRM6y0rfMwT10baDjh+hLKMshxTqsP55lWvtM SleSGjheVTiZChb3jK0rUPCC4Rg3gDTEQsptC3TgN48PtLpmhsNc4JPm64zlrreInZQ= Organization: CZ.NIC Message-ID: Date: Fri, 12 Apr 2019 19:46:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <877ebz8kwz.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Language: cs Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 17:46:21 -0000 On 12. 04. 19 14:31, Daniel Kahn Gillmor wrote: > On Fri 2019-04-12 12:16:31 +0200, Petr Špaček wrote: >> On 11. 04. 19 21:23, Daniel Kahn Gillmor wrote: >>> For knot-resolver specifically, i'd much rather it ship with DoH >>> disabled by default. >> >> Can you elaborate on the reasons, please? > > * one of the advantages of DoH is that it is indistinguishable from > HTTPS traffic. a distinct port defeats that advantage. > > * the proposed port is in the port range typically used by ephemeral > port allocation, not something that would typically be assigned by > IANA > > * system administrators who enable DoH services should probably prefer > to offer other HTTPS content on the same HTTPS endpoint (e.g. at > least a configuration page, so that when someone points their browser > at this URL they get something human-readable). It seems plausible > that this requirement means that the DoH endpoint requires > coordination/integration with any local https machniery anyway. > > * We went through this with the OpenPGP keyserver network years ago, > when we were trying to figure out how to move HKP to HKPS. The > initial attempt was to put it on some special port like 11372, but > that ended up making hkps less useful because it couldn't get through > restrictive firewalls, so we moved to 443 instead. Almost all hkps > servers today use port 443, and clients have defaulted to it as well. > This is network ossification for sure, but it's also a fact of the > modern, messed-up thing that we call the Internet. > >> Do you oppose enabling DoT by default as well? > > No, because nothing else is using port 853. I very strongly advocate > DoT being enabled by default, because none of the concerns above apply > to DoT, which was always going to be distinguishable on the wire from > traditional DNS-over-UDP or DNS-over-TCP. > > Note that it's also possible to run DoT on port 443 in coordination with > an https service, if you want to avoid the ossification concerns > mentioned above > (https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/). > This is currently done on port 443 of dns.cmrg.net if you want to try > it. > >> It utterly confuses me that this very WG on one hand invented DoH >> protocol because DoT is not good enough, but then WG participants claims >> it should not be enabled by default. > > I offered those mechanisms in the context of Tomas's concern that > offering it automatically on the standard port (443) would be > problematic for those services that run on the same machine as a > different https endpoint. > > I already offered two different ways to make it easy for an > administrator to enable DoH on the standard port with knot-resolver, > including one that involves nothing more than installing an operating > system package, something an admin will need to do anyway. > > [ trimming Petr's serious and relevant concerns about our plans for > smooth configuration, which i agree with but think we should take up > in a separate thread ] > >> So, how is it easier to copy&paste or hardcode >> https://doh.example.com/doh >> vs. >> https://doh.example.com:44353/doh >> ? > > it's not a question of ease -- it's a question of semantics. > > If you want end users to understand what they're connecting to (with all > the various tradeoffs we've already talked about with DoH), you need to > ensure that the string you're asking them to input is semantically > meaningful. > > I've voiced my displeasure elsewhere about the idea that the user needs > configure DoH with a full URL, and not just a hostname -- because most > users (and maybe even some IETFers) don't understand what a URL is, or > what the semantic difference is between entering > https://doh.example.net/doh or https://doh.example.net/bananas here. > (for that matter, most users don't even understand what a hostname is, > but due to browser same-origin policy, public advertising campaigns, > etc, they probably have at least a closer fuzzy concept of "site" than > they do of "URL"). > > But users *definitely* don't understand what it means to enter :44353 as > part of the URL. If we want to argue that these choices about who to > trust with sensitive data involve meaningful user action/consent, we > need make the choices that the user handles here as simple as possible. > > Encouraging the wider propagation of ":44353" as part of the broader > ecosystem is encouraging people to make the (not insignificant) trust > decision about their DNS resolver based on magic strings that they don't > understand. Let's try to keep that to a minimum. > > Furthermore, the specific action requested here was to ask IANA to > allocate a port for this -- if the port were allocated to doh, then > perhaps that changes the URL from https:// to doh:// in which case the > magic ":44353" is no longer needed. But the distinct port has all of > the disadvantages mentioned above, and now users will have to > distinguish between doh:// URLs and https:// URLs when making their > choices about who to entrust their sensitive data to -- another thing > that users won't understand. > >> So, why should we make it harder for admins to make it available? > > The only "harder" part you're objecting to afaict is a single > administrative command, executed during configuration of the DNS > resolver daemon. The tradeoff is a significant amount of complexity for > the rest of the ecosystem, and potential worse interaction with the > users. > > I don't think that's a good tradeoff. > > --dkg Thank you for elaborate reply, I will think about it. -- Petr Špaček @ CZ.NIC From nobody Fri Apr 12 11:46:02 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE00120486 for ; Fri, 12 Apr 2019 11:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 97EyguAGFsbk for ; Fri, 12 Apr 2019 11:45:56 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 4DABF1204AE for ; Fri, 12 Apr 2019 11:45:56 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id z17so12353561qts.13 for ; Fri, 12 Apr 2019 11:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tfliy+vIrq/naozv0VOSnoSNl08GY3Vg1BJD7yv14Ho=; b=Uhw06OaAJb+gnNQIm2PD03NPFNpJ+xjKoTGkIVM/caDRQVGZj3+iEhk93X+cHTaqY4 agPt6PjxwB6yeXvIEqk7u3S2CTMztlGqn7GAbQkTOK8fkWmFZj3w4Hs1txAd7giIxb4d EM/4HT5Oaw0RBhYOPl0lV3jt/MXB/eRP8ftNB2Z6RmheTLKAac7NTxA6+U7kv6Ltmply D8qkRpfj2sS20+lpV8MbeIn8w26ZTr5hJt+q1iiJdvz1KOCRbulcDx5oxGk0whyHz05b ywCYDIDhGgsF+Q0TG7P2KJ7Dc+MeRbrt8yPfF+RLTMsYBIY2d/59BlDz+NsoeebMuCdM 8B1g== 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=Tfliy+vIrq/naozv0VOSnoSNl08GY3Vg1BJD7yv14Ho=; b=iU3GGdyfDbaZuUoHnqhkkMjjcPMZ6eZTmbTMEsEMQNX1dCjuiacCbRXhEhdtonXrst exhfL8kaZNjmFd6EFCNJaKHkTz2Oy2AWr73mvTPVX8xaJlo45pgBi853NTBTJZwJ4+SH /oHMwRYfc/FXnPcgctp9c34ye4CZ3dechm3mS0JQRUBno7Dz+QvgsdSpVDv1Pj5qQ4f/ l3Mz9KsB82XVnHQZeczJS9G8gWEUHRrlDXY3roP26LSgQsPcUcNLnLXeWBjBUvLmXHz0 XAc1tvdd7EXue3GS9Zxw3ZhuX2JP0kxyMPF/T0rkXGOvpl7f9UuoCvt03tMuAmNEnqiC +Nqg== X-Gm-Message-State: APjAAAXbjnvzuajqmMa8vD30Yk8XFn+NjmCujfWKWBr8ZB5UlN2yuczi zOujgDBcRMEFi/3XF1Fs55toqR0xl5zFzV0ODus= X-Google-Smtp-Source: APXvYqz0J3mWQgjRWPY/bOmu0nxTopIaAVMlZdTju41eAyvkuCFs7eCe6TBpwTWqkbDCwjsbkJKF0fMA9hrhlZbw2kI= X-Received: by 2002:ac8:38f5:: with SMTP id g50mr46709000qtc.119.1555094755216; Fri, 12 Apr 2019 11:45:55 -0700 (PDT) MIME-Version: 1.0 References: <87tvf48hyd.fsf@fifthhorseman.net> <877ebz8kwz.fsf@fifthhorseman.net> In-Reply-To: <877ebz8kwz.fsf@fifthhorseman.net> From: Brian Dickson Date: Fri, 12 Apr 2019 11:45:43 -0700 Message-ID: To: Daniel Kahn Gillmor Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , DoH WG Content-Type: multipart/alternative; boundary="0000000000007a10fa058659b663" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 18:46:00 -0000 --0000000000007a10fa058659b663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Top-posting one comment, and then additional comments provided in-line. Please read this comment carefully, as I believe it frames the issue in ways not included at the start of this thread. Having a DISTINCT port for DoH, does not necessarily REQUIRE that it be the ONLY port for DoH. Think of it as an additional port, rather than a substitute port. Some DNS resolvers (offering DoH) might listen only on the substitute port. Some DNS resolvers (offering DoH) might listen only on the traditional (443) port. Some DNS resolvers (offering DoH) might listen on both ports. All of the above is orthogonal to whether the above resolvers listen on 853, 53, or other ports. (A DNS resolver listening on 443 might or might not offer other services on 443.) On Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor wrote: > On Fri 2019-04-12 12:16:31 +0200, Petr =C5=A0pa=C4=8Dek wrote: > > On 11. 04. 19 21:23, Daniel Kahn Gillmor wrote: > >> For knot-resolver specifically, i'd much rather it ship with DoH > >> disabled by default. > > > > Can you elaborate on the reasons, please? > > * one of the advantages of DoH is that it is indistinguishable from > HTTPS traffic. a distinct port defeats that advantage. > This is a bug, not a feature, from the perspective of enterprise networks who want to avoid having DNS traffic on 443. Having DoH clients and understand both DoH:443 and DoH:DISTINCT_PORT facilitates the two use cases (non-enterprise and enterprise). > > * the proposed port is in the port range typically used by ephemeral > port allocation, not something that would typically be assigned by > IANA > > * system administrators who enable DoH services should probably prefer > to offer other HTTPS content on the same HTTPS endpoint (e.g. at > least a configuration page, so that when someone points their browser > at this URL they get something human-readable). It seems plausible > that this requirement means that the DoH endpoint requires > coordination/integration with any local https machniery anyway. > This is true ONLY if the end-point is a general-purpose HTTP(S) server. I know for a fact that some resolver operators do not intend on running DNS resolvers on machines offering other HTTP(S) content. I know for a fact that some resolver operators do not want to us general-purpose HTTP(S) server software to implement DoH. And in the possible case where, for whatever reason, the same IP address is hosting multiple services (DoH and HTTP(S)), it might not be the case that the DoH and HTTP(S) sessions are terminated on the same server (e.g. virtualized server environments, or servers behind load balancers sharing an external IP.) > > * We went through this with the OpenPGP keyserver network years ago, > when we were trying to figure out how to move HKP to HKPS. The > initial attempt was to put it on some special port like 11372, but > that ended up making hkps less useful because it couldn't get through > restrictive firewalls, so we moved to 443 instead. Almost all hkps > servers today use port 443, and clients have defaulted to it as well. > This is network ossification for sure, but it's also a fact of the > modern, messed-up thing that we call the Internet. > > > Do you oppose enabling DoT by default as well? > > No, because nothing else is using port 853. I very strongly advocate > DoT being enabled by default, because none of the concerns above apply > to DoT, which was always going to be distinguishable on the wire from > traditional DNS-over-UDP or DNS-over-TCP. > > Note that it's also possible to run DoT on port 443 in coordination with > an https service, if you want to avoid the ossification concerns > mentioned above > (https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/). > This is currently done on port 443 of dns.cmrg.net if you want to try > it. > > This gets dangerously close to "bike-shed" arguments, or maybe "straw man" logic. Yes, it is *possible* to do . This does not mean that it is reasonable for to be mandated, e.g. if there are important distinctions in which makes much better (more scalable for instance, or more secure, or whatever), than . In this case =3D 443, =3D DISTINCT_PORT. > > It utterly confuses me that this very WG on one hand invented DoH > > protocol because DoT is not good enough, but then WG participants claim= s > > it should not be enabled by default. > > I offered those mechanisms in the context of Tomas's concern that > offering it automatically on the standard port (443) would be > problematic for those services that run on the same machine as a > different https endpoint. > > I already offered two different ways to make it easy for an > administrator to enable DoH on the standard port with knot-resolver, > including one that involves nothing more than installing an operating > system package, something an admin will need to do anyway. There are MANY more resolvers than knot, including some number of independent implementations (not open source). What needs to be achieved is interoperability, without specific dependencies on specific implementations, IMHO. As open a *protocol* (or standard, or whatever you want to call it) is required, which should not be dependent about assumptions about the host OS or resolver software. > > [ trimming Petr's serious and relevant concerns about our plans for > smooth configuration, which i agree with but think we should take up > in a separate thread ] > > > So, how is it easier to copy&paste or hardcode > > https://doh.example.com/doh > > vs. > > https://doh.example.com:44353/doh > > ? > > it's not a question of ease -- it's a question of semantics. > > If you want end users to understand what they're connecting to (with all > the various tradeoffs we've already talked about with DoH), you need to > ensure that the string you're asking them to input is semantically > meaningful. > This basically gets to the UI issue vs the service offered issue. I don't think it is either necessary or useful for the connection details to be exposed to users in this way. The UI can very easily display "example.com" and have this associated with whatever the DoH operator of example.com wants. It is the operator of "example.com", and not the user, who knows what the full URI is (including port numbers if appropriate). It might be the case that the operator of "example.com" provides more than one end-point (DoH:443 and DoH:DISTINCT_PORT, and possibly DoT:853), and either wants that exposed for user selection, or prefers that the DoH client (e.g. browser) determine which end-points are currently reachable, and use the first one in an ordered list that is accessible. In some use cases, the operator might want the user to know that port 433 is available, and for the user to select that for . > > I've voiced my displeasure elsewhere about the idea that the user needs > configure DoH with a full URL, and not just a hostname -- because most > users (and maybe even some IETFers) don't understand what a URL is, or > what the semantic difference is between entering > https://doh.example.net/doh or https://doh.example.net/bananas here. > (for that matter, most users don't even understand what a hostname is, > but due to browser same-origin policy, public advertising campaigns, > etc, they probably have at least a closer fuzzy concept of "site" than > they do of "URL"). > > But users *definitely* don't understand what it means to enter :44353 as > part of the URL. If we want to argue that these choices about who to > trust with sensitive data involve meaningful user action/consent, we > need make the choices that the user handles here as simple as possible. > > Encouraging the wider propagation of ":44353" as part of the broader > ecosystem is encouraging people to make the (not insignificant) trust > decision about their DNS resolver based on magic strings that they don't > understand. Let's try to keep that to a minimum. > > Furthermore, the specific action requested here was to ask IANA to > allocate a port for this -- if the port were allocated to doh, then > perhaps that changes the URL from https:// to doh:// in which case the > magic ":44353" is no longer needed. But the distinct port has all of > the disadvantages mentioned above, and now users will have to > distinguish between doh:// URLs and https:// URLs when making their > choices about who to entrust their sensitive data to -- another thing > that users won't understand. > > > So, why should we make it harder for admins to make it available? > > The only "harder" part you're objecting to afaict is a single > administrative command, executed during configuration of the DNS > resolver daemon. The tradeoff is a significant amount of complexity for > the rest of the ecosystem, and potential worse interaction with the > users. > > See the top of my message about why _DNS RESOLVER_ operators, rather than generic system administrators, might prefer NOT to use 443. This changes the balance of the trade-off on the server side. The client side should be designed to support whatever the server operator offers. This might mean more complex under-the-hood configuration, or more complex service discovery. However, this only needs to occur when the client establishes the DNS resolver connection, which should only be needed when network connections change, or when the DNS resolver connection is reset/broken/fails (regardless of why). > I don't think that's a good tradeoff. > > --dkg > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000007a10fa058659b663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Top-posting one comment, and then additional comments= provided in-line.

Please read this comment carefu= lly, as I believe it frames the issue in ways not included at the start of = this thread.

Having a DISTINCT port for DoH, does = not necessarily REQUIRE that it be the ONLY port for DoH.

Think of it as an additional port, rather than a substitute port.
Some DNS resolvers (offering DoH) might listen only on the substit= ute port.
Some DNS resolvers (offering DoH) might listen only on = the traditional (443) port.
Some DNS resolvers (offering DoH) mig= ht listen on both ports.
All of the above is orthogonal to whethe= r the above resolvers listen on 853, 53, or other ports.
(A DNS r= esolver listening on 443 might or might not offer other services on 443.)
On= Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Fri 2019-04-12 12:16:31 +0200, = Petr =C5=A0pa=C4=8Dek wrote:
> On 11. 04. 19 21:23, Daniel Kahn Gillmor wrote:
>> For knot-resolver specifically, i'd much rather it ship with D= oH
>> disabled by default.
>
> Can you elaborate on the reasons, please?

=C2=A0* one of the advantages of DoH is that it is indistinguishable from =C2=A0 =C2=A0HTTPS traffic.=C2=A0 a distinct port defeats that advantage.

This is a bug, not a feature, from the p= erspective of enterprise networks who want to avoid having DNS traffic on 4= 43.

Having DoH clients and understand both DoH:443= and DoH:DISTINCT_PORT facilitates the two use cases (non-enterprise and en= terprise).
=C2=A0

=C2=A0* the proposed port is in the port range typically used by ephemeral<= br> =C2=A0 =C2=A0port allocation, not something that would typically be assigne= d by
=C2=A0 =C2=A0IANA

=C2=A0* system administrators who enable DoH services should probably prefe= r
=C2=A0 =C2=A0to offer other HTTPS content on the same HTTPS endpoint (e.g. = at
=C2=A0 =C2=A0least a configuration page, so that when someone points their = browser
=C2=A0 =C2=A0at this URL they get something human-readable).=C2=A0 It seems= plausible
=C2=A0 =C2=A0that this requirement means that the DoH endpoint requires
=C2=A0 =C2=A0coordination/integration with any local https machniery anyway= .

This is true ONLY if the end-point is= a general-purpose HTTP(S) server.

I know for a fa= ct that some resolver operators do not intend on running DNS resolvers on m= achines offering other HTTP(S) content.
I know for a fact that so= me resolver operators do not want to us general-purpose HTTP(S) server soft= ware to implement DoH.

And in the possible case wh= ere, for whatever reason, the same IP address is hosting multiple services = (DoH and HTTP(S)), it might
not be the case that the DoH and HTTP= (S) sessions are terminated on the same server (e.g. virtualized server env= ironments,
or servers behind load balancers sharing an external I= P.)
=C2=A0

=C2=A0* We went through this with the OpenPGP keyserver network years ago,<= br> =C2=A0 =C2=A0when we were trying to figure out how to move HKP to HKPS.=C2= =A0 The
=C2=A0 =C2=A0initial attempt was to put it on some special port like 11372,= but
=C2=A0 =C2=A0that ended up making hkps less useful because it couldn't = get through
=C2=A0 =C2=A0restrictive firewalls, so we moved to 443 instead.=C2=A0 Almos= t all hkps
=C2=A0 =C2=A0servers today use port 443, and clients have defaulted to it a= s well.
=C2=A0 =C2=A0This is network ossification for sure, but it's also a fac= t of the
=C2=A0 =C2=A0modern, messed-up thing that we call the Internet.

> Do you oppose enabling DoT by default as well?

No, because nothing else is using port 853.=C2=A0 I very strongly advocate<= br> DoT being enabled by default, because none of the concerns above apply
to DoT, which was always going to be distinguishable on the wire from
traditional DNS-over-UDP or DNS-over-TCP.

Note that it's also possible to run DoT on port 443 in coordination wit= h
an https service, if you want to avoid the ossification concerns
mentioned above
(https://datatracker.ietf.org/doc/d= raft-dkg-dprive-demux-dns-http/).
This is currently done on port 443 of dns.cmrg.net if you want to try
it.


This gets dangerously close to "b= ike-shed" arguments, or maybe "straw man" logic.
<= br>
Yes, it is *possible* to do <some action> <some way&= gt;.

This does not mean that it is reasonable for = <some way> to be mandated,
e.g. if there are important dist= inctions in <some environment> which makes
<other way>= ; much better (more scalable for instance, or more secure, or whatever),
than <some way>.

In this case <so= me way> =3D 443, <other way> =3D DISTINCT_PORT.

=C2=A0
> It utterly confuses me that this very WG on one hand invented DoH
> protocol because DoT is not good enough, but then WG participants clai= ms
> it should not be enabled by default.

I offered those mechanisms in the context of Tomas's concern that
offering it automatically on the standard port (443) would be
problematic for those services that run on the same machine as a
different https endpoint.

I already offered two different ways to make it easy for an
administrator to enable DoH on the standard port with knot-resolver,
including one that involves nothing more than installing an operating
system package, something an admin will need to do anyway.

There are MANY more resolvers than knot, including some num= ber of independent
implementations (not open source). What needs = to be achieved is interoperability,
without specific dependencies= on specific implementations, IMHO.

As open a *pro= tocol* (or standard, or whatever you want to call it) is required,
which should not be dependent about assumptions about the host OS or reso= lver software.
=C2=A0
=C2=A0

[ trimming Petr's serious and relevant concerns about our plans for
=C2=A0 smooth configuration, which i agree with but think we should take up=
=C2=A0 in a separate thread ]

> So, how is it easier to copy&paste or hardcode
> https://doh.example.com/doh
> vs.
> https://doh.example.com:44353/doh
> ?

it's not a question of ease -- it's a question of semantics.

If you want end users to understand what they're connecting to (with al= l
the various tradeoffs we've already talked about with DoH), you need to=
ensure that the string you're asking them to input is semantically
meaningful.

This basically gets to the = UI issue vs the service offered issue.

I don't= think it is either necessary or useful for the connection details to be ex= posed to users in this way.

The UI can very easily= display "example.com" and hav= e this associated with whatever the DoH operator of example.com wants.
It is the operator of "example.com", and not the user, who knows= what the full URI is (including port numbers if appropriate).
It might be the case that the operator of "example.com" provides more than one end-point (Do= H:443 and DoH:DISTINCT_PORT,
and possibly DoT:853), and either wa= nts that exposed for user selection, or prefers that the DoH client (e.g. b= rowser) determine
which end-points are currently reachable, and u= se the first one in an ordered list that is accessible.

In some use cases, the operator might want the user to know that port= 433 is available, and for the user to select that for <reasons>.
=C2=A0

I've voiced my displeasure elsewhere about the idea that the user needs=
configure DoH with a full URL, and not just a hostname -- because most
users (and maybe even some IETFers) don't understand what a URL is, or<= br> what the semantic difference is between entering
https://doh.example.net/doh or https://doh.example.net/bananas<= /a> here.
(for that matter, most users don't even understand what a hostname is,<= br> but due to browser same-origin policy, public advertising campaigns,
etc, they probably have at least a closer fuzzy concept of "site"= than
they do of "URL").

But users *definitely* don't understand what it means to enter :44353 a= s
part of the URL.=C2=A0 If we want to argue that these choices about who to<= br> trust with sensitive data involve meaningful user action/consent, we
need make the choices that the user handles here as simple as possible.

Encouraging the wider propagation of ":44353" as part of the broa= der
ecosystem is encouraging people to make the (not insignificant) trust
decision about their DNS resolver based on magic strings that they don'= t
understand.=C2=A0 Let's try to keep that to a minimum.

Furthermore, the specific action requested here was to ask IANA to
allocate a port for this -- if the port were allocated to doh, then
perhaps that changes the URL from https:// to doh:// in which case the
magic ":44353" is no longer needed.=C2=A0 But the distinct port h= as all of
the disadvantages mentioned above, and now users will have to
distinguish between doh:// URLs and https:// URLs when making their
choices about who to entrust their sensitive data to -- another thing
that users won't understand.

> So, why should we make it harder for admins to make it available?

The only "harder" part you're objecting to afaict is a single=
administrative command, executed during configuration of the DNS
resolver daemon.=C2=A0 The tradeoff is a significant amount of complexity f= or
the rest of the ecosystem, and potential worse interaction with the
users.





<= div>connection, which should only be needed when network connections change= ,
I don't think that's a good tradeoff.

=C2=A0 --dkg
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000007a10fa058659b663-- From nobody Fri Apr 12 14:01:10 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFE81201A2 for ; Fri, 12 Apr 2019 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=llyNdPsL; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=b6Cuyl5p 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 DgROYDL6eMjL for ; Fri, 12 Apr 2019 14:01:06 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C0C1200EC for ; Fri, 12 Apr 2019 14:01:05 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555102864; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=wQBCV1OsgUa8pGxSTKZsD4WZlsAZXjIpAsOwb+RZXj4=; b=llyNdPsLbkYIyBTTYf4cA6WwLlP0mOyDSiav0V36osZ4P52xE+VA1Oz8 A3TvjuiBbDy3T/UIGGBtN/uKt194AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555102864; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=wQBCV1OsgUa8pGxSTKZsD4WZlsAZXjIpAsOwb+RZXj4=; b=b6Cuyl5pvarzhyiu8qtc8VcP/oiFn+HI3uyz2ymwY8NGmRuoK7guMRzA 3c2sLx/UL41OaCubbwtSU5GotTuw7StI3XbenpG6UQcnwPMNFH81nTpU8l GKHkZ+/PE1S+yrR4UeN/jlXkN4K8gi//5RP+LDOy2Mn0RRTxabB6SS7VFx KHY+KH+KryS2cx3ITgNSGUGOQ63BjMecfUWkm+mikdd+2ywRdG3ELkt1H7 I223ullKIp1ZqOER/qclCyvr73lSPOvYbkWsIxJP/369fYVWbAfDm4F33e QZNb5jJt8u09HyNb7w1tbxNzDTztWECg6TdIad9qA4E+Pj7lnaWr3g== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 80FEAF99D; Fri, 12 Apr 2019 17:01:03 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 40211203B7; Fri, 12 Apr 2019 17:01:01 -0400 (EDT) From: Daniel Kahn Gillmor To: Brian Dickson Cc: Petr =?utf-8?B?xaBwYcSNZWs=?= , DoH WG In-Reply-To: References: <87tvf48hyd.fsf@fifthhorseman.net> <877ebz8kwz.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 12 Apr 2019 17:01:00 -0400 Message-ID: <87v9zj6ir7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:01:09 -0000 --=-=-= Content-Type: text/plain Hi Brian-- Thanks for the thoughtful followup. On Fri 2019-04-12 11:45:43 -0700, Brian Dickson wrote: > Having a DISTINCT port for DoH, does not necessarily REQUIRE that it be the > ONLY port for DoH. Absolutely agreed here, though i note that this discussion is in the context of a proposed IANA registration. I think we can all agree here that operators are always free to run arbitrary services on any port that they like, and what the IANA registry is managing is conventions for use. In the discussion here we're in the process of establishing norms about deployment, not strict requirements. All of my considerations written earlier were intended in that context, and were about how i think the norms we establish here will affect the broader ecosystem. > On Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor wrote: >> * one of the advantages of DoH is that it is indistinguishable from >> HTTPS traffic. a distinct port defeats that advantage. > > This is a bug, not a feature, from the perspective of enterprise networks > who want to avoid having DNS traffic on 443. I'm sorry, but it's a feature, not a bug, for users attached to (or routed through) networks that they neither control nor trust. Keeping it in the enterprise lane: do you want your enterprise users to have their connections to remote DoH servers trivially blockable by some remote network operator that is beholden to a competitor of your enterprise? I certainly don't. >> * system administrators who enable DoH services should probably prefer >> to offer other HTTPS content on the same HTTPS endpoint (e.g. at >> least a configuration page, so that when someone points their browser >> at this URL they get something human-readable). It seems plausible >> that this requirement means that the DoH endpoint requires >> coordination/integration with any local https machniery anyway. > > This is true ONLY if the end-point is a general-purpose HTTP(S) server. > > I know for a fact that some resolver operators do not intend on running DNS > resolvers on machines offering other HTTP(S) content. > I know for a fact that some resolver operators do not want to us > general-purpose HTTP(S) server software to implement DoH. Those operators are encouraged to run (the equivalent of): systemctl enable --now knot-resolver-doh.socket and never have to think about it again. :) For the rest of the operators who care what happens when a curious user probes the actual endpoint in question, they might need to think about it in a bit more detail. And that's fine. I'm trying to preserve both options when it comes to deployment. > And in the possible case where, for whatever reason, the same IP address is > hosting multiple services (DoH and HTTP(S)), it might > not be the case that the DoH and HTTP(S) sessions are terminated on the > same server (e.g. virtualized server environments, > or servers behind load balancers sharing an external IP.) This is a distinct case, and "behind the curtain" of an organization's internal jurisdiction -- i think we expect folks that operate machines in complicated networks to be proficient about fiddling with port and IP address allocation on the systems they control, so norms we establish for the public communications network are less relevant there. >> Note that it's also possible to run DoT on port 443 in coordination with >> an https service, if you want to avoid the ossification concerns >> mentioned above >> (https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/). >> This is currently done on port 443 of dns.cmrg.net if you want to try >> it. > > This gets dangerously close to "bike-shed" arguments, or maybe "straw man" > logic. > > Yes, it is *possible* to do . > > This does not mean that it is reasonable for to be mandated, > e.g. if there are important distinctions in which makes > much better (more scalable for instance, or more secure, or > whatever), than . > > In this case = 443, = DISTINCT_PORT. heh, yes, i agree. to be clear, the demux draft above is a provocation, designed to encourage network protocol designers to think about metadata leakage, channel multiplexing, ossification, privacy, and traffic analysis. It's not at all a "mandate". It's a demonstration of the lengths that people will go to when the network ossifies around them based on designed-in leakage. > There are MANY more resolvers than knot, including some number of > independent implementations (not open source). What needs to be > achieved is interoperability, without specific dependencies on > specific implementations, IMHO. > > As open a *protocol* (or standard, or whatever you want to call it) is > required, which should not be dependent about assumptions about the > host OS or resolver software. Agreed. That's why i think we shouldn't deviate from the standard port 443. > This basically gets to the UI issue vs the service offered issue. > > I don't think it is either necessary or useful for the connection details > to be exposed to users in this way. > > The UI can very easily display "example.com" and have this associated > with whatever the DoH operator of example.com wants. It is the > operator of "example.com", and not the user, who knows what the full > URI is (including port numbers if appropriate). you say "very easily" and i hear "simple matter of UX design" (by analogy with "SMOP"). Perhaps you have UX design background and experience, but the majority of the people i meet at the IETF (including myself) definitely do not, and have given very little thought to the difficulties of designing interoperable, meaningful, secure user experience for the protocols that we use. The example you then give describes a range of things that the protocol needs to expose to the user without giving any clear directive how to do it. I just don't think it's that simple, unless we accept a configuration option that is a pre-populated list with only the names of a handful of operators; but that further entrenches the consolidation concerns i believe we both share. The norms we establish about DoH service discoverability and representation (hopefully in a different thread) will have a real impact on our ability to offer users meaningful choice in their decisions about who to trust with their sensitive metadata. > See the top of my message about why _DNS RESOLVER_ operators, rather > than generic system administrators, might prefer NOT to use 443. By all means, they should offer their services on whatever ports they want. My dns.cmrg.net service offers DoT on several non-standard ports as well (53053 and 443 in addition to the standard 853). But i wouldn't want to register those with IANA. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXLD8jAAKCRB2GBllKa5f +BarAP9Tu0f9qSlxTtYzrKC815Zi/Wh1h2lBfM8RcX7xuzjGcAEAi2Iyv+rQ4kJz owNYtLoqG5BjJcKjEBkJ1XgidWlgZAo= =YZ90 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 12 14:37:52 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E053012031C for ; Fri, 12 Apr 2019 14:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 ZReNQpQY52UX for ; Fri, 12 Apr 2019 14:37:48 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 DFD4C120301 for ; Fri, 12 Apr 2019 14:37:47 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id w30so12943781qta.8 for ; Fri, 12 Apr 2019 14:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y+ieAejMkZ3pqJg3TVpygZBHjdyFaM0whoBUZCYV2Ew=; b=maY5d1ZkUxLV6b0a94RwkpLN3xXG8FkmfG5Zv+l1Va8BP6zghfXfkvdTxiPFNRaAv0 VrhWtRcRM86KeeYLnS8J69oAoD6/2xRnzBht0/s2Cz51GxQsfHKBjaAFx9oiorJsOURg mPpiVdW4MgEXmDwAjPTZxEjPLCSU95VQCZOBPPZzAeL0kU6V31mzQYh5ax4cH1552tBC jU7qqiiLh0bL4WSROWBOhUI8Lx9bvJx7Jhm7CLEXOpzyWlPtA+LwYcaI8bD4uJkoeJ7f 8AF8+1A6s2g9xTSnpFPUUgKZvDMIW7edrSF/Q6eNU3HsZFIPa1rNufR+ge9EjkHeqENB 8Ilw== 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=y+ieAejMkZ3pqJg3TVpygZBHjdyFaM0whoBUZCYV2Ew=; b=cohWZ4BsLVq3oKNAPW6XMns7irOW3v6JLQGfOt5rVBCM3pzrvVJn3wGQrpfAGaximz gN6mP0E1Hb1r1KGb/8e4V9Yy+Sus+kSoQT9FQxp9KcvxK32W5p5ez9x+VGKm8dXhvJ+E ij6sx1G8oXPEtrBEpXg+3vfSrmvIKP/GNwxy4muLfiI0NJkvxmKrVf+iYUpKDTdmuVd7 OeMk9j14nr2wjyCJxFiBTv1ru8eS/1o6hM8MBD6mIvDvswWB8kpIFzpsY7QMbx+R/LD2 vU46WFhj3OWHX33nk8+VlRMgiQt+Yh1nWUoQUM3a8lJacCwhPx7hsCJdS4um0NG2CrqY rZGQ== X-Gm-Message-State: APjAAAXGWV0fGuo/aHt/5r3NRZRUXluwKfOUmNMb+MKBeKC+Kz7A60KR gUW7nhaCwJcMNkDqZ0bYxWrHdJI0AnDhHtZm5fA= X-Google-Smtp-Source: APXvYqzWljpxz1e13IENI6l2OE6vcvb7tFBQ88SQFxipDiPn1OWjK+nNEQaHOauhRnyPvtO+9ivtFxklX2XPstJf3Mw= X-Received: by 2002:a0c:812d:: with SMTP id 42mr2369999qvc.68.1555105066880; Fri, 12 Apr 2019 14:37:46 -0700 (PDT) MIME-Version: 1.0 References: <87tvf48hyd.fsf@fifthhorseman.net> <877ebz8kwz.fsf@fifthhorseman.net> <87v9zj6ir7.fsf@fifthhorseman.net> In-Reply-To: <87v9zj6ir7.fsf@fifthhorseman.net> From: Brian Dickson Date: Fri, 12 Apr 2019 14:37:35 -0700 Message-ID: To: Daniel Kahn Gillmor Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , DoH WG Content-Type: multipart/alternative; boundary="00000000000019968205865c1d2f" Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:37:51 -0000 --00000000000019968205865c1d2f Content-Type: text/plain; charset="UTF-8" On Fri, Apr 12, 2019 at 2:01 PM Daniel Kahn Gillmor wrote: > Hi Brian-- > > Thanks for the thoughtful followup. > You're welcome. (I prefer to think first and only then stick my foot in my mouth. ;-) ) > > On Fri 2019-04-12 11:45:43 -0700, Brian Dickson wrote: > > Having a DISTINCT port for DoH, does not necessarily REQUIRE that it be > the > > ONLY port for DoH. > > Absolutely agreed here, though i note that this discussion is in the > context of a proposed IANA registration. > > I think we can all agree here that operators are always free to run > arbitrary services on any port that they like, and what the IANA > registry is managing is conventions for use. In the discussion here > we're in the process of establishing norms about deployment, not strict > requirements. > > All of my considerations written earlier were intended in that context, > and were about how i think the norms we establish here will affect the > broader ecosystem. > > > On Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor < > dkg@fifthhorseman.net> wrote: > >> * one of the advantages of DoH is that it is indistinguishable from > >> HTTPS traffic. a distinct port defeats that advantage. > > > > This is a bug, not a feature, from the perspective of enterprise networks > > who want to avoid having DNS traffic on 443. > > I'm sorry, but it's a feature, not a bug, for users attached to (or > routed through) networks that they neither control nor trust. > > Keeping it in the enterprise lane: do you want your enterprise users to > have their connections to remote DoH servers trivially blockable by some > remote network operator that is beholden to a competitor of your > enterprise? I certainly don't. > Actually, I want to have my cake and eat it too. In this case, the enterprise use case would probably best be met by: - an enterprise end-point running on a non-443 port (possibly DoT, or DISTINCT_PORT) - which forwards queries to an external DoH provider (on 443) So, the internal user would not have DIRECT access to the external DoH server, but WOULD have indirect access. The enterprise forwarder might do other things (regular DNS stuff, like RPZ, malware detection), but might otherwise be configured/operated so as to not interfere with privacy. Having such a well-defined, standardized DISTINCT_PORT allows an enterprise to easily set that up, without having the problems of 443 outbound DNS leakage. It's something that clearly needs to be figured out between all the parties involved, including the browser software folks, and probably needs to fail safe, if the host is inside an enterprise, the user is not a privileged (admin) user, and no new "opt-in" type extra configurations for these new enhancements have been done (new includes vanilla DoH, IMHO). > > >> * system administrators who enable DoH services should probably prefer > >> to offer other HTTPS content on the same HTTPS endpoint (e.g. at > >> least a configuration page, so that when someone points their browser > >> at this URL they get something human-readable). It seems plausible > >> that this requirement means that the DoH endpoint requires > >> coordination/integration with any local https machniery anyway. > > > > This is true ONLY if the end-point is a general-purpose HTTP(S) server. > > > > I know for a fact that some resolver operators do not intend on running > DNS > > resolvers on machines offering other HTTP(S) content. > > I know for a fact that some resolver operators do not want to us > > general-purpose HTTP(S) server software to implement DoH. > > Those operators are encouraged to run (the equivalent of): > > systemctl enable --now knot-resolver-doh.socket > > and never have to think about it again. :) > > For the rest of the operators who care what happens when a curious user > probes the actual endpoint in question, they might need to think about > it in a bit more detail. And that's fine. I'm trying to preserve both > options when it comes to deployment. > > > And in the possible case where, for whatever reason, the same IP address > is > > hosting multiple services (DoH and HTTP(S)), it might > > not be the case that the DoH and HTTP(S) sessions are terminated on the > > same server (e.g. virtualized server environments, > > or servers behind load balancers sharing an external IP.) > > This is a distinct case, and "behind the curtain" of an organization's > internal jurisdiction -- i think we expect folks that operate machines > in complicated networks to be proficient about fiddling with port and IP > address allocation on the systems they control, so norms we establish > for the public communications network are less relevant there. > > >> Note that it's also possible to run DoT on port 443 in coordination with > >> an https service, if you want to avoid the ossification concerns > >> mentioned above > >> (https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/). > >> This is currently done on port 443 of dns.cmrg.net if you want to try > >> it. > > > > This gets dangerously close to "bike-shed" arguments, or maybe "straw > man" > > logic. > > > > Yes, it is *possible* to do . > > > > This does not mean that it is reasonable for to be mandated, > > e.g. if there are important distinctions in which > makes > > much better (more scalable for instance, or more secure, or > > whatever), than . > > > > In this case = 443, = DISTINCT_PORT. > > heh, yes, i agree. to be clear, the demux draft above is a provocation, > designed to encourage network protocol designers to think about metadata > leakage, channel multiplexing, ossification, privacy, and traffic > analysis. It's not at all a "mandate". It's a demonstration of the > lengths that people will go to when the network ossifies around them > based on designed-in leakage. > > > There are MANY more resolvers than knot, including some number of > > independent implementations (not open source). What needs to be > > achieved is interoperability, without specific dependencies on > > specific implementations, IMHO. > > > > As open a *protocol* (or standard, or whatever you want to call it) is > > required, which should not be dependent about assumptions about the > > host OS or resolver software. > > Agreed. That's why i think we shouldn't deviate from the standard port > 443. > > > This basically gets to the UI issue vs the service offered issue. > > > > I don't think it is either necessary or useful for the connection details > > to be exposed to users in this way. > > > > The UI can very easily display "example.com" and have this associated > > with whatever the DoH operator of example.com wants. It is the > > operator of "example.com", and not the user, who knows what the full > > URI is (including port numbers if appropriate). > > you say "very easily" and i hear "simple matter of UX design" (by > analogy with "SMOP"). Perhaps you have UX design background and > experience, but the majority of the people i meet at the IETF (including > myself) definitely do not, and have given very little thought to the > difficulties of designing interoperable, meaningful, secure user > experience for the protocols that we use. The example you then give > describes a range of things that the protocol needs to expose to the > user without giving any clear directive how to do it. > I see the "under-the-hood" elements and the UX elements as being loosely related but mostly orthogonal. If there is a standardized "publishing" spec for each DNS provider, perhaps as one or more RR types in DNS, in some well-known place (like an underscore namespace, standardized via the IETF), that would allow the mapping of DNS provider's base name to whatever the DNS provider wanted to offer. The UX piece is something separate, and as long as the semantics are preserved, implementations should be free to do whatever they want. At that point, the presentation stuff is truly orthogonal to the publishing/discovery. Also, browser vendors have lots of developers, with hopefully some UX skills and experience. > > I just don't think it's that simple, unless we accept a configuration > option that is a pre-populated list with only the names of a handful of > operators; but that further entrenches the consolidation concerns i > believe we both share. > > The norms we establish about DoH service discoverability and > representation (hopefully in a different thread) will have a real impact > on our ability to offer users meaningful choice in their decisions about > who to trust with their sensitive metadata. > > > See the top of my message about why _DNS RESOLVER_ operators, rather > > than generic system administrators, might prefer NOT to use 443. > > By all means, they should offer their services on whatever ports they > want. My dns.cmrg.net service offers DoT on several non-standard ports > as well (53053 and 443 in addition to the standard 853). But i wouldn't > want to register those with IANA. > > Maybe, but as long as someone does want to register, we should standardize on that, and publish that, as an OPTIONAL port choice to use. A given DNS resolver operator would then have lots of good options, basically as check-boxes: UDP/53, TCP/53, TLS/853, HTTPS/443, HTTPS/NEWPORT, HTTPS/numeric-custom-port-number Brian --00000000000019968205865c1d2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 12, 2019 at 2:01 PM Danie= l Kahn Gillmor <dkg@fifthhorsem= an.net> wrote:
Hi Brian--

Thanks for the thoughtful followup.

You= 're welcome.
(I prefer to think first and only then stick my = foot in my mouth. ;-) )
=C2=A0

On Fri 2019-04-12 11:45:43 -0700, Brian Dickson wrote:
> Having a DISTINCT port for DoH, does not necessarily REQUIRE that it b= e the
> ONLY port for DoH.

Absolutely agreed here, though i note that this discussion is in the
context of a proposed IANA registration.

I think we can all agree here that operators are always free to run
arbitrary services on any port that they like, and what the IANA
registry is managing is conventions for use.=C2=A0 In the discussion here we're in the process of establishing norms about deployment, not strict=
requirements.

All of my considerations written earlier were intended in that context,
and were about how i think the norms we establish here will affect the
broader ecosystem.

> On Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor <dkg@fifthhorseman.net> = wrote:
>>=C2=A0 * one of the advantages of DoH is that it is indistinguishab= le from
>>=C2=A0 =C2=A0 HTTPS traffic.=C2=A0 a distinct port defeats that adv= antage.
>
> This is a bug, not a feature, from the perspective of enterprise netwo= rks
> who want to avoid having DNS traffic on 443.

I'm sorry, but it's a feature, not a bug, for users attached to (or=
routed through) networks that they neither control nor trust.

Keeping it in the enterprise lane: do you want your enterprise users to
have their connections to remote DoH servers trivially blockable by some remote network operator that is beholden to a competitor of your
enterprise?=C2=A0 I certainly don't.

Actually, I want to have my cake and eat it too.

In this case, the enterprise use case would probably best be met by:
=
- an enterprise end-point running on a non-443 port (possibly DoT, or = DISTINCT_PORT)
- which forwards queries to an external DoH provid= er (on 443)

So, the internal user would not have D= IRECT access to the external DoH server,
but WOULD have indirect = access.

The enterprise forwarder might do other th= ings (regular DNS stuff, like RPZ, malware detection),
but might = otherwise be configured/operated so as to not interfere with privacy. Havin= g such a
well-defined, standardized DISTINCT_PORT allows an enter= prise to easily set that up, without
having the problems of 443 o= utbound DNS leakage.

It's something that clear= ly needs to be figured out between all the parties involved, including
the browser software folks, and probably needs to fail safe, if the h= ost is inside an enterprise,
the user is not a privileged (admin)= user, and no new "opt-in" type extra configurations for these
new enhancements have been done (new includes vanilla DoH, IMHO).
=C2=A0

>>=C2=A0 * system administrators who enable DoH services should proba= bly prefer
>>=C2=A0 =C2=A0 to offer other HTTPS content on the same HTTPS endpoi= nt (e.g. at
>>=C2=A0 =C2=A0 least a configuration page, so that when someone poin= ts their browser
>>=C2=A0 =C2=A0 at this URL they get something human-readable).=C2=A0= It seems plausible
>>=C2=A0 =C2=A0 that this requirement means that the DoH endpoint req= uires
>>=C2=A0 =C2=A0 coordination/integration with any local https machnie= ry anyway.
>
> This is true ONLY if the end-point is a general-purpose HTTP(S) server= .
>
> I know for a fact that some resolver operators do not intend on runnin= g DNS
> resolvers on machines offering other HTTP(S) content.
> I know for a fact that some resolver operators do not want to us
> general-purpose HTTP(S) server software to implement DoH.

Those operators are encouraged to run (the equivalent of):

=C2=A0 =C2=A0 systemctl enable --now knot-resolver-doh.socket

and never have to think about it again. :)

For the rest of the operators who care what happens when a curious user
probes the actual endpoint in question, they might need to think about
it in a bit more detail.=C2=A0 And that's fine.=C2=A0 I'm trying to= preserve both
options when it comes to deployment.

> And in the possible case where, for whatever reason, the same IP addre= ss is
> hosting multiple services (DoH and HTTP(S)), it might
> not be the case that the DoH and HTTP(S) sessions are terminated on th= e
> same server (e.g. virtualized server environments,
> or servers behind load balancers sharing an external IP.)

This is a distinct case, and "behind the curtain" of an organizat= ion's
internal jurisdiction -- i think we expect folks that operate machines
in complicated networks to be proficient about fiddling with port and IP address allocation on the systems they control, so norms we establish
for the public communications network are less relevant there.

>> Note that it's also possible to run DoT on port 443 in coordin= ation with
>> an https service, if you want to avoid the ossification concerns >> mentioned above
>> (https://datatracker.ietf.= org/doc/draft-dkg-dprive-demux-dns-http/).
>> This is currently done on port 443 of dns.cmrg.net if you want to tr= y
>> it.
>
> This gets dangerously close to "bike-shed" arguments, or may= be "straw man"
> logic.
>
> Yes, it is *possible* to do <some action> <some way>.
>
> This does not mean that it is reasonable for <some way> to be ma= ndated,
> e.g. if there are important distinctions in <some environment> w= hich makes
> <other way> much better (more scalable for instance, or more sec= ure, or
> whatever), than <some way>.
>
> In this case <some way> =3D 443, <other way> =3D DISTINCT_= PORT.

heh, yes, i agree.=C2=A0 to be clear, the demux draft above is a provocatio= n,
designed to encourage network protocol designers to think about metadata leakage, channel multiplexing, ossification, privacy, and traffic
analysis.=C2=A0 It's not at all a "mandate".=C2=A0 It's a= demonstration of the
lengths that people will go to when the network ossifies around them
based on designed-in leakage.

> There are MANY more resolvers than knot, including some number of
> independent implementations (not open source). What needs to be
> achieved is interoperability, without specific dependencies on
> specific implementations, IMHO.
>
> As open a *protocol* (or standard, or whatever you want to call it) is=
> required, which should not be dependent about assumptions about the > host OS or resolver software.

Agreed.=C2=A0 That's why i think we shouldn't deviate from the stan= dard port
443.

> This basically gets to the UI issue vs the service offered issue.
>
> I don't think it is either necessary or useful for the connection = details
> to be exposed to users in this way.
>
> The UI can very easily display "example.com" and have this asso= ciated
> with whatever the DoH operator of example.com wants.=C2=A0 It is the > operator of "example.com", and not the user, who knows what the= full
> URI is (including port numbers if appropriate).

you say "very easily" and i hear "simple matter of UX design= " (by
analogy with "SMOP").=C2=A0 Perhaps you have UX design background= and
experience, but the majority of the people i meet at the IETF (including myself) definitely do not, and have given very little thought to the
difficulties of designing interoperable, meaningful, secure user
experience for the protocols that we use.=C2=A0 The example you then give describes a range of things that the protocol needs to expose to the
user without giving any clear directive how to do it.
=
I see the "under-the-hood" elements and the UX ele= ments as being
loosely related but mostly orthogonal.
<= br>
If there is a standardized "publishing" spec for ea= ch DNS provider,
perhaps as one or more RR types in DNS, in some = well-known place
(like an underscore namespace, standardized via = the IETF),
that would allow the mapping of DNS provider's bas= e name to whatever
the DNS provider wanted to offer.
The UX piece is something separate, and as long as the semanti= cs are preserved,
implementations should be free to do whatever t= hey want. At that point,
the presentation stuff is truly orthogon= al to the publishing/discovery.

Also, browser vend= ors have lots of developers, with hopefully some UX
skills and ex= perience.
=C2=A0

I just don't think it's that simple, unless we accept a configurati= on
option that is a pre-populated list with only the names of a handful of
operators; but that further entrenches the consolidation concerns i
believe we both share.

The norms we establish about DoH service discoverability and
representation (hopefully in a different thread) will have a real impact on our ability to offer users meaningful choice in their decisions about who to trust with their sensitive metadata.

> See the top of my message about why _DNS RESOLVER_ operators, rather > than generic system administrators, might prefer NOT to use 443.

By all means, they should offer their services on whatever ports they
want.=C2=A0 My dns.cmrg.net service offers DoT on several non-standard ports<= br> as well (53053 and 443 in addition to the standard 853).=C2=A0 But i wouldn= 't
want to register those with IANA.


M= aybe, but as long as someone does want to register, we should standardize o= n that,
and publish that, as an OPTIONAL port choice to use.

A given DNS resolver operator would then have lots of = good options, basically
as check-boxes: UDP/53, TCP/53, TLS/853, = HTTPS/443, HTTPS/NEWPORT, HTTPS/numeric-custom-port-number

Brian=C2=A0
--00000000000019968205865c1d2f-- From nobody Thu Apr 18 00:12:45 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0B61200B8 for ; Thu, 18 Apr 2019 00:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st 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 qm_oRlzH86aq for ; Thu, 18 Apr 2019 00:12:42 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id E68D31200E3 for ; Thu, 18 Apr 2019 00:12:41 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 75F1A3B01C; Thu, 18 Apr 2019 17:12:38 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1555571558; bh=9qyBvBDJ1P39cteJuExQW8nQuPI=; h=Comments:Received:Date:Message-ID:From:To:Subject:MIME-Version: Content-Type:Content-Disposition; b=ecnnYqWD3k8bTKvCSaFdzUSLmoxBHL6Arz+dtsttAbgrz0i0bx14gpquiQuNbmZCg rs5Ya6onQFGzDxdWSD9hNrtfbvGDk/KmVObuYhrFwP2rky5GXdL+eDdzm57F9CZ2Dp lVEgmaM8FubwWdpOsBtW6Ip0NKeeHyLxkYxmeqEU=meqEU= Comments: QMDA 0.3a Received: (qmail 68407 invoked by uid 1001); 18 Apr 2019 07:12:38 -0000 Date: 18 Apr 2019 07:12:38 +0000 Message-ID: <20190418071238.68406.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Archived-At: Subject: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 07:12:44 -0000 I'm working on a proxy/server DoH implementation designed to install on CPE and a private DoH server respectively. The development is strictly based on the RFCs without reference to any existing implementations and there are a few areas that seem ambiguous or undefined. I'm hoping to get clarity from this list. The model is: port 53 -> CPE proxy -> HTTPS -> private server -> localResolver For those familiar with CPE think of a dnsmasq replacement. The questions: ## TTL reduction due to HTTP "Age" header RFC8484 Section 5.1 advises that clients MUST account for the HTTP "Age" header by reducing TTLs. Unfortunately the RFC is silent on what to do if that reduction causes the TTL to be reduced to zero or below. Should the RR be removed which could result in an empty/odd response? Should the TTL be set to zero and let the client deal with it? This seems a risky choice as client behaviour with zero TTL is well-know to be quite unpredictable. Current behaviour is to never set the TTL lower than 1s and leave every RR in place. ## ECS Performance I've had conversations around this topic in other forums and consensus seems hard to find. Should a DoH server - when appropriately configured or signalled - add an ECS option based on the HTTPS client source IP? That seems like it would really help ECS-aware auths give much better answers than they otherwise would. Particularly as DoH servers are likely to be topologically distant from DoH clients resulting in otherwise very sub-optimal ECS answers. As best I can tell, ECS is perfectly suit to DoH but the RFC is silent on the matter. So what's the general thinking? ## ECS Privacy The converse view is that ECS is antithetical to DoH and should be avoided with extreme prejudice. If so, should a DoH implementation remove any pre-existing ECS option to protect a naive client? I know it's not particuarly likely as ECS is mostly generated by resolvers/caches rather than stubs or clients, nonetheless having a DoH implementation let a privacy-exposing option leak out seems at odds with the central tenant of DoH. ** RFC8467 DNS Padding for DoH client RFC8484 Section 9 recommends adding padding to the DNS query sent between client and server. What should a client do if the query already contains padding? Should it assume the initiator has a specific purpose in mind and not do anything or should it replace the padding to comply with RFC8484? Again unlikely, but not impossible. ** RFC8467 DNS Padding for DoH server RFC8484 is not clear about whether a DoH server should forward queries with any existing padding remaining in place or whether the padding should be removed. Arguably from a "layering" perspective if the DoH client has "pushed padding onto the stack" then the DoH server should "pop it off the stack". But the DoH server has no idea whether the padding was added by the DoH client or whether it was in the original query given to the client. The other thing to consider is that passing on padding may disclose that the query probably travelled via DoH. Is that a concern given we're trying not to disclose anything about the client? ** RFC8484 DNS Padding for GET requests My first thought is that DNS padding should apply to both GET and POST methods, but 4.1.1 says "Finally, a GET-based query ... and that padding is omitted". Is "padding omitted" referring to DNS padding or base64url padding? I presume base64url padding, but it's ambiguous. For now the implementation doesn't add DNS padding for GET requests. Should I change that? ** RFC8467 padding ambiguity with "closest multiples" and "a multiple" I've sent this to dprive but maybe it's more appropriate here. This is a truly minor nit about the precision of the text in 4.1. Nonetheless... For clients the text says pad to the "closest multiple" but for servers the text says pad to "a multiple". A literal interpretation is that servers can use a padding value which may *not* be the closest multiple, but maybe 2 or 3 or 100 multiples? My interpretation is that the intent is the same for both client and server, namely that the padding should increase the size to the next multiple up as I don't see anything else in the text that explains why larger multiples are of value. But it may be that a server is given latitude for some security or traffic analysis reason I don't understand. Is that latitude in the text on purpose and if so on what basis should a server exercise that latitude? ** A naive answer to most of these questions is that the DoH channel is merely a secure tunnel transporting a DNS blob. Leastwise I think the primordial DoH implementations worked that way. But that genie was let out of the bottle with the "Age" header modifications and DNS padding and possibly ECS. In short DoH implementations are now expected to peer into the message and mess with it. I'm new to DoH so any and all clarification and corrections appreciated. Mark. From nobody Thu Apr 18 01:03:22 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9CF1200DE for ; Thu, 18 Apr 2019 01:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 4qSR592vLAyk for ; Thu, 18 Apr 2019 01:03:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 1256F120129 for ; Thu, 18 Apr 2019 01:03:18 -0700 (PDT) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:67c:1220:80c:8010:dac7:96a7:dd53]) by mail.nic.cz (Postfix) with ESMTPSA id 563616338B for ; Thu, 18 Apr 2019 10:03:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555574594; bh=D0hZ8y7CQ5gVsqsY+50EaPnf1i7X1lAL4X2L+dSF8fI=; h=To:From:Date; b=M0G6Ojb++Vm+w5eGEKWq8led2CE6c36p+Ccet5BXLjnI9SZuOMQ2mp3/m0vHqeFUe XghOMLFpCrxGJQ2TzffM+/cD3BHatNOUzMEKTnG5hJiCyYQYSLIQ9QOuZ5aBt1pN6f qS/qK5jbXR0jGFOwBDGhj5czcFZwSVeTSRcPs0Gg= To: doh@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Openpgp: preference=signencrypt Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCBQZXRyIFNwYWNl ayA8cGV0ci5zcGFjZWtAbmljLmN6PokCVAQTAQgAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIe AQIXgBYhBL4m67nL4FmzkQyjW86N1qGlCiHkBQJcEOXhBQkFp4LgAAoJEM6N1qGlCiHkxNwQ ALFyQ7Rrghf0rM9GN2+kgP92Qvot21h8/Je3bRTvoLyhYUXcAMRmODZQ/0EsjExFc+pRwn+E 0GD2TpiorDnRMpJYEmHqenYGIrZ5TE0lHwwu0fi/X3evDY4j68OFlim5Q6+7pHOlZWaRsSm5 T6blSwIaNDFYtBhI0X1ZXTGqbXIUBFuGxolo/xEgUkeDy+6D4R8yT17CTHkuGYYrfUYnoBTr j3xMVil/lNMievaklAL8kRNVl0It4M8VzHTyEdMq7pG0CJ0CfU8COizCsu4+zy8dsxMVE0Su hju05LSsClZ9X1csxSK9HjKq+TG1Hx2qciFHRB1qC2mNIvWTm10Gkj4tLTWcJp3k2Wyv+1K2 sLFxreGOwbx0uR7XtIIBTiiZAiVsjBH0D39qG2ZLz+bJkQvlTDZQuXzsMS51wROvTVxPYcXX p069hON2+/QqJasmpOHhOydGkB3uokA0crqvMOnK+EcueKQQspvdLGiFLefJPuM8VVyR9fFZ YjnX2vfGZbE+MxY8wG4mDbhgxsUORAEtNUH/G0dvTv66fzKpl5q9GIZs7el+1IU31w7KivgS 7fsWcOsdzq4KzZzNBRJtEDoxX4b9lQ8P6ttMlPi7PnQ+iN0OUxKSnAnKQiqKMFRO1zH22vn7 iiF4JMO32//0HcpsyV8oEdjDkSJsFRnDfLW2uQINBFhri/0BEADFp4ZfxSoKTAad0IkFK9CV oZ6XKywYLFNPPhzw++gbvHL2EX7QqhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQo u0FeSNnzRGb607U8OFOPQ+ei92Mm1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkh wtWU/6yo+RZs7cFRuihuLl8FuoP0A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAw GDtjWkBVawpoHWwq58OQSx5piwyOCnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdW Jw5OV9BoA7UTHG95xVHV5QiEm6q6igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8 mmKyS8E+mSh3djmqdJNHF1pJqKxAxPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03d uzocyU95DfP/lwNJr5SH918Vf1t7WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkS eXNoMlHJOIqbqm7N414I0HytbENf7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw 3f3Gn3+PDzGEHI9sfQv/mYvO77oRSGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6If ZZ0OIWKLSRa/DQARAQABiQI8BBgBCAAmAhsMFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ 5fcFCQWngvoACgkQzo3WoaUKIeTg+w/9Gyp5EcB4AoR3vKVxP0SAh1zBher3bh9uGaKTAWt0 +0v8fyZYGEPqZr//9rkodPnXbQnr9ogzjJmZpsPvGPyRZikWjYIwkfM2Vb4BCyr5wQ9++9KB kob5zCQmUw2o7s/gISpFsCC5B0eYusArVDnrCyrroyaxbN6MpUb5lzVMEOCzYljtdrPRAXPL FKRm3ijLV0RcYPzJJVOPV5EzUfCtGsGTXXRI9Y9O/7lFaJ+iWnwygo/Xoi0IgBHvOAj9Gp3Q 0BY+sI6Rgzm9dbddm8gYJ4+FjfZivI7fbdfSubTWvrtFmFdHovIPJYLvXK7hUG22ww4CneIF D4oZSVy9xUoqJf0qQNruzEqTr7y7lbZIzxgPCSVmH0jpgJ1po6RLaJllNA+ZklOQ76fCMiaD 5yQuJluwD5w+acPWTbmZX6DijGHPZSjzeUkiMKctYSRqVUo6JmK0dgwwm3l1/Orb4D3YsLVP QDa4ZrCfSldrGC3zkEJ8iCVSYQwlc0JfIxyn8C3LLxToPYeFv/bQTeDYBjaV7a0SQ/xKUdpg RFzrGrxj7CM2WHcpxCLVK0agobuUO7YXoufHRM6y0rfMwT10baDjh+hLKMshxTqsP55lWvtM SleSGjheVTiZChb3jK0rUPCC4Rg3gDTEQsptC3TgN48PtLpmhsNc4JPm64zlrreInZQ= Organization: CZ.NIC Message-ID: Date: Thu, 18 Apr 2019 10:03:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: cs Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] Mozilla's plans re: DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 08:03:21 -0000 On 01. 04. 19 22:45, Eric Rescorla wrote: > > > On Mon, Apr 1, 2019 at 1:32 PM Brian Dickson > > > wrote: > > > > On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla > wrote: > > I’ve heard a number of questions about Mozilla’s plans around > DoH. We’ve made a number of public statements, but it might be > useful > to try to put this all in one place. > > In context, the problem we are attempting to solve here is attack on > the user’s name resolution from an attacker with full or partial > control of the network, as contemplated by Section 3 of BCP 72 > as well > as BCP 188. There’s ample evidence of monitoring/manipulation of > user > traffic via this vector [0][1][2]. > > > [1] > https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pearce.pdf > > > Looking specifically at the problem statement and evidence, I have a > question about this (or any other) investigative work: > Has there been any related/follow-up work, or other similarly scoped > work, to examine the use of DNSSEC in the domains tested, that > you're aware of or can point folks at? > > > I.e. Were any of the manipulated domains signed DNSSEC domains, > where validation might have prevented the manipulated responses from > being accepted from the resolver? > > Clearly there would still be the issue of being able to find/reach a > resolver that does not manipulate results, but at least the > manipulation would be detected/blocked. > > > I don't have much more information than is in the paper (you'll note I'm > not an author), but generally DNSSEC doesn't help that much here. You > can't safely do DNSSEC validation on user-facing clients because of a > combination of tampering by middleboxes (typically record stripping, > etc,. not really "attacks") and errors in the published DNSSEC records. Tampering by middleboxes is solved by DoH, isn't it? Statement "can't safely do DNSSEC validation on user-facing clients because of ... errors in the published DNSSEC records" requires some evidence to show it is still valid in 2019. According to APNIC's data [1] ~ 17 % of web population is behind DNSSEC validating resolver today, so anyone who screws up DNSSEC will notice and fix it quite quickly. Second data point is that we (as CZ.NIC company) provide support to telcos operating DNSSEC-validating resolvers, and do not see any significant breakage caused by misconfigured DNSSEC. To give some weight to this statenemt please note that CZ has ~ 65 % users behind validating resolvers, CZ.NIC doing support also for local telcos, and we simply do not see the rummored breakage caused by DNSSEC misconfiguration. [1] https://stats.labs.apnic.net/dnssec -- Petr Špaček @ CZ.NIC From nobody Thu Apr 18 05:20:41 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57234120300 for ; Thu, 18 Apr 2019 05:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 TNWuvc3o7_ZI for ; Thu, 18 Apr 2019 05:20:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 B7F6C1202FF for ; Thu, 18 Apr 2019 05:20:37 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:2] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:2]) by mail.nic.cz (Postfix) with ESMTPSA id 8E25E60710; Thu, 18 Apr 2019 14:20:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555590033; bh=w8idke3tvdI2goasA5O6GKI3t7y9DiswlU/NwIiaruw=; h=To:From:Date; b=kVAMdrGeUCwkM9v5ltZQPZI/lls3EMxEcvsB1+zt38ED3fL0jf0aZdFptWXSowpAC nPV0SsJ55OyUBISMQl1In35iLbTuTkmvyrjRu+jwpRwTktYC5dF8mjp5Qcq5eJEeHh LdEWft3n8gmjQqJfYWTVCJzRbsBtXm0JOkS60Bfw= To: Mark Delany References: <20190418071238.68406.qmail@f3-external.bushwire.net> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Cc: doh@ietf.org Openpgp: preference=signencrypt Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtDBWbGFkaW3DrXIg xIx1bsOhdCAod29yaykgPHZsYWRpbWlyLmN1bmF0QG5pYy5jej6JAlQEEwEIAD4CGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w 3gAKCRDnR98flXWjqmD6D/96U4cDZBrHQ5LhqybocZr/N2IS5Wr2SLLB4k2F5/W/wbL05gq6 Ha9/2TMqXoxRkhug+EAHFHxylPR43yN9rz0pjBXHrra87FAPHMqq/qqrOEUdhkytEqa6WIho aoEkdhaMhUyctjVjL2WZ0+MWeRjqedLQX+VCrOVPcVbLreRRhA9N3KPgNwbp9zCg6hEPi4l2 zZKedHkTNjKIAwJ0xZoMwFa1Y+vL8Em8Or+IBZuGBMP/ZMtasPOIQaT/Gvsyx1DDorwsoCdX 6zaTZy5DOWP3FIrMzus/YDbzwAYxSpWk/jF44ySbnJzdjU67EfG3UrsK+RRGw8aJqs3/4qHK ZMZZnNL+4wJpEdnZyFic/MXcw6FBszQEwrIOaM1WEfwzn2ExUYk2pM5zaBwq76OgrmGMzMEi cfMDyqLodwEQqR70PvRbkrh+R02LphwQ9c5AFXcrLjKMmeQlbQVarTUsrELcTK6rElC1ojS7 M37j0XzFE+kgNWn2fyBRgtnGDWEa7r+oDaueXJnEf0/4Ww28IwxakNc7r0N41GIBekwSxKdk epKFZgtVGGSDlFei5hb5LLWFljA1OS7CRVJKpbHafQjdPdb1vNqZAj4y2SJXvVVpI1KO5kq+ dFdYipORv0N2Iho6MNYbQUT1EBeU46G5N0viCoLS15/PxLhIAo+PzKpW97kCDQRYA5J2ARAA yHww3huLEtsdyqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zx x85WcuaO1OVqung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPp DkGodS0De9osA+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOo jGMiLoZvELY86Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxM t5LB/MSrmECB5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoR bh7i4fT0lWvMXTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJ V7xVLTtS1EamVqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p 02oSecDl5yVXplJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGX M71OpmONQJGF24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0 Q2zochS64Mcg0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYB gAAKCRDnR98flXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw 9SLUt7OGuUnIpKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrie b6iPjvAARXJCPTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTj xZzmGgvNSi6JDlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJi ba7iFPcGwcClCSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhw QYXm4/pDmNT8UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvL woHib0jEvohPMJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTN r+qHh+7Ltrkbu/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2Kg T1AcZ51E+xG+cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGo UREr0rkMnFVsWeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <0e241cc8-dd4c-f93d-92b6-83dd62791bc4@nic.cz> Date: Thu, 18 Apr 2019 14:20:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <20190418071238.68406.qmail@f3-external.bushwire.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:20:40 -0000 Hello! Reactions to particular parts inline.  I omitted those where I can't say too much. On 4/18/19 9:12 AM, Mark Delany wrote: > [...] > ## TTL reduction due to HTTP "Age" header > > RFC8484 Section 5.1 advises that clients MUST account for the HTTP "Age" > header by reducing TTLs. Unfortunately the RFC is silent on what to do if > that reduction causes the TTL to be reduced to zero or below. Should the RR > be removed which could result in an empty/odd response? Should the TTL be set > to zero and let the client deal with it? This seems a risky choice as client > behaviour with zero TTL is well-know to be quite unpredictable. > > Current behaviour is to never set the TTL lower than 1s and leave > every RR in place. I believe the HTTP "Age" makes sense as the minimum of all TTLs in the packet, or optionally smaller but never larger.  Therefore it should not happen, but in case it does, I can't think of anything better than resetting the underflowed TTLs to 1s. The RFC only bounds to minimum TTL *in answer section*, but I believe that's a mistake as you can't just ignore authority section at least.  There may be records vital for DNSSEC validation of negative answers, for example. > ## ECS Performance, Privacy, etc. I can't see how using a different transport makes ECS issues different.  If you use UDP forwarding to some public resolver, you are in pretty same situation, except that you're more likely to be intercepted, etc. > ** RFC8467 DNS Padding for DoH client I'm not so sure about this, but my point of view is, shortly, that padding is a per-hop thing.  It depends on the particular transport - for unencrypted ones it doesn't even make any sense, so I can't see why padding should matter between your proxy and its clients.  I believe this point of view is consistent with the RFC, too. > ** RFC8484 DNS Padding for GET requests > > My first thought is that DNS padding should apply to both GET and POST > methods, but 4.1.1 says "Finally, a GET-based query ... and that padding is > omitted". Is "padding omitted" referring to DNS padding or base64url padding? > I presume base64url padding, but it's ambiguous. > > For now the implementation doesn't add DNS padding for GET requests. Should I > change that? That's certainly about base64url padding.  It could get clarified in the RFC, but I suspect most people don't get to reading errata or "corrected" RFC versions. --Vladimir (Knot Resolver) From nobody Thu Apr 18 11:13:28 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62AF120370 for ; Thu, 18 Apr 2019 11:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 yUGdMGkCTIm1 for ; Thu, 18 Apr 2019 11:13:24 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 80161120144 for ; Thu, 18 Apr 2019 11:13:23 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id h21so2670865ljk.13 for ; Thu, 18 Apr 2019 11:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pfYONb3QVcUO3SFPgxTQYVTfEh3Dk69sw7d90ImsfNc=; b=EgfKXvncDNUwzC1LG5kJkYxlg8WBH5sA/+eN7yK8UtT7ztK6letswNrMJfn4s+e2Iz t/e7lKWMXajoPBJgsI4DzCqLWU7CXx6I22wkxY9F6mRlhfLiQtNezbpSImisr+7ka1b5 XPihdGOYeLERsusyi7k1CZWQKG9+TMCSIpWWhkVEpdC+skbqeCHFNFRCwDSQZyHk206d VR0Ug7E4ZckHXiR08dqeIoL4y0HqOZM5Hmhyh/kXBCZnUblj1VU4+p8PrfL4xVdPxR7F v2uHZqk21uSwWy3LbloHOIh1JbprrHHNY5GT5Vo0e7sj49AFs2OhXN+z+tEdC6axKbGZ eyRw== 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=pfYONb3QVcUO3SFPgxTQYVTfEh3Dk69sw7d90ImsfNc=; b=FuTz1V4i3JghRb7QUA0rNJf611A4nt7R7YH+z7Iwvk67uCOihO/QvkD046q8LCAWML eL+CAtjU1QkGKqCUHvrkRpKseup9c1XdcQ6cmrn4QhdZ1MKQpTRUyTwOkVa6jOJu6ZBs yH+x9eIX2ou3dxM5D79l9dn1YcyNTCw85Gbgnuzoedqopo8HxGNKxdG1wG92ATTfOldB c1LiNtXqAtlfL7dzR9zRtfcj0S8TCOcDXUJPUod2UfKH1DNpXf7hUcJprgxVUqWoSyD+ OXLRyyjSegfexbm03kyevvI3KfqnTNqKODrVNQjShH/HDVTXmx3z/sM91oX9af6IUY+K Zuxw== X-Gm-Message-State: APjAAAVcedjjaI+9qix/SvYFVSC45/EXcZbO05UTxsetE6BnR+ZdfJ0P IfMUJyPG5wHHd+yIKK1UQnBq4s1gLS7SWc36tWR887VUkak= X-Google-Smtp-Source: APXvYqxDDBcUTch5/qs7EOfLJrqrpPvW73Vmozv/Ke8SOs6+L1oy1VXWzC4uEMYNiWX2bGFQoNtX55xMdzkqPCYJuLo= X-Received: by 2002:a2e:8050:: with SMTP id p16mr4919711ljg.160.1555611201421; Thu, 18 Apr 2019 11:13:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 18 Apr 2019 11:12:42 -0700 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000011e0d30586d1f5d0" Archived-At: Subject: Re: [Doh] Mozilla's plans re: DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 18:13:27 -0000 --00000000000011e0d30586d1f5d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 18, 2019 at 1:03 AM Petr =C5=A0pa=C4=8Dek = wrote: > > > On 01. 04. 19 22:45, Eric Rescorla wrote: > > > > > > On Mon, Apr 1, 2019 at 1:32 PM Brian Dickson > > > > > wrote: > > > > > > > > On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla > > wrote: > > > > I=E2=80=99ve heard a number of questions about Mozilla=E2=80=99= s plans around > > DoH. We=E2=80=99ve made a number of public statements, but it m= ight be > > useful > > to try to put this all in one place. > > > > In context, the problem we are attempting to solve here is > attack on > > the user=E2=80=99s name resolution from an attacker with full o= r partial > > control of the network, as contemplated by Section 3 of BCP 72 > > as well > > as BCP 188. There=E2=80=99s ample evidence of monitoring/manipu= lation of > > user > > traffic via this vector [0][1][2]. > > > > > > [1] > > > https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pea= rce.pdf > > > > > > Looking specifically at the problem statement and evidence, I have = a > > question about this (or any other) investigative work: > > Has there been any related/follow-up work, or other similarly scope= d > > work, to examine the use of DNSSEC in the domains tested, that > > you're aware of or can point folks at? > > > > > > I.e. Were any of the manipulated domains signed DNSSEC domains, > > where validation might have prevented the manipulated responses fro= m > > being accepted from the resolver? > > > > Clearly there would still be the issue of being able to find/reach = a > > resolver that does not manipulate results, but at least the > > manipulation would be detected/blocked. > > > > > > I don't have much more information than is in the paper (you'll note I'= m > > not an author), but generally DNSSEC doesn't help that much here. You > > can't safely do DNSSEC validation on user-facing clients because of a > > combination of tampering by middleboxes (typically record stripping, > > etc,. not really "attacks") and errors in the published DNSSEC records. > > Tampering by middleboxes is solved by DoH, isn't it? > Yes, probably, but given that the context in which I introduced this point was about the need for DoH, I'm not sure that that is relevant. > Statement "can't safely do DNSSEC validation on user-facing clients > because of ... errors in the published DNSSEC records" requires some > evidence to show it is still valid in 2019. > Well, I'm not sure why the situation would have changed, but I'd certainly welcome any data you have to show that client-side DNSSEC validation is safe. > According to APNIC's data [1] ~ 17 % of web population is behind DNSSEC > validating resolver today, so anyone who screws up DNSSEC will notice > and fix it quite quickly. > No, unfortunately not. The question here is about validation in the client, and so validating ISP resolvers don't address the problem. > Second data point is that we (as CZ.NIC company) provide support to > telcos operating DNSSEC-validating resolvers, and do not see any > significant breakage caused by misconfigured DNSSEC. To give some weight > to this statenemt please note that CZ has ~ 65 % users behind validating > resolvers, CZ.NIC doing support also for local telcos, and we simply do > not see the rummored breakage caused by DNSSEC misconfiguration. > I'm not primarily talking about misconfiguration (though I've seen data reflecting that as well [0]) but about damage due to middleboxes. -Ekr [0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf > > [1] https://stats.labs.apnic.net/dnssec > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000011e0d30586d1f5d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 18, 2019 at 1:03 AM Petr = =C5=A0pa=C4=8Dek <petr.spacek@nic.= cz> wrote:
brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com>= >
> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com
>=C2=A0 =C2=A0 =C2=A0<mailto:ekr@rtfm.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I=E2=80=99ve heard a number of questi= ons about Mozilla=E2=80=99s plans around
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DoH. We=E2=80=99ve made a number of p= ublic statements, but it might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0useful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to try to put this all in one place.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In context, the problem we are attemp= ting to solve here is attack on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the user=E2=80=99s name resolution fr= om an attacker with full or partial
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0control of the network, as contemplat= ed by Section 3 of BCP 72
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as well
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as BCP 188. There=E2=80=99s ample evi= dence of monitoring/manipulation of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0user
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0traffic via this vector [0][1][2]. >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.usenix.org/system/files/conference/usenixsecu= rity17/sec17-pearce.pdf
>
>
>=C2=A0 =C2=A0 =C2=A0Looking specifically at the problem statement and e= vidence, I have a
>=C2=A0 =C2=A0 =C2=A0question about this (or any other) investigative wo= rk:
>=C2=A0 =C2=A0 =C2=A0Has there been any related/follow-up work, or other= similarly scoped
>=C2=A0 =C2=A0 =C2=A0work, to examine the use of DNSSEC in the domains t= ested, that
>=C2=A0 =C2=A0 =C2=A0you're aware of or can point folks at?
>
>
>=C2=A0 =C2=A0 =C2=A0I.e. Were any of the manipulated domains signed DNS= SEC domains,
>=C2=A0 =C2=A0 =C2=A0where validation might have prevented the manipulat= ed responses from
>=C2=A0 =C2=A0 =C2=A0being accepted from the resolver?
>
>=C2=A0 =C2=A0 =C2=A0Clearly there would still be the issue of being abl= e to find/reach a
>=C2=A0 =C2=A0 =C2=A0resolver that does not manipulate results, but at l= east the
>=C2=A0 =C2=A0 =C2=A0manipulation would be detected/blocked.
>
>
> I don't have much more information than is in the paper (you'l= l note I'm
> not an author), but generally DNSSEC doesn't help that much here. = You
> can't safely do DNSSEC validation on user-facing clients because o= f a
> combination of tampering by middleboxes (typically record stripping, > etc,. not really "attacks") and errors in the published DNSS= EC records.

Tampering by middleboxes is solved by DoH, isn't it?

Yes, probably, but given that the context in which I intr= oduced this point was about the
need for DoH, I'm not sure th= at that is relevant.


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Statement "can't safely do DNSSEC validation on user-facing client= s
because of ... errors in the published DNSSEC records" requires some evidence to show it is still valid in 2019.

=
Well, I'm not sure why the situation would have changed, but I'= ;d certainly
welcome any data you have to show that client-side D= NSSEC validation
is safe.


According to APNIC's data [1] ~ 17 % of web population is behind DNSSEC=
validating resolver today, so anyone who screws up DNSSEC will notice
and fix it quite quickly.

No, unfortuna= tely not. The question here is about validation in the client, and
so validating ISP resolvers don't address the problem.

=

=C2=A0
Second data point is that we (as CZ.NIC company) provide support to
telcos operating DNSSEC-validating resolvers, and do not see any
significant breakage caused by misconfigured DNSSEC. To give some weight to this statenemt please note that CZ has ~ 65 % users behind validating resolvers, CZ.NIC doing support also for local telcos, and we simply do
not see the rummored breakage caused by DNSSEC misconfiguration.

I'm not primarily talking about misconfigurat= ion (though I've seen data reflecting
that as well [0]) but a= bout damage due to middleboxes.

-Ekr

[1] https://stats.labs.apnic.net/dnssec

--
Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--00000000000011e0d30586d1f5d0-- From nobody Thu Apr 18 17:25:36 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4211200CD for ; Thu, 18 Apr 2019 17:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st 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 arXFa5bbqOTx for ; Thu, 18 Apr 2019 17:25:33 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8624512004C for ; Thu, 18 Apr 2019 17:25:33 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 20F983B01C; Fri, 19 Apr 2019 10:25:30 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1555633530; bh=XwNByD05N2rhkVfRsxLs3Nk1BIU=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=U0TENPxERP0hf0zuzUH3KMPcJZ0eh5HTkePSyt1nJoml7Gx9hCGtAMwcbATaNRBjS qIzGNHizN5UdtT3G79XuMsRl51UaaDsGxy80biUxdaPvNXz8lf4WPS5F/Y2J+awU3u iPDnuqBsyBpEuVQcuF7jupJ5uaobwUqSqnHep+KQ=ep+KQ= Comments: QMDA 0.3a Received: (qmail 72953 invoked by uid 1001); 19 Apr 2019 00:25:30 -0000 Date: 19 Apr 2019 00:25:30 +0000 Message-ID: <20190419002530.72952.qmail@f3-external.bushwire.net> From: "Mark Delany" To: doh@ietf.org References: <20190418071238.68406.qmail@f3-external.bushwire.net> <0e241cc8-dd4c-f93d-92b6-83dd62791bc4@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0e241cc8-dd4c-f93d-92b6-83dd62791bc4@nic.cz> Archived-At: Subject: Re: [Doh] Clarification for a newbie DoH implementor X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 00:25:35 -0000 On 18Apr19, Vladim??r ??un??t allegedly wrote: > Hello! > Reactions to particular parts inline.?? I omitted those where I can't say > too much. Thanks. > The RFC only bounds to minimum TTL *in answer section*, but I believe > that's a mistake as you can't just ignore authority section at least.?? I agree, particularly as an "Age" response might come from a caching HTTP server which is oblivious to the payload. Since "Age" is saying the whole payload has aged thus it should logically apply to all TTLs inside. > I'm not so sure about this, but my point of view is, shortly, that > padding is a per-hop thing.?? It depends on the particular transport Yeah. I guess the thing is that a DNS message didn't typically traverse multiple hops until DoH came along so the question never arose. As you well know, most often a message triggers new messages rather than being forwarding directly. But I agree that padding seems like a per-hop/per-transport value. As it turns out I don't think a DoH proxy has to care about pre-existing padding as it should be able to arbitrarily add a second padding to the message to meet the modulo size requirements. Is there anything that says two paddings options in one message are illegal? It might be more efficient to replace the existing padding, but RFC7830 is silent on the matter of multiple occurrences. (It's also interesting that padding has been placed inside the DNS message as opposed to something appended to the HTTP payload. Both work just as well to mitigate the traffic analysis risk. However this in-message approach forces a proxy implementation to disassemble and reassemble the message and thus have a fairly full understanding of the DNS message structure rather than just append a blob of zeros to a blob of HTTP payload. That's a lot of extra complexity to add a few zero bytes. Oh well, that ship has well and truly sailed!) > > For now the implementation doesn't add DNS padding for GET requests. Should I > > change that? > > That's certainly about base64url padding.?? It could get clarified in the > RFC, but I suspect most people don't get to reading errata or > "corrected" RFC versions. Or the original RFCs for that matter :-) In retrospect I think GET should have padding as it mitigates the same risks as POST but it also might reduce cacheability if some proxys pad and others don't... And the RFC authors did worried a bit about HTTP cacheability as witness by the zero ID for GET rule. All in all tho, since GET is discouraged it's unlikely to be a big deal. Thanks again for your responses. Mark. From nobody Tue Apr 23 11:23:18 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72A012047B for ; Tue, 23 Apr 2019 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 NPSbEomWaLcR for ; Tue, 23 Apr 2019 11:23:14 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 BF6AF120472 for ; Tue, 23 Apr 2019 11:23:13 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3B14A280703 for ; Tue, 23 Apr 2019 20:23:11 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 3414128070C; Tue, 23 Apr 2019 20:23:11 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 2AFEF280703 for ; Tue, 23 Apr 2019 20:23:11 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 26169642A7A1 for ; Tue, 23 Apr 2019 20:23:11 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 1D63F4665F; Tue, 23 Apr 2019 20:23:11 +0200 (CEST) Date: Tue, 23 Apr 2019 20:23:11 +0200 From: Stephane Bortzmeyer To: doh@ietf.org Message-ID: <20190423182311.v7iiniyo6pjj2uyt@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="hryqiudyquchzqef" Content-Disposition: inline X-Operating-System: Debian GNU/Linux 9.8 X-Kernel: Linux 4.9.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.4.23.180916 Archived-At: Subject: [Doh] [ietf-secretariat@ietf.org: New Non-WG Mailing List: masque] X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 18:23:17 -0000 --hryqiudyquchzqef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Interesting list. The deployment model envisaged at the end is exactly what would be good for DoH. --hryqiudyquchzqef Content-Type: message/rfc822 Content-Disposition: inline Return-Path: ietf-announce-bounces@ietf.org Received: from hebe.prod-int.prive.th3.nic.fr [10.1.81.80] by b12.tech.prive.nic.fr with IMAP (fetchmail-6.3.26) for (single-drop); Mon, 22 Apr 2019 16:31:32 +0200 (CEST) Received: from hebe.prod-int.prive.th3.nic.fr (LHLO zimbra.afnic.fr) (10.1.81.80) by zimbra.afnic.fr with LMTP; Mon, 22 Apr 2019 16:30:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id E40092D7C999 for ; Mon, 22 Apr 2019 16:30:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.afnic.fr X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-10 required=6.6 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=no autolearn_force=no Authentication-Results: zimbra.afnic.fr (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org header.b=fTiB7fat; dkim=pass (1024-bit key) header.d=ietf.org header.b=bs85i0/x Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUO-2By8dCPi for ; Mon, 22 Apr 2019 16:30:08 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [10.1.50.11]) by zimbra.afnic.fr (Postfix) with ESMTP id 2E81C2D7C9A3 for ; Mon, 22 Apr 2019 16:30:04 +0200 (CEST) Received: by relay01.prive.nic.fr (Postfix) id 00C2F642C581; Mon, 22 Apr 2019 16:30:04 +0200 (CEST) Delivered-To: bortzmeyer@nic.fr Received: from mx5.nic.fr (mx5.nic.fr [IPv6:2001:67c:2218:2::4:13]) by relay01.prive.nic.fr (Postfix) with ESMTP id E8131642C592; Mon, 22 Apr 2019 16:30:03 +0200 (CEST) Received: from mx5.nic.fr (localhost [127.0.0.1]) by mx5.nic.fr (Postfix) with SMTP id E14FA3000B9; Mon, 22 Apr 2019 16:30:03 +0200 (CEST) Received: by mx5.nic.fr (Postfix, from userid 1137) id A34D73002C3; Mon, 22 Apr 2019 16:30:03 +0200 (CEST) Received-SPF: pass (ietf.org: 4.31.198.44 is authorized to use 'ietf-announce-bounces@ietf.org' in 'mfrom' identity (mechanism 'ip4:4.31.198.32/27' matched)) receiver=mx5.nic.fr; identity=mailfrom; envelope-from="ietf-announce-bounces@ietf.org"; helo=mail.ietf.org; client-ip=4.31.198.44 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx5.nic.fr (Postfix) with ESMTPS id 6F90E3000B9; Mon, 22 Apr 2019 16:30:03 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0C2120340; Mon, 22 Apr 2019 07:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1555943402; bh=B9FxNawieSefRHVnL/71Z1t5PbRNoJJWq+n2n8DOYq4=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=fTiB7fatkmw+RJ8rAwzpfpijoyFXRtqDhdjB2zdcmL8alrNvMPu6yvQaf7mWTLV6g YFuR9fnx7nmMn+wUY8AOhLlztaitOZRc5fV3pcJnAEZlvHL2csnMmwjGjEWYd1m008 EpeGycej2w0HinCOUeysd/e8DeirIgY5kcJrQ3lw= X-Mailbox-Line: From ietf-announce-bounces@ietf.org Mon Apr 22 07:29:54 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB39E12025C; Mon, 22 Apr 2019 07:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1555943336; bh=B9FxNawieSefRHVnL/71Z1t5PbRNoJJWq+n2n8DOYq4=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=bs85i0/xu1Oner+l6hPf0Cfgz72f1FJPVNT3LBRpbAck0q12LrzyBh/+qw28xI1uU /IgxogShnXZzCw3sXo1Qu/Fnfwke2sPwa8aIwv63qnDN6VDtqouP4n/6kv/ewHax1o Ez8/yUJXefd6c1JralT/S3JJzmHdcqAiNDcMzZHI= X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1033F12001B; Mon, 22 Apr 2019 07:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Old-From: IETF Secretariat To: "IETF Announcement List" Old-Subject: New Non-WG Mailing List: masque X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155594332902.21194.12701430310750645026.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2019 07:28:49 -0700 Archived-At: X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ietf@ietf.org Errors-To: ietf-announce-bounces@ietf.org Sender: "IETF-Announce" X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.4.22.142116 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' REPLYTO_FROM_DIFF_ADDY 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_1099 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DKIM_ALIGNS 0, DKIM_SIGNATURE 0, FROM_SAME_AS_TO_DOMAIN 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __DKIM_ALIGNS_1 0, __DKIM_ALIGNS_2 0, __FRAUD_CONTACT_ADDY 0, __FROM_DOMAIN_IN_ANY_TO1 0, __FROM_DOMAIN_IN_RCPT 0, __HAS_FROM 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_ID 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __HAS_REPLYTO 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __PHISH_PHRASE2 0, __PHISH_SPEAR_SUBJ_SUBJECT 0, __REPLYTO_SAMEAS_FROM_DOMAIN 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_WITH_PATH 0' X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Subject: New Non-WG Mailing List: masque From: IETF Secretariat A new IETF non-working group email list has been created. List address: masque@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/masque/ To subscribe: https://www.ietf.org/mailman/listinfo/masque Purpose: MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a mechanism that allows co-locating and obfuscating networking applications behind an HTTPS web server. The currently prevalent use-case is to allow running a VPN server that is indistinguishable from an HTTPS server to any unauthenticated observer. We do not expect major providers and CDNs to deploy this behind their main TLS certificate, as they are not willing to take the risk of getting blocked (given previous experiences when domain fronting was blocked). An expected use would be for individuals to enable this behind their personal websites via easy-to-configure open-source software. This list belong IETF area: SEC For additional information, please contact the list administrators. --hryqiudyquchzqef-- From nobody Wed Apr 24 07:49:22 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ABE12034D for ; Wed, 24 Apr 2019 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.336 X-Spam-Level: * X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gWkvPGjGTHyg for ; Wed, 24 Apr 2019 07:49:11 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 D26DD120364 for ; Wed, 24 Apr 2019 07:49:10 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id o25so4978525wmf.5 for ; Wed, 24 Apr 2019 07:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=sL2y5/r6CB6G2BaXfWvvVHxCL08cCbW9UgJg4BmHjvs=; b=Ajs4O7UTw3YhO1yhJ9lHgCc9iuTKPuMW57t/doMg0Jy4Q5WzvnJPH0mcOkZQ8NvGhR 1mCjktJ5XX+WXe77Y8jRz7imL8PG/g9o3KcjwGP2pQlc1DK8YPw2IP3RxZc1m2hLIv1D BiESz3el6k1rFaIu5KVX6IGfiqsz5UM34eYXMb4EJcK1KQhEwHMubNpYztL+goGz3sIh T5jjOws7lPRVxrljrHwSq4lwKDxJ6zvvYzgb0prwbg+A9+X/Ay1G4eFvPnCMCsgzpSyi BEQxyv7XWVQFVB5LrouW7ISoFKVmayOBGNBCb4KstBR3X3AR9buDTwy5NOTmRNTFLUXx Xl1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=sL2y5/r6CB6G2BaXfWvvVHxCL08cCbW9UgJg4BmHjvs=; b=NpoAHcIfb0XCCOxrdwWtW5o9HXW+sseS4tHadY5/aD5E0eCwU3eis1CRvfggdCbcWv s9mNh4d7h3gceDPBmclZmcCb5I44gj0Hyq6bjTh02MQ1mlq55UfCGbWuagOtXA6635x+ iVAFzrh8nd36CwHSmIPzJaJumbrwzM4BKjulYLYylMbPSfjnmra9/jYgBOgfO2ZGkcpL Ls8kFuKFQ0MH992AKEwx2L7zGGiA+I8ruKP0lmZibjEMfJ8x7jq6kkah3a5BfA2RKYaQ zNQH0lpEjJbGOG41gdQOodPuC1D4t/kkPFuYqPhyGRkaTwet9ic2uBSE3rfdbdUQ9HWC hIQA== X-Gm-Message-State: APjAAAWy/Ar45nXH42e3LxU7pMbq5JRWwpOFJYod+UG3baVtCzgIgH36 rPCrJDCCvCS533UnS5FaKM1+h0dx X-Google-Smtp-Source: APXvYqzuOys4+67+Te8kS9SiDDxTy1/2Tomp0wGz3un7AK/5f0biArX3GUfuuNpuPhG2h+I2H+GlOg== X-Received: by 2002:a05:600c:2198:: with SMTP id e24mr3999105wme.16.1556117349176; Wed, 24 Apr 2019 07:49:09 -0700 (PDT) Received: from ROADKILL.local ([132.185.158.37]) by smtp.gmail.com with ESMTPSA id u6sm35429199wrg.72.2019.04.24.07.49.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 07:49:07 -0700 (PDT) To: doh@ietf.org References: <155341529409.18062.10657099011172813446@ietfa.amsl.com> <20190325110136.GA23793@laperouse.bortzmeyer.org> <08BD5718-CD1F-47B3-A4FB-4040F8E9FC4B@icann.org> <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> Cc: Martin Thomson From: Thomas Peterson Message-ID: <5ea4221f-3e16-906d-a41d-2914b3803bca@gmail.com> Date: Wed, 24 Apr 2019 15:49:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6121981d-9827-483d-92db-14bd8e39c05e@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Doh] Authentication in draft-ietf-doh-resolver-associated-doh-03.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 14:49:21 -0000 I agree with Martin on the points around discovery, and as such have started an initial draft[0] describing DoH DHCP and RA extensions. Feedback from the list would be appreciated, and should there be further consensus for this I will also author an additional draft for DoT and begin the necessary requests to IANA for assignments. Regards 0: https://thpts.github.io/draft-peterson-doh-dhcp/draft-peterson-doh-dhcp.html On 30/03/2019 12:48, Martin Thomson wrote: > On Mon, Mar 25, 2019, at 12:37, Paul Hoffman wrote: >> The reason I didn't drop down to http: is that doing so evokes the >> response, even though you are quite correct that the other two >> methods given in this document do not offer any authentication. > There is a different reason that I think is stronger. We tolerate an exposure on DHCP and other network-layer configuration options (like the v6 RA). The security implications of those mechanisms are well understood and it is common for networks to deploy systems that limit the opportunity for attacks. Things like filtering broadcast and RA from end hosts are common. > > But the connection to a resolver might be harder to secure in this fashion. Though it might be possible to narrow the use of unicast port 53 (or 853), such filtering is different. It is not always the case that the resolver is local in the same way that a DHCP server/relay or gateway is. For DoH, which might use a service that is completely external to the network, this is more difficult. > > Therefore, it is easier to look at this step of the configuration process as being subject to "untrusted" activity and insist on authentication. It's certainly true that the only basis for authentication is the assertion by the network discovery phase, for which you have no prior expectations. However, the property we are looking for is that we are talking to the same server that the network intended for us to talk to. Thus, if the name of the server comes from the same mechanism that gave us an IP address (DHCP), or the system that provides connectivity (RA), then we at least have that much. > > If your goal is to talk to the resolver provided by the network, then I believe that to be sufficient. > > Hence I would propose a different design for this, bringing DoT into the design. > > 1. The first step requires no new protocol mechanisms. To discover DoT, connect to the resolver IP at port 853. If the server produces a certificate that is valid for the IP address of the resolver, then you are good to proceed. No new mechanism is required. (Clients may decide to accept any certificate here if they require opportunistic security, but I would suggest that this is unwise for the aforementioned reasons. That said, it's better than using Do53, so I'd say it's still worth doing except for the fact that this establishes an expectation on the part of DoT resolvers that having a valid certificate is not required, which is dangerous.) > > 2. We add a field to DHCP and RA that carries the "DoT resolver". When this is present, the client resolves this name using the resolver. This resolution is unsecured. The client then connects to the resulting IP address and validates the certificate it presents using this name. This enables easier deployment of DoT because a certificate for a name is easier to get than an IP certificate (it also enables use of 1918 address and the like). > > 3. We add another field to DHCP and RA that carries the "DoH resolver". When this is present, the client resolves the associated name using the unsecured resolver. The client then connects to this endpoint, validates the certificate and proceeds to use DoH. > > We could decide not to do the DoT step, but I wanted to include it to illustrate the symmetry of the design. > > You will observe that this is significantly simpler than the proposed design. There are several drawbacks, that I will address: > > A. A client in a residential network will not receive this option unless their gateway/relay is configured to relay these values from external network. The design proposed in the current draft has this property in that the SUDN is forwarded by resolvers that don't understand its purpose. In this case, endpoints will talk to the DNS proxy in their gateway and not be able to discover a DoH service provided by an ISP. RFC 5625 points out that it is not generally possible to talk to the external resolver. > > B. This doesn't provide any option for web clients to find the local resolver. I will separately argue that this is not a valid use case, and moreover that it is one that presents some privacy challenges for clients and networks. It should not be possible for a web site to be able to use a client's position in the network to access information that it would not otherwise be able to access itself. Allowing requests to a local resolver might allow access to that sort of information. Sites are better suited to making requests of configured resolvers. With DoH, they can make those requests from the client, meaning that the answers will be more suitable for the client's position in the network than their own. Though this requires that the configured resolver has nodes that are deployed near the client, I believe this to be sufficient. > > I think that problem A is pretty significant. The SUDN option does help there, but it eliminates the weak "authentication" we have. For anything in this area to work, I think that we would need some other basis for deciding that the DoH server that is identified in this way is OK. The only idea that I have, which is a poor one, is to configure clients with a list of "trusted" resolvers. I don't like maintaining these sorts of lists, but it might be the only way to manage it. No matter what option we choose here, I would prefer that we look at the DHCP/RA steps first. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Thu Apr 25 00:07:05 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61CF120136 for ; Thu, 25 Apr 2019 00:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 foiqcGAwi-7V for ; Thu, 25 Apr 2019 00:07:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 105101200EA for ; Thu, 25 Apr 2019 00:07:01 -0700 (PDT) Received: from [192.168.80.34] (unknown [85.93.99.179]) by mail.nic.cz (Postfix) with ESMTPSA id 5743B635A8 for ; Thu, 25 Apr 2019 09:06:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1556176018; bh=iiUAwD6+GVFw9miM6SSwk6uZtoqQBOdB6MDfDFtbzkY=; h=From:To:Date; b=drnFbfJ4XXA/q55R2CsgA2BXjfk9CmuA9Ms3qXJ6vmD6TkqA/Xz3SKN6bvrlZ5tNq iOjlgUJTutY72mMNU2/F8lAO93lLxtFw5WK9LW71/975BPjY+v6m2/J9z3nGASA/DD E1XAOXPR+8sQ3OOl8lijO1jEOrNERJeLB6FodcsE= From: Tomas Krizek To: doh@ietf.org References: Openpgp: preference=signencrypt Autocrypt: addr=tomas.krizek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhITjsBEACn+jYk59OSa7eul+bIaZERXTfhgfC6esfC5WPV0NmCig0W1JbunWglYX3B s1FJR4OCpchrbAQW3bEYDsddvy5rCbaG0IoOqNsd5GEhCmegDLNU/l36P83UUw8kkSJhlKr/ U+EO+bFyKljmF+dE+OvIky1A+wd1zgRkcljr9DOfdLsAqL4nIb/LC99ZD27laSEAoaZagHXW MVP0EExM3+T4V5sPJ3ghrK1hAk5spAX9yHUSF242zo+5Sj/l/dGL/PXDeCJPHjfdQNUkKcRT VlbAIjfl5mk//73z3XmRSKp9R5HsCKQjBC5Q38a/ZVDdaiSwIxw2sDLrI4+91ycsJ3gjtyiq yO43a4Y6mQHw9VZxudYG1hJ1+pAEPyLo/xIpGIlOo6BmmSz7gYgTPKB/dmGFOx/Qtrt8jNti y3oyRRMPdQ2Vl/MRAZ+OVSsSplf0uGFrhWOX6OPl6h7hu1mMbmHrQtgs835ZVfMf2IoK6QkF NFkn6HbdgF+4IZaX4br1WqZN2c51hKcIE4AHTSVSXwXRgdN/7Q2bmOH2IvfqTOX3HyfrIqUL nqUuD4tZB5Q+z7V5H6vzG5GR2CFlwkSgaayoplLG7h4Xh6Hyman95tl/xS61TeSfnv7NYIZj 6fw4veUUALQlTwDkOh17wByJitvYfBkoiCY7ShAxYyBckGGFxQARAQABtCJUb21hcyBLcml6 ZWsgPHRvbWFzLmtyaXpla0BuaWMuY3o+iQJXBBMBCABBAhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAAhkBFiEESoukjCrtkzvUlcUJoful9++MSGkFAlwZInQFCQXe2rkACgkQoful9++M SGnRWw//f6g+dd4ddcsocUpn4dCJGOQ9HqWMhAKItTq4UI8H337LATFCB8vKPmaDkKXIJYtw +4eZzhlZqTIzH6VUUnZWdM/Aifwnj2nCnfUD1wHUuEU7ZwNUEenl6YZfFHFqKaThcv8UNOss TUdWL752LwRMvaBscert2Jnc4siOYTRNcLJiqev36LXFwc/pbuH8TBrLVszB3MGrrMNv+NCy yCrk5vgGlzBXGJWwVKwf/7pPjN+0DiEeSbSFnxnFCUiyMYTVOhs5DanxNcdYu7cBMbLwp1cw EP+RzUSeOOrKcVdb839EXb0KtXQ6w9dAkpp7XeQs+os6bq8M9Mx6tdIv7bX/KUJWVRUed5ow SG6AJvRdSdvxpKom14CgWLM96tJVdz+Pttc29ObSGcucEvmAIAUtdFSmxYLnKVXq1EGfkZXX PDr/cSr2Lfedc+kb7GDqal6St4uYTo0Q3nVFwiHs19ZRqvf+6TCbOvv8PStxD4YbwlzNkcyF nKceU2a8dyvOhDR3s/5OONsjLT5srEmnArZy/0gtlzPEhserHhnnE7o0dnzy02QmktLaqhw2 MXX1zIifR4tf+MGY2rAm2YtilD78fcsFPOZ5w7GDufflxz2uzOQ1CtPiazoI7tNYSYJELTxD g9Es2KUNnT5sja5gKPpGSjK4mhOzvYrxIZnG4p7i5gO5Ag0EWimwOAEQANIie73DMB4rO0WE mJ4qXfJotkZEViX7MUMo+gh1Gb+zcC08gsY2rdtVXwydkjHimk90qupL0WvP2caYpGyeZrn8 4fuiNpbzDWM3r/EhArizGWgpiEh8B9Pp0Q7K1meA7Rkwk6C1O+Jns9RhXJFE2KPIPBBqwWG5 rNIChnPOt/ZpSmQ9fnqplMT+N83xeN9GDU9EwEPcwzLsq+nCgVcAam1zMUUGKNeiHj9pcg+U TfvTROSKkRQ0UGTKm7+vYi9+jbQDGeTNSoEUp/wqgneryhKISfBODTqCn5mjoBqWJqQB3u8G Kj0R1WNK/kmmNA5cNDZmzfx24a3I8DI110AoKBGvGkmzR+c1F3ScjrCrBf3ce4wj0tAVtpmr h1Zj8DA9Waa2MxYi2BNVH0nJf2m7xrc7K/NsCC3zdMLML7KF8oBmiVFMJCxozla1e1iDq/F8 aCjkeX6qtdycdYulVcQqgaXRpe821yYRreTjAdO9j05CSfqQ0CZUmPq/Ff5YJ928FJF4rJOU g6djm4CYaDH9/1kcIiAczpUvvd8U643oKOiN5cEooFKqc3uOLaiTQFc09pZm19rGY2wmn7qE Q6KoMuPXkrFOHkCpyqtW6dfHHJeimLBbvxLotdWrUaMtKjmwG61MueKCRPlysaA2HWcaqQiA Jk5U16eKb2ImjpO9UBepABEBAAGJBHIEGAEIACYCGwIWIQRKi6SMKu2TO9SVxQmh+6X374xI aQUCXBki0QUJA/15GQJAwXQgBBkBCAAdFiEEFe8t8KwPEBnPn+loGFnIJjkFVmwFAlopsDgA CgkQGFnIJjkFVmya5BAA0JPGtGHpCLnLPjxdLnIpUbQbaKA7AiYskJReIEqPOXWb9WguXYa0 j8PsO8d7sn/tBMqw7XdezjWcJWKutipV9tw6bWQfsx37dyplLwQ6FvuaAMAEXBdxS2Zvf5ff nq1/Sy+TZSRzVH9GkkP7LgjFfjt4sXTi6KT3zv25ILblJk/Am8qpBt5Iia6hLibDtaz54o3C motHi2JQLayWwQZ6A1a4/hlI7DczsEZfANxd2AItQOQQHvoTEuxFR0ew0dIdv5pLWrW2HfPi LCFUk2tPImpLvUsmHTQ0kRp5RunObplWIkb7MqCb8DhJ7rbU4eur+qW046pNxci94m0zpEBh dsgC2P+gYSfohYvpEdVMmUOETdxbEUREF1aud72+onyPSvLR6nTwM3Br/v1NK3o8t6K9zkUn BFDtjqXn7vsf0CA1eszcygsAi06CSgpv8qnU4j7YoBspbCjEINhip5iNigI3SN49gA9ON+0+ FszDZU3sokvIu2xfvePyZ7OhQD6lu+KITlwUH2EDIVpirH1ubO3VhxY6M9qBWs49UuCQbBaG BwpHlhg7n+wggx+k6Z59kU+4cd1Q9XNfbk2hVvYdCvHbtH78rh8maLBdGsiyoWrLvcDF+z3G /afej3QVAP2LdWkurAxhUp7sAf7VBKvcXCQ0/PGrfRpgdofxmNcQG1sJEKH7pffvjEhpdFUP /0dEjCqXFocJh+brbecd5UOAxZ8LmmBKcxyB0jr4oeiZBjhBy7Id55YwGRRAYm6MYW6S+g9g yoH5qw0u1fmAcxanXq3i7tLp6NZP+O4ZN0UP7G145VfgTU7qpj6KszvFaoWhMDIQk7ADry1k FrOPpB0q8fc2kIdcsTmAvl3l3oKrq4pEeUGuBoKZpoF/5tG6krv1tOjYXAmZ/hxR6ktBG3PK B1Q/rWu5RLhwrEofTtoxAGOL2XKm0FdvMlE0KWxSKgmJzZbQokm2mF1WbY2xCJLjaqUgaDpT tzGvihOlomFENrkQsWy75ywkcZoxXRKux6SU3xmodVeXTwI2BiPkwp+eaj3luZyfgD/f3x3Z MfNY3txJX1EATbF/0PM/EqJN3ZfdUu7fBfdKlf5tNnM+nfvHGG0VX6gooC2JzEjJARIl32rb WPdaNxOSkgWqXnH0YNv4195bAFet1wFjls3xbiFqwQr39ExwOQ8pneQ4pAOlq8evY8VDf6wh pjWyr5eNQNUjex1n2chF8GWLGTAggNpAxhO9QxXgKWvtg8uD1qyUPGc+S0kRwHtgGmbtVmPu TDk8kzECxV6x2tCnvqDwfGmX9DWfT+Aivu1n+0zigFQJbaJ4thhrZj7ls0jX0gqO720ogjCk SnRQFWnvzUH5Z4nhfq0nELZDO11mSAJuf3mCuQINBFopsMIBEADTHIG17I/eGluDtAgq5ryD bXc2q8NMNWotsNJvj9MbT6sCOq7gwHCrsbPMylxPTAsz/LIfaFzF5eIKJs4BfQJkgLrNPN6D r40zq/+rfl4tjrfpEzxFRYrqTRHIVEhc2TETdBkQNf351H+dAMrctjFvCzoEhap0MorxWmub uHLXqdsNPCAmnLCkn4nuBm49qBPtxZOalbKQx2OpBxkrvhHvTYh078WNqBFi3y2EW2RYqxVr I5u4fL2A2b505uaavup2gQIOuIgsnUciIw1iGUDRHlQt15w2H1y6w0rI5qYDKwVbO8cM6g3R CCh1A+sYYyXhPtxAqk+zcCswU15fuaf4PmcdS8js7CJxXJVeUD/1xrXDVMLSyrTJCLDT5Ki+ jAToqt8UzGeDyP6kUvz7f25O2eeR+myy8yDw8dF/CPHQLorHIczeQNRxvbWEwuBgMKNDQvyB Tx9jpmAjZ+oAc7n6eALwZF06hlhAu+T7aTg2DHCoobDSSG1xWfv1esBPjSMr4QpurTONMJXJ BMiBubVI7jsLltAIagpggimmZfDTO+lmI+/u69iK/LZTd0r960HhixmmHccNkc7wWnrSJr0s 6zTNi7ddscLdL+z9+g61g2LunQze4wHO9Bd5xcoDWUOY7TYKXKxkwapfHHdBG9oK6F3IZO/q vt4BALiSw0+KLQARAQABiQI8BBgBCAAmAhsMFiEESoukjCrtkzvUlcUJoful9++MSGkFAlwZ ItIFCQP9eI8ACgkQoful9++MSGkeTQ/9F5mW8VPQf6XOraSigIqfjb4WrrGc0kQwYlzILWiA 9jdmINHnX6gFriMkUuOcuntROmNUxOPxrTkBLZYvdF502O68LT2Je9aPo4loPyZancbIZAMN bYRp76zQHFjSJEdSW5I/rSsV7iufFQZ9Q7f6+UdSFfLmNBnlKKBYGfj7TmnyOk9u//J22nV0 Sinu1cmsYwcBSoHydu89YbSFs5Tu4vgbkA1D+ggCE9/XkoS+0nPEoyBalRKmm4oXt91+ArLn b62RxPYwo28axDAcg1jk4IC1kdRKa+X7dWfYFcknRa932m+SK2MY0yPNECZdva897yo1IylX y50zRSw4gujo+3cExFUuyfX71L4yG9ndQOPEtXJt2kQbbdvVOMFmNJjA4+l8DUyiRBwLfjhW VAF2WUI7YGbrwIxW5AqogBgFvx/iV3fgUHTeEU5/Jmzok/BI9cjlrd1ialNwyjQqBls8cjgk hGnPB8cZSUYiWm1WN6gqCmXTDzXVRoqaV68TJF2QMhficAHq1PgD9cFnOz9cfMaqVUputKUR R3anYpkxlDe8MGvoS3HCfnQwiOWRDDWfsmFfB64RROMDvojkhrJ6vgcpPH3R4lh8ZomGJUWS b9+pupY0mI26hpV4woYD0nQCGXJ58Hfh84DmufQuppdfoJwS50O9WO9B6Mpns/Ab61+JAjwE GAEIACYCGyAWIQRKi6SMKu2TO9SVxQmh+6X374xIaQUCXBki0gUJA8IjjgAKCRCh+6X374xI aY5tD/9Fw9WHqaFvcNu41M5oQjUbWl1jY6FutXgm+tapmHsWdQ6nTEA8Ch93HRUJC4I8grNR e4xd9qEZLGw+lrlmKhhroNqrzoaCIbl2/zRE4Pl0UOaMV/xR8x01Jr9kE6rrkHQt9HuSMffJ M76sqHEh95ZTfTWW6m228gRN3Wduqt2Mu0vlSQSdegog8DP7KnR5i/LcdgUfAm5D5NlBvJwR W55PJ24bp/zFCFZAQXMN75so4OLiig/yWgsnz2yxEsg/79aRf6p4R4jOy+aP/V43iJJKQkDx BG5X08kh+QBaGTaUHqalnOccIX9DcM4G9bz2WZySg3njmXVjRyD5ayNmy+WixhaMjKgudAAv zKqHpT6qKBwc4r+kqGxySvsVIU6IUxs9zzrUrwgyB5WRO45JZ5ZOXPOOFyEEIfb+VcMSzu5N 4U9vOAxGCTBhjEjJyai7Zz4hgx3c48rNMDmByHL9sd8GwwGoCdoCDiZti62fBYxUfsHtoaxb kSnXMtN0LeQclHSjQpDMO/k2Ow8/19sG8XqW+d4nLz+7se4QjmNEf8xAkice+t7hEtu8sqcu vfISaURjPOEYzPdTymo7Bd9aYICCewHgCJEP1n0Fk5dj6ZMmUR86vDE2wm7qaEDc9M5sDqV3 pHNUGPUm3ANtW8nHF/R57lLE9IGZBe82eO9g+s9qtg== Message-ID: <0b27ee95-8404-cccf-93e4-adbb612d174c@nic.cz> Date: Thu, 25 Apr 2019 09:07:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jsqvaQh4nNUVIX5AsKZUfXS8uw1ylK6eL" X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [Doh] Dedicated DoH port X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 07:07:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jsqvaQh4nNUVIX5AsKZUfXS8uw1ylK6eL Content-Type: multipart/mixed; boundary="HmKWUUAryeo1uti5YntBAJamTHfPStxRn"; protected-headers="v1" From: Tomas Krizek To: doh@ietf.org Message-ID: <0b27ee95-8404-cccf-93e4-adbb612d174c@nic.cz> Subject: Re: Dedicated DoH port References: In-Reply-To: --HmKWUUAryeo1uti5YntBAJamTHfPStxRn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/04/2019 19.41, Tomas Krizek wrote: > Since there is currently no IANA assigned DoH port, I've filed the > following user port request with IANA to establish a common default tha= t > could be used among DNS vendors. >=20 > Service Name: [domain-doh] > Desired Port Number: [44353] > Description: [DNS query-response protocol over HTTPS] To follow up on this information, this request was declined by IANA. Overall, my impression from this community, as well as the RFC 8484 and IANA, is there is a strong preference for port 443 for DoH. I understand the reasons for it and I'll keep investigating the packaging options for Knot Resolver to use this port 443 on our users lis= t. --=20 Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 --HmKWUUAryeo1uti5YntBAJamTHfPStxRn-- --jsqvaQh4nNUVIX5AsKZUfXS8uw1ylK6eL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEFe8t8KwPEBnPn+loGFnIJjkFVmwFAlzBXMoACgkQGFnIJjkF VmyJqA//eHwfpEXNNlcgVznI0SbPOtPBk+QPvZVLHLBsGCkPqdIeZnrXgTMbx19N rHuzdh8elmKKiV0qEiAAlpVebcFcTf4RAwm9QipmHJ5hO870ysrGAXQrkaQoiPDE /uANxOpqwjFo2WMZj6f6sB/YWqrtNYA5Wl/owHk7UYlJCOfCLxIbwa6p5ParTUdV i0d3Ud7WxI0/iNEQI4FaSsv3vTiGQQcVjRHOGI1541NrA02AoowcqWZwOtcZCIpg +5V/p+J0KK1KjAOVRcUV4Va/iKMK7lL+oC8MxICJS2wYI3PNUJ9kBAmSFKFi5O/K FY/H8tvcAaQFZ03gmfo3uFHzl1WrGh9dXrmqA8XaV32pjNOms7BBBy389Ei7N2sT 6uDwX2dtiW2DCLJuZTUQWykxX3D2HqwU9J0u9EsL7JGqIofVO3UbtvjR//cCiRog uTyr2UOa17JpNgfYjPJa04ZIQRJ2ZxcL5HuQvRY9gTZAq2Ay5t4XY1Sx2fQSmcm1 F4TbWR2J0UdbeqyCD1XBwBOHQKlZaCknQg4W2uAo+KzPrQvdTr0Z6e13ekgPHjJr Hz0qc1g6uxinBQ3+KUjFYFC/5h+oy2QbDPqRuBSiQX/PaqYnNmg5ERJ9y8wbu3wY EUo1O24GlhRia361Ji32c3P+ChXC1DclvrYpFeA2fs4LIg/p+HQ= =TPyY -----END PGP SIGNATURE----- --jsqvaQh4nNUVIX5AsKZUfXS8uw1ylK6eL-- From nobody Tue Apr 30 14:00:50 2019 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1612016C for ; Tue, 30 Apr 2019 14:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 M3LupLF26j2p for ; Tue, 30 Apr 2019 14:00:47 -0700 (PDT) Received: from mail.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BBD12015C for ; Tue, 30 Apr 2019 14:00:47 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 30 Apr 2019 14:00:46 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Tue, 30 Apr 2019 14:00:46 -0700 From: Paul Hoffman To: doh WG Thread-Topic: New draft, seeking comments in DNSOP: draft-sah-resolver-information Thread-Index: AQHU/5fH8aBwa2M3dkGJ3lqDMHKOVg== Date: Tue, 30 Apr 2019 21:00:45 +0000 Message-ID: <7872F13E-61C5-491B-88EB-C60F0F3AC2D4@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <342D7F9840E9384BB482D7EFEAC16631@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] New draft, seeking comments in DNSOP: draft-sah-resolver-information X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 21:00:49 -0000 Greetings again. Puneet, Roy and I have just published a -00 with an idea f= or how to get information about a recursive resolver from the resolver, if = it wants to give that information. This is an outgrowth of my earlier work = in the DOH WG on draft-ietf-doh-resolver-associated-doh. The discussion on = that latter draft in Prague had a couple of people saying "this should be m= ore general than just DoH" and "what about DoT", which sparked the idea for= draft-sah-resolver-information. We have started the discussion in DNSOP because the draft covers much more = than DoH. If DNSOP folks think that the idea has legs, I would ask the DOH = WG to drop discussion of draft-ietf-doh-resolver-associated-doh in favor of= the new draft. If not, I'll keep working on draft-ietf-doh-resolver-associ= ated-doh here. --Paul Hoffman