From nobody Fri Jun 1 03:29:21 2018 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 ECF751276AF for ; Fri, 1 Jun 2018 03:29:18 -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, FREEMAIL_FROM=0.001, 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 uGe7UCmT3cu8 for ; Fri, 1 Jun 2018 03:29:16 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 0292F127871 for ; Fri, 1 Jun 2018 03:29:15 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 8693 invoked from network); 1 Jun 2018 12:29:12 +0200 Received: from agkn64.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.141.64]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 1 Jun 2018 12:29:12 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus , DoH WG References: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl> Openpgp: preference=signencrypt Message-ID: Date: Fri, 1 Jun 2018 12:23:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IIrllgchNlhw6dZIpvEuh3zTP7PnLOhkR" X-WP-MailID: abecddc0502948b71ebb5818c290806d X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [URPU] Archived-At: Subject: [Doh] HTTP/2 and constrained environments X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 10:29:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IIrllgchNlhw6dZIpvEuh3zTP7PnLOhkR Content-Type: multipart/mixed; boundary="xhQWWf7c7FgrHMPInMfqrVO00R8f0h6V3"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus , DoH WG Message-ID: Subject: [Doh] HTTP/2 and constrained environments References: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl> In-Reply-To: --xhQWWf7c7FgrHMPInMfqrVO00R8f0h6V3 Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 23.05.2018 o=C2=A023:13, Patrick McManus pisze: > On Wed, May 23, 2018 at 5:40 AM, Mateusz Jo=C5=84czyk > wrote: >=20 >=20 > How difficult it would be to implement HTTP/2 on a home router with= 8 MB of > flash and 32 MB of RAM? Would it at all be possible?=20 >=20 >=20 > no problem really. HTTP/2 provides a number of mechanisms for either pe= er to > scale things down (e.g.reducing state in the compression dictionary, li= miting > the number of outstanding streams , small flow control windows, etc ). HTTP/2 may be larger in code size and this is a serious limitation in hom= e routers (it is in most cases a more important limiting factor then RAM si= ze). It will probably also be more difficult to implement (in terms of coding eff= ort). >=20 > searching for nginx and dd-wrt yields lots of howto's > https://www.dd-wrt.com/phpBB2/viewtopic.php?t=3D312701&sid=3Ddfc6638ad8= a57c7d3540d4b3aae828d3=C2=A0 > .. nginx has http/2 support. >=20 I suppose it is feasible to run NGINX only on high-end routers. There are= high-end routers with lots of RAM (like 128MB and more) and ability to mo= unt external media (USB or SD card or Samba network drives). The router mentioned in the forum thread (Linksys WRT1900ACv2) is one of = the highest-end router models supported by DD-WRT and is very expensive. AFAIK NGINX will not easily run on routers with 32 MB RAM and 8 MB flash,= at least not without consuming much of the precious resources. >=20 > Would it be much more > difficult to implement than HTTP/1.0? All of my routers support onl= y > HTTP/1.0 in > the management interface. >=20 >=20 > I'm just speculating, but I suspect that has more to do with https and = the > challenges of provisioning certs on that kind of device than anything e= lse. Two of my three routers support HTTPS, so it seems it does not have much = to do with enabling HTTPS (the third router is a really constrained device with= 16MB of RAM and 2MB of flash). I suppose that it has much to do with simplicity of protocol and ease of implementation. There are few benefits to upgrade a router management int= erface to support HTTP/1.1 or HTTP/2.0. > =C2=A0 >=20 > Would it be beneficial to specify that DNS API clients SHOULD suppo= rt DNS API > servers that only talk HTTP/1.0 or HTTP/1.1? >=20 >=20 > imo we shouldn't be explicitly encouraging older protocols. Why not? They may be deprecated, but still may be a better choice in some= cases (as outlined above). Greetings, Mateusz --xhQWWf7c7FgrHMPInMfqrVO00R8f0h6V3-- --IIrllgchNlhw6dZIpvEuh3zTP7PnLOhkR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbER/2AAoJEPvWWrhhCv7GzQYP/j3E+ByC3n58Mj4x1t6a0OEf ALh9N62TCwHbLWAQnQtA5Yj/QoU8ssl3ogMuUjcHrThEhkJVvKoyQ2YIZjyFX+wU xp+xtsyr8lY4SLtu1nEPVA887jUEqX5J4oB/jNPthgMQ/k0q96bG8lchy909uw/y YpNO1LXCBx864UxgI01hQRtKTUS0LlT6JBZip6jLyzc46bMmdXVXzfhmJXxib2Kv +qXKiZcBh8dWVw4TB+ZBGeO8OO0hg+lUpPMmgYUiHygacMsNZpJ9kri6FZkzhLem 3vkbNxy2kiDq5N5I6XnkUYeFLnkd1xzt1aiUBXr1t1CMm9ViljtfMNDgcpSAOAhe FLwpJkfrETqmVlNtvsngPDMDMoJPMpnB/z7Y9wJYNxi8meQLGGLEGiNb+xFHY3iZ XvXSThyzSrw0wEuIPvrT9I7VG5dq5eWR6NHyV07X6cRSQ+l8b9GCZ2MaNRWzzT/s pneJdBB/UpVPr8z9x7YOyafxNRqI3W/I0JFnNSBJLOHS4On45meNZXsTfGJtchii N7mUFaSMzCN5Gnu8I3G8EMjBTZR56CdN3U0t2YUeoqIdAd599ciyzZjI0+0GQidG n7eYQE31gHkBVg4MhBFa8j0tKr6oPdQPxT2l8ncvwDdaUrNSexR4baoIq3Q9N8/L nP56+GXby983DKHN+JrG =NF87 -----END PGP SIGNATURE----- --IIrllgchNlhw6dZIpvEuh3zTP7PnLOhkR-- From nobody Fri Jun 1 08:19:01 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1091205F0; Fri, 1 Jun 2018 08:18:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152786633932.15070.4115102497811684482@ietfa.amsl.com> Date: Fri, 01 Jun 2018 08:18:59 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-10.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 15:19:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS (DOH) Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-10.txt Pages : 18 Date : 2018-06-01 Abstract: This document describes how to make DNS queries over HTTPS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-10 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 5 05:05:29 2018 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 53E42130FF6 for ; Tue, 5 Jun 2018 05:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 vskuc4kDv6UR for ; Tue, 5 Jun 2018 05:05:25 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D3B131001 for ; Tue, 5 Jun 2018 05:05:20 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id B1CD59FB55 for ; Tue, 5 Jun 2018 12:05:10 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 49713AC5B02; Tue, 5 Jun 2018 14:05:10 +0200 (CEST) Date: Tue, 5 Jun 2018 14:05:10 +0200 From: bert hubert To: doh@ietf.org Message-ID: <20180605120510.GA29047@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 12:05:28 -0000 Dear DOH-people, As I'm implementing DOH in dnsdist (expect something you can try later this week), I am a bit confused. The question is what maximum response size I should send in the absence of an EDNS buffer size. So let's say a query comes in without EDNS for www.whitehouse.gov, but the answer exceeds 512 bytes. Should I truncate? I have read the draft and previous discussion, which has led to: Also note that while [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", that was later updated by [RFC6891]. This protocol allows DNS on-the-wire format payloads of any size." This is not explicit on what an implementation should do, only what the protocol could support. Some further text: A DNS API server is allowed to answer queries with any valid DNS response. For example, a valid DNS response might have the TC (truncation) bit set in the DNS header to indicate that the server was not able to retrieve a full answer for the query but is providing the best answer it could get. A DNS API server can reply to queries with an HTTP error for queries that it cannot fulfill. In this same example, a DNS API server could use an HTTP error instead of a non- error response that has the TC bit set. This seems says sending a TC response is some kind of error, which implies a DNS API server should be willing to send 65 kilobyte answers. I think for the new usecases, this would be a fine default. However, there might be UDP-to-DOH bridges which would then need to put explicit EDNS buffersize of 512 in there if they get non-EDNS adorned UDP queries. If the '65 kilobyte' interpretation is correct, I can supply text that will hopefully make this explicit and unconfuse future implementers. Bert From nobody Tue Jun 5 05:35:53 2018 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 4D210131006 for ; Tue, 5 Jun 2018 05:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 S3x68NDhW0Fp for ; Tue, 5 Jun 2018 05:35:50 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5BA130FFF for ; Tue, 5 Jun 2018 05:35:50 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 385EE9FB55 for ; Tue, 5 Jun 2018 12:35:41 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 82CBEAC54A3; Tue, 5 Jun 2018 14:35:41 +0200 (CEST) Date: Tue, 5 Jun 2018 14:35:41 +0200 From: bert hubert To: doh@ietf.org Message-ID: <20180605123541.GB29047@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] assorted things X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 12:35:52 -0000 Hi everyone, I'm going through -10 with fresh eyes, so I may be discovering some parts that are not obvious to the outsider, or at least this reader. This paragraph in 4 seems to be important, but I can't figure out what it is trying to achieve: A DNS API client MUST NOT use a different URI simply because it was discovered outside of the client's configuration, or because a server offers an unsolicited response that appears to be a valid answer to a DNS query. This specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as configured URIs. Such scenarios may create additional operational, tracking, and security hazards that require limitations for safe usage. A future specification may support this use case. Does this say "don't just use any URI"? What are 'DNS resolution privileges'? Is this about disallowing javascript to send out random DNS queries? This sentence: Some of these non-successful HTTP responses (e.g., redirects or authentication failures) could mean that clients need to make new requests to satisfy the original question. I would recommending teeth to this. Naive implementations may decide to not follow 3xx codes. I would recommend making this explicit with a MUST. Also, it may be worth it to explicitly say if authentication is in our out of scope. Here it is a bit uncertain if you'd ever prompt a user for a username/password for doing DNS resolution. In 6.3 "Server Push": For HTTP server push ([RFC7540] Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request. This means an API server is free to send responses to DNS queries we haven't seen yet? And should a client do something with that? Or can it ignore the pushed records? Bert From nobody Tue Jun 5 06:02:36 2018 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 DE77F131012 for ; Tue, 5 Jun 2018 06:02:34 -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 YPCn5few-hyQ for ; Tue, 5 Jun 2018 06:02:28 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE4B130DF3 for ; Tue, 5 Jun 2018 06:02:28 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 6A5CC23720; Tue, 5 Jun 2018 09:02:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23318.35298.418727.723565@gro.dd.org> Date: Tue, 5 Jun 2018 09:02:26 -0400 From: Dave Lawrence To: bert hubert Cc: doh@ietf.org In-Reply-To: <20180605120510.GA29047@server.ds9a.nl> References: <20180605120510.GA29047@server.ds9a.nl> Archived-At: Subject: Re: [Doh] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 13:02:35 -0000 bert hubert writes: > This seems says sending a TC response is some kind of error, which > implies a DNS API server should be willing to send 65 kilobyte > answers. Yes, based on previous conversations, this is basically the case -- though not just 6kk, but theoretically even longer. While 64k is the limit on DNS/TCP, it is not an intrinsic limit of DNS wire format encoding. Note, I'm not advocating that DoH servers should be sending such large messages, just that like with other HTTPS messages there is no hard limit. > I think for the new usecases, this would be a fine default. However, there > might be UDP-to-DOH bridges which would then need to put explicit EDNS > buffersize of 512 in there if they get non-EDNS adorned UDP queries. Right, there is a separate matter of handling transparent proxies, but for the basic use case a client/server should not have to muck around with the network limitations of the DNS protocol. That's one of the wins of using HTTPS. > I can supply text that will hopefully make this explicit and > unconfuse future implementers. Excellent, but do note that we are on the cusp of moving the document along. Please do so quickly for the authors to evaluate. From nobody Tue Jun 5 06:19:16 2018 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 0DDD813100F for ; Tue, 5 Jun 2018 06:19:14 -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 6DtGlJM1rIk9 for ; Tue, 5 Jun 2018 06:19:11 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 63C7C13100D for ; Tue, 5 Jun 2018 06:19:10 -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 w55DJ7MG006331 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Jun 2018 15:19:07 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w55DJ6kj006326; Tue, 5 Jun 2018 15:19:07 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 5 Jun 2018 15:19:06 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: bert hubert cc: doh@ietf.org In-Reply-To: <20180605123541.GB29047@server.ds9a.nl> Message-ID: References: <20180605123541.GB29047@server.ds9a.nl> 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] assorted things X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 13:19:15 -0000 On Tue, 5 Jun 2018, bert hubert wrote: > Some of these non-successful HTTP responses (e.g., redirects or > authentication failures) could mean that clients need to make new > requests to satisfy the original question. > > I would recommending teeth to this. Naive implementations may decide to not > follow 3xx codes. I would recommend making this explicit with a MUST. Also, > it may be worth it to explicitly say if authentication is in our out of > scope. Isn't all of this basically just how HTTP works and offers? RFC 7231 section 6.4 explains redirects just fine I think and HTTP authentication is certainly a part of HTTP and is explained in RFC7235. > Here it is a bit uncertain if you'd ever prompt a user for a > username/password for doing DNS resolution. To me that sounds more like a UI/program decision and not something we need to specify. > In 6.3 "Server Push": > For HTTP server push ([RFC7540] Section 8.2) extra care must be taken to > ensure that the pushed URI is one that the client would have directed the > same query to if the client had initiated the request. > > This means an API server is free to send responses to DNS queries we haven't > seen yet? And should a client do something with that? Yes, basically. See RFC 75450 section 8.2. > Or can it ignore the pushed records? A HTTP/2 client can always opt to either not ever accept pushed resources or deny them when offered. -- / daniel.haxx.se From nobody Tue Jun 5 07:13:08 2018 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 39ED013107D for ; Tue, 5 Jun 2018 07:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 ECD9jEp4EuyJ for ; Tue, 5 Jun 2018 07:13:04 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 C246F131055 for ; Tue, 5 Jun 2018 07:13:04 -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, 5 Jun 2018 07:13:02 -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, 5 Jun 2018 07:13:02 -0700 From: Paul Hoffman To: bert hubert CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] a tad confused on response sizes Thread-Index: AQHT/MWCHKfSaHDR5060bxLSfOCW76RSKm2A Date: Tue, 5 Jun 2018 14:13:02 +0000 Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> In-Reply-To: <20180605120510.GA29047@server.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_CB4ABEEA-5066-4A5C-8B19-97F2535D4C62"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:13:06 -0000 --Apple-Mail=_CB4ABEEA-5066-4A5C-8B19-97F2535D4C62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2018, at 5:05 AM, bert hubert = wrote: >=20 > Dear DOH-people, >=20 > As I'm implementing DOH in dnsdist (expect something you can try later = this > week), I am a bit confused. >=20 > The question is what maximum response size I should send in the = absence of > an EDNS buffer size. So let's say a query comes in without EDNS for > www.whitehouse.gov, but the answer exceeds 512 bytes. Should I = truncate? >=20 > I have read the draft and previous discussion, which has led to: >=20 > Also note that while [RFC1035] says "Messages carried by UDP are > restricted to 512 bytes", that was later updated by [RFC6891]. = This > protocol allows DNS on-the-wire format payloads of any size." >=20 > This is not explicit on what an implementation should do, only what = the > protocol could support. Some further text: >=20 > A DNS API server is allowed to answer queries with any valid DNS > response. For example, a valid DNS response might have the TC > (truncation) bit set in the DNS header to indicate that the = server > was not able to retrieve a full answer for the query but is > providing the best answer it could get. A DNS API server can = reply > to queries with an HTTP error for queries that it cannot = fulfill.=20 > In this same example, a DNS API server could use an HTTP error > instead of a non- error response that has the TC bit set. >=20 > This seems says sending a TC response is some kind of error Not at all. The first sentence is quite explicit.=20 > , which implies > a DNS API server should be willing to send 65 kilobyte answers. ...if it wants to, yes. > I think for the new usecases, this would be a fine default. However, = there > might be UDP-to-DOH bridges which would then need to put explicit EDNS > buffersize of 512 in there if they get non-EDNS adorned UDP queries. Bridges and proxies and gateways, for any protocol, always have to make = these kinds of decisions.=20 > If the '65 kilobyte' interpretation is correct, I can supply text that = will > hopefully make this explicit and unconfuse future implementers. Sure, please do. --Paul Hoffman= --Apple-Mail=_CB4ABEEA-5066-4A5C-8B19-97F2535D4C62 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCCBZUw ggR9oAMCAQICEAHlUc/Wu3bw9qj3vjSgnBAwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE1MDYyOTAwMDAwMFoXDTE4MDYyOTEy MDAwMFowgbQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMRUwEwYDVQQDEwxQYXVsIEhvZmZtYW4xJTAjBgkqhkiG9w0BCQEWFnBhdWwu aG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFp+z8d5Ge 3VPgAkNc47Br7C7lVgMGi3KPyzdtdsjKDFmk8G0b4YNv+pmv8TvISr4XRpHf/+u/+1n7wkKhjVjk rY32PWhXEzk5Vky2MGaS9DiNSGwmyY6FXXxwFR8/e9f/DNZy2UEeYFrHz/kIzf5cwwdfrNEPkds8 FNfftOzdg195KOGVbIyC2DmnA8R0VNN9Ymv8U9+uojD0uuQSxK2z0NspQZdjjthk9CgLtGTDqIsk Ji4AuAkwjCmff5aHlEY+G5GyHRuEpczLGqRIEbpLoRTFnLTrhrbshkxsYQM5pNwWTidtw9CWWEmd RX96sMvym3SdYGkhfFWlpgoF7/3nAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAdBgNVHQ4EFgQU9btKWvkJMHw27U3VEwvQ+VCtpqEwDAYDVR0TAQH/BAIwADAh BgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB1Zc/uexWtNIjStm4b/HN1W5/Hcl4eE58O lh+2JgLIsgY7Ten6HoOx/4LNFKPQlnCMdyy1XqkF9FDU/7O+a98B+++tWTvk3U7EBqKGe7XLw1oq w6ymSNZ/gn4L+Bh4Ka5I3RY15+tWxfAOiHkLFHGFvU7NA2Oqsue8tD5fZD/+UNNlQ5YVDiQCgkN1 miFgb6tkX6kLnuItIU1LSFi8etVL+5MN7NyuH2Y/Ta7h3p+JsIvdAGe2F1+9RiVMkHDSRgiS05qo TpdWBJ0hnX9B/0nSs+gXeZbGkO1KXS4+KC9dt+FriAhd5fHc/9g8qtbEkh2TdSZdfse7idXAG+UB tAx3MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/ vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG 2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9 CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh 7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAB5VHP1rt28Pao9740oJwQMAkGBSsOAwIaBQCg ggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYwNTE0MTMw MlowIwYJKoZIhvcNAQkEMRYEFBT70yImlCkAZeFVsvueAy+JISK0MIGIBgkrBgEEAYI3EAQxezB5 MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2 qPe+NKCcEDCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2qPe+NKCcEDANBgkqhkiG9w0BAQEFAASCAQC3fQGU fQw/bdBtMAxG/NbTWC+cOS6fga/m3SlP8OzYS2pw3Rckk3HkuuS2wGI5npZZqa4cfVV4HR+6gVsS EnRms0A96P3qDnxC5Z381GBl5wacYrq1hLpn2ntOshjMu1jYIA5W9Ntm6gGuE74Pvx3WaDvXS6Jz lIy+YNTbl17VN4QAchoOl37644qqToeOevCV1jObnxz88jGME/7ilMirYZyTqSyA1Jmqb6ToC993 jrU8hpQw2FT9Vkk8FV5Qk2RzSI0JnrjHFmyFRFzSF111RLtTZhRRW6rgNFxo6l4/sHPWOzKH54Dm YoA9XwxYZw7sJLD2nyavYwHcWsPvKkMBAAAAAAAA --Apple-Mail=_CB4ABEEA-5066-4A5C-8B19-97F2535D4C62-- From nobody Tue Jun 5 07:14:03 2018 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 3C8A1131084 for ; Tue, 5 Jun 2018 07:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 21hsEUbo_mk2 for ; Tue, 5 Jun 2018 07:13:58 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 9B0CA13107D for ; Tue, 5 Jun 2018 07:13:58 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55214) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQCii-000pem-M8 (Exim 4.91) (return-path ); Tue, 05 Jun 2018 15:13:56 +0100 Date: Tue, 5 Jun 2018 15:13:56 +0100 From: Tony Finch To: bert hubert cc: doh@ietf.org In-Reply-To: <20180605120510.GA29047@server.ds9a.nl> Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:14:03 -0000 bert hubert wrote: > > This seems says sending a TC response is some kind of error, which implies > a DNS API server should be willing to send 65 kilobyte answers. Yes. > I think for the new usecases, this would be a fine default. However, there > might be UDP-to-DOH bridges which would then need to put explicit EDNS > buffersize of 512 in there if they get non-EDNS adorned UDP queries. If a UDP-to-DoH proxy gets an oversized answer it will have to do its own truncation. My trivial DoH code makes upstream queries over TCP, so the EDNS buffer size is ignored. I don't think a DoH server should have to truncate answers. Tony. -- f.anthony.n.finch http://dotat.at/ Tyne, Dogger: North 5 or 6, becoming cyclonic 3 or 4, occasionally 2 later. Moderate. Occasional drizzle later. Good, occasionally poor later. From nobody Tue Jun 5 07:17:35 2018 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 6D1181310AD for ; Tue, 5 Jun 2018 07:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qBwyuD-2TnqT for ; Tue, 5 Jun 2018 07:17:30 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 7FD12131088 for ; Tue, 5 Jun 2018 07:17:28 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55296) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQCm6-000sdR-MG (Exim 4.91) (return-path ); Tue, 05 Jun 2018 15:17:26 +0100 Date: Tue, 5 Jun 2018 15:17:26 +0100 From: Tony Finch To: Paul Hoffman cc: bert hubert , "doh@ietf.org" In-Reply-To: Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:17:33 -0000 Paul Hoffman wrote: > On Jun 5, 2018, at 5:05 AM, bert hubert wrote: > > > > A DNS API server is allowed to answer queries with any valid DNS > > response. For example, a valid DNS response might have the TC > > (truncation) bit set in the DNS header to indicate that the server > > was not able to retrieve a full answer for the query but is > > providing the best answer it could get. A DNS API server can reply > > to queries with an HTTP error for queries that it cannot fulfill. > > In this same example, a DNS API server could use an HTTP error > > instead of a non- error response that has the TC bit set. > > > > This seems says sending a TC response is some kind of error > > Not at all. The first sentence is quite explicit. Thinking about this further, I think this is a bug, because a DoH client doesn't have any way to recover from TC. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall, Malin: Variable or cyclonic, 3 or 4. Slight, occasionally moderate. Mainly fair. Moderate or good. From nobody Tue Jun 5 07:42:30 2018 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 F1B151310BE for ; Tue, 5 Jun 2018 07:42:27 -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 BPYQ4-eUYiDu for ; Tue, 5 Jun 2018 07:42:26 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8606C131002 for ; Tue, 5 Jun 2018 07:42:26 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Jun 2018 07:42:24 -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, 5 Jun 2018 07:42:24 -0700 From: Paul Hoffman To: bert hubert CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] assorted things Thread-Index: AQHT/MnAMTM+RUINW0SyNYIuXR3MXKRSMpmA Date: Tue, 5 Jun 2018 14:42:23 +0000 Message-ID: <95D1F35A-B7C4-4AF9-B682-CA1C17DCE34F@icann.org> References: <20180605123541.GB29047@server.ds9a.nl> In-Reply-To: <20180605123541.GB29047@server.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_54AB44F6-906C-477A-8FF6-B6FDB0FD36C5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] assorted things X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:42:29 -0000 --Apple-Mail=_54AB44F6-906C-477A-8FF6-B6FDB0FD36C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2018, at 5:35 AM, bert hubert = wrote: >=20 > Hi everyone, >=20 > I'm going through -10 with fresh eyes, so I may be discovering some = parts > that are not obvious to the outsider, or at least this reader.=20 >=20 > This paragraph in 4 seems to be important, but I can't figure out what = it is > trying to achieve: >=20 > A DNS API client MUST NOT use a different URI simply because it was > discovered outside of the client's configuration, or because a = server > offers an unsolicited response that appears to be a valid answer to = a > DNS query. This specification does not extend DNS resolution > privileges to URIs that are not recognized by the DNS API client as > configured URIs. Such scenarios may create additional operational, > tracking, and security hazards that require limitations for safe > usage. A future specification may support this use case. >=20 > Does this say "don't just use any URI"? It says "don't use a URI that is not configured". > What are 'DNS resolution > privileges'? The equivalent of "a DNS open resolver that you discovered by accident". > Is this about disallowing javascript to send out random DNS > queries?=20 No. It is about them sending out queries to servers not in their = configuration. >=20 > This sentence: >=20 > Some of these non-successful HTTP responses (e.g., redirects or > authentication failures) could mean that clients need to make new > requests to satisfy the original question. >=20 > I would recommending teeth to this. Naive implementations may decide = to not > follow 3xx codes. I would recommend making this explicit with a MUST. Good catch. We assume that developers of DNS API clients will follow = HTTP semantics here, but we didn't say so explicitly. > Also, > it may be worth it to explicitly say if authentication is in our out = of > scope. No, definitely not. Authentication is completely in scope. > Here it is a bit uncertain if you'd ever prompt a user for a > username/password for doing DNS resolution.=20 HTTP authentication does not require a UI at all. >=20 > In 6.3 "Server Push": > For HTTP server push ([RFC7540] Section 8.2) extra care must be = taken to > ensure that the pushed URI is one that the client would have = directed the > same query to if the client had initiated the request. >=20 > This means an API server is free to send responses to DNS queries we = haven't > seen yet? And should a client do something with that? Or can it = ignore the > pushed records? Yes; not "should" but "may"; yes. This is all well-defined in HTTP/2. --Paul Hoffman= --Apple-Mail=_54AB44F6-906C-477A-8FF6-B6FDB0FD36C5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCCBZUw ggR9oAMCAQICEAHlUc/Wu3bw9qj3vjSgnBAwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE1MDYyOTAwMDAwMFoXDTE4MDYyOTEy MDAwMFowgbQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMRUwEwYDVQQDEwxQYXVsIEhvZmZtYW4xJTAjBgkqhkiG9w0BCQEWFnBhdWwu aG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFp+z8d5Ge 3VPgAkNc47Br7C7lVgMGi3KPyzdtdsjKDFmk8G0b4YNv+pmv8TvISr4XRpHf/+u/+1n7wkKhjVjk rY32PWhXEzk5Vky2MGaS9DiNSGwmyY6FXXxwFR8/e9f/DNZy2UEeYFrHz/kIzf5cwwdfrNEPkds8 FNfftOzdg195KOGVbIyC2DmnA8R0VNN9Ymv8U9+uojD0uuQSxK2z0NspQZdjjthk9CgLtGTDqIsk Ji4AuAkwjCmff5aHlEY+G5GyHRuEpczLGqRIEbpLoRTFnLTrhrbshkxsYQM5pNwWTidtw9CWWEmd RX96sMvym3SdYGkhfFWlpgoF7/3nAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAdBgNVHQ4EFgQU9btKWvkJMHw27U3VEwvQ+VCtpqEwDAYDVR0TAQH/BAIwADAh BgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB1Zc/uexWtNIjStm4b/HN1W5/Hcl4eE58O lh+2JgLIsgY7Ten6HoOx/4LNFKPQlnCMdyy1XqkF9FDU/7O+a98B+++tWTvk3U7EBqKGe7XLw1oq w6ymSNZ/gn4L+Bh4Ka5I3RY15+tWxfAOiHkLFHGFvU7NA2Oqsue8tD5fZD/+UNNlQ5YVDiQCgkN1 miFgb6tkX6kLnuItIU1LSFi8etVL+5MN7NyuH2Y/Ta7h3p+JsIvdAGe2F1+9RiVMkHDSRgiS05qo TpdWBJ0hnX9B/0nSs+gXeZbGkO1KXS4+KC9dt+FriAhd5fHc/9g8qtbEkh2TdSZdfse7idXAG+UB tAx3MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/ vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG 2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9 CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh 7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAB5VHP1rt28Pao9740oJwQMAkGBSsOAwIaBQCg ggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYwNTE0NDIy M1owIwYJKoZIhvcNAQkEMRYEFCQV5Rm3cP7iWOgsmGwnfIun09oMMIGIBgkrBgEEAYI3EAQxezB5 MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2 qPe+NKCcEDCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2qPe+NKCcEDANBgkqhkiG9w0BAQEFAASCAQAj2sDA VPn3WXixZK/a6P8csEcPM03j1aTu66zcBZ9da3ZicvJn6Zs7mxnDkvC0+jTk7JBgMZfToLbiM4Hi RkZJa+3NNyy5BKxjJmvO/rs+uCQUAvn9DgK82Vc2KwSukG7+CBFn8UhylIx612DAZgwk8L6r8Tqp xhuQiVt8oc9KVNtAS67SM7fPv3TP7WUwsuBbsgT82yUcGTX5NSd4DeRiIueIp8SGTFTEA9W+1oDF PEcs2izPYgn7X0G9fougVZNiR8Takt7Ox6Xvu1iElIeZj776LH+I6QubQVioUChMVd9ns5xH1yOX M1ds9OIBwu7CEJcsC0VAFQ4EtoXauZybAAAAAAAA --Apple-Mail=_54AB44F6-906C-477A-8FF6-B6FDB0FD36C5-- From nobody Tue Jun 5 07:46:57 2018 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 6C16913103F for ; Tue, 5 Jun 2018 07:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 U8DgCo2w1iuc for ; Tue, 5 Jun 2018 07:46:53 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9C720131002 for ; Tue, 5 Jun 2018 07:46:53 -0700 (PDT) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id C5B4C3A04F for ; Tue, 5 Jun 2018 10:46:52 -0400 (EDT) Received: by mail-ot0-f175.google.com with SMTP id n3-v6so3128307ota.5 for ; Tue, 05 Jun 2018 07:46:52 -0700 (PDT) X-Gm-Message-State: ALKqPwc1O2buTxU3ryhUPjCjYrDvyDancXEAWzO9glV5NHNH4Vg2xPYi KHamvJuJVsemMQHaBtJUWWsHtRGOPUboR0ijoRo= X-Google-Smtp-Source: ADUXVKKOGEqIj831Ih50rXNsvN7ck+Zz0+v4gWxLYm8KeQ6PCgJEexetCE1ZA5MiwL3gjPC91yZdNZrbEitTtBeikgQ= X-Received: by 2002:a9d:513b:: with SMTP id c56-v6mr16673035oth.397.1528210012017; Tue, 05 Jun 2018 07:46:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 07:46:51 -0700 (PDT) In-Reply-To: <20180605123541.GB29047@server.ds9a.nl> References: <20180605123541.GB29047@server.ds9a.nl> From: Patrick McManus Date: Tue, 5 Jun 2018 16:46:51 +0200 X-Gmail-Original-Message-ID: Message-ID: To: bert hubert Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000e89a64056de61e8a" Archived-At: Subject: Re: [Doh] assorted things X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:46:56 -0000 --000000000000e89a64056de61e8a Content-Type: text/plain; charset="UTF-8" Hey Bert, On Tue, Jun 5, 2018 at 2:35 PM, bert hubert wrote: > > Does this say "don't just use any URI"? What are 'DNS resolution > privileges' every DoH exchange has a URI - if the URI isn't one your client is cool with - don't use it. e.g. when a DoH exchange arrives via push, check the URI as your first filter. > ? Is this about disallowing javascript to send out random DNS > queries? > > no >. Naive implementations may decide to not > follow 3xx codes. I would recommend making this explicit with a MUST. Also, > it may be worth it to explicitly say if authentication is in our out of > scope > That non-normative text is just there to remind the reader, who may not be that familiar with http, about the way http works. Specifically the group wanted to emphasize that DNS errors are only carried in successful HTTP responses, non-successful responses have HTTP semantics. This is a further reminder that we say non-successful rather than failed because some codes (like 3xx) can still be worked out successfully if the HTTP client wants to try harder with another request.. but that's all governed by HTTP, not DoH in particular. (And there are lots of these cases - so enumerating them rather than just relying on HTTP semantics is probably not the right thing.. a DoH implementation needs a full HTTP implementation - likely via library or other tool). > In 6.3 "Server Push": > For HTTP server push ([RFC7540] Section 8.2) extra care must be taken to > ensure that the pushed URI is one that the client would have directed > the > same query to if the client had initiated the request. > > This means an API server is free to send responses to DNS queries we > haven't > seen yet? And should a client do something with that? Or can it ignore > the > pushed records? > > it can ignore them if it likes. It can cache them if it likes. In practice it can even configure HTTP/2 to prevent or flow control them if it likes (its an http feature, and we don't enumerate every knob http provides or may evolve - we just stick to the semantics it provides). --000000000000e89a64056de61e8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Bert,

On Tue, Jun 5, 2018 at 2:35 PM, bert hubert <bert= .hubert@powerdns.com> wrote:
? Is this about= disallowing javascript to send out random DNS
queries?

no

=C2=A0>. Naive imp= lementations may decide to not
follow 3xx codes. I would recommend making this explicit with a MUST. Also,=
it may be worth it to explicitly say if authentication is in our out of
scope

That non-normative text is just t= here to remind the reader, who may not be that familiar with http, about th= e way http works. Specifically the group wanted to emphasize that DNS error= s are only carried in successful HTTP responses, non-successful responses h= ave HTTP semantics. This is a further reminder that we say non-successful r= ather than failed because some codes (like 3xx) can still be worked out suc= cessfully if the HTTP client wants to try harder with another request.. but= that's all governed by HTTP, not DoH in particular. (And there are lot= s of these cases - so enumerating them rather than just relying on HTTP sem= antics is probably not the right thing.. a DoH implementation needs a full = HTTP implementation - likely via library or other tool).

=
=C2=A0
In 6.3 "Server Push":
=C2=A0 =C2=A0For HTTP server push ([RFC7540] Section 8.2) extra care must b= e taken to
=C2=A0 =C2=A0ensure that the pushed URI is one that the client would have d= irected the
=C2=A0 =C2=A0same query to if the client had initiated the request.

This means an API server is free to send responses to DNS queries we haven&= #39;t
seen yet?=C2=A0 And should a client do something with that?=C2=A0 Or can it= ignore the
pushed records?


it can ignore them if it likes. It can= cache them if it likes. In practice it can even configure HTTP/2 to preven= t or flow control them if it likes (its an http feature, and we don't e= numerate every knob http provides or may evolve - we just stick to the sema= ntics it provides).


--000000000000e89a64056de61e8a-- From nobody Tue Jun 5 07:48:37 2018 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 9CBBF1310BC for ; Tue, 5 Jun 2018 07:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 zdBCd-MLSJp8 for ; Tue, 5 Jun 2018 07:48:33 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 5D9691310A2 for ; Tue, 5 Jun 2018 07:48:33 -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, 5 Jun 2018 07:48:31 -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, 5 Jun 2018 07:48:31 -0700 From: Paul Hoffman To: Tony Finch CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] a tad confused on response sizes Thread-Index: AQHT/Nf1Q8eIdA6YbUmlfXswbBzsLaRSNDGA Date: Tue, 5 Jun 2018 14:48:30 +0000 Message-ID: <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> References: <20180605120510.GA29047@server.ds9a.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_677AB471-185F-42E5-ABE5-B14CB9AF0819"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:48:35 -0000 --Apple-Mail=_677AB471-185F-42E5-ABE5-B14CB9AF0819 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 5, 2018, at 7:17 AM, Tony Finch wrote: >=20 > Paul Hoffman wrote: >> On Jun 5, 2018, at 5:05 AM, bert hubert = wrote: >>>=20 >>> A DNS API server is allowed to answer queries with any valid DNS >>> response. For example, a valid DNS response might have the TC >>> (truncation) bit set in the DNS header to indicate that the = server >>> was not able to retrieve a full answer for the query but is >>> providing the best answer it could get. A DNS API server can = reply >>> to queries with an HTTP error for queries that it cannot = fulfill. >>> In this same example, a DNS API server could use an HTTP error >>> instead of a non- error response that has the TC bit set. >>>=20 >>> This seems says sending a TC response is some kind of error >>=20 >> Not at all. The first sentence is quite explicit. >=20 > Thinking about this further, I think this is a bug, because a DoH = client > doesn't have any way to recover from TC. A non-DOH DNS client that can't get a TCP connection to the resolver = open can't recover either. Also note that the second sentence indicates = that the TC bit could indicate that the resolver itself couldn't get the = full response.=20 In both cases, the TC bit means "here's the best I got". 'Twas always = thus. --Paul Hoffman= --Apple-Mail=_677AB471-185F-42E5-ABE5-B14CB9AF0819 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCCBZUw ggR9oAMCAQICEAHlUc/Wu3bw9qj3vjSgnBAwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE1MDYyOTAwMDAwMFoXDTE4MDYyOTEy MDAwMFowgbQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMRUwEwYDVQQDEwxQYXVsIEhvZmZtYW4xJTAjBgkqhkiG9w0BCQEWFnBhdWwu aG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFp+z8d5Ge 3VPgAkNc47Br7C7lVgMGi3KPyzdtdsjKDFmk8G0b4YNv+pmv8TvISr4XRpHf/+u/+1n7wkKhjVjk rY32PWhXEzk5Vky2MGaS9DiNSGwmyY6FXXxwFR8/e9f/DNZy2UEeYFrHz/kIzf5cwwdfrNEPkds8 FNfftOzdg195KOGVbIyC2DmnA8R0VNN9Ymv8U9+uojD0uuQSxK2z0NspQZdjjthk9CgLtGTDqIsk Ji4AuAkwjCmff5aHlEY+G5GyHRuEpczLGqRIEbpLoRTFnLTrhrbshkxsYQM5pNwWTidtw9CWWEmd RX96sMvym3SdYGkhfFWlpgoF7/3nAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAdBgNVHQ4EFgQU9btKWvkJMHw27U3VEwvQ+VCtpqEwDAYDVR0TAQH/BAIwADAh BgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB1Zc/uexWtNIjStm4b/HN1W5/Hcl4eE58O lh+2JgLIsgY7Ten6HoOx/4LNFKPQlnCMdyy1XqkF9FDU/7O+a98B+++tWTvk3U7EBqKGe7XLw1oq w6ymSNZ/gn4L+Bh4Ka5I3RY15+tWxfAOiHkLFHGFvU7NA2Oqsue8tD5fZD/+UNNlQ5YVDiQCgkN1 miFgb6tkX6kLnuItIU1LSFi8etVL+5MN7NyuH2Y/Ta7h3p+JsIvdAGe2F1+9RiVMkHDSRgiS05qo TpdWBJ0hnX9B/0nSs+gXeZbGkO1KXS4+KC9dt+FriAhd5fHc/9g8qtbEkh2TdSZdfse7idXAG+UB tAx3MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/ vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG 2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9 CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh 7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAB5VHP1rt28Pao9740oJwQMAkGBSsOAwIaBQCg ggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYwNTE0NDgz MFowIwYJKoZIhvcNAQkEMRYEFCeE/Im110RSGykHy9w5K9N1g6u1MIGIBgkrBgEEAYI3EAQxezB5 MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2 qPe+NKCcEDCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2qPe+NKCcEDANBgkqhkiG9w0BAQEFAASCAQBAulJT uRAWeh4fmJuZIU8fRaA/MVILdAQLPVur8YbvcSfu2imezjOaFN3EQ102O/Zrv9QpPieY3ww5ehbH cBR5NrNu65tx1G1nRpqrLozoRBgsbA4Bwyn4i6FZH4DFQreJU8QioLpoXlSO9iQC/0nqoqXoO936 znnwBPgr1eXnQO/zVTB/gebr8JyKhPC3hBaZgPFeHKszZAB7hRcgTYTgIlppQRZ5nAUBZymOVuUr LhGNc6yVY9Eh8ZEwB62bo/83RxTJz1o8qxWd9sg9Ud2W8EZZ+ofrLLzGqh7ePWt36FOmQVeX/wt+ oV7PegNqZDjeSh+1xQI/q75zzR9ZH7CAAAAAAAAA --Apple-Mail=_677AB471-185F-42E5-ABE5-B14CB9AF0819-- From nobody Tue Jun 5 07:50:35 2018 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 CEA171310C1 for ; Tue, 5 Jun 2018 07:50:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=UqE7Q5fZ; dkim=pass (1024-bit key) header.d=yitter.info header.b=FgftagYL 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 b2KTl3NHH4E7 for ; Tue, 5 Jun 2018 07:50:32 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071031310BC for ; Tue, 5 Jun 2018 07:50:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 71A6CBDEF9 for ; Tue, 5 Jun 2018 14:50:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528210231; bh=CI1Q4PzJt3YMs7LFjG7Ml5gMFtZ9eOUq5EuUpAUpqlY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UqE7Q5fZyL+gvatEqiaG/LMGJHEIjHkciwuhFm0yFXZRXj8qjSHpP+AEURhcryoPZ 8+nbCNFalj/+rNujTq0llBY+va2FID4Gl5cqwr4ldo/4RJZNqed1b/obnEr8PqHAw7 HNcl+yhW6U7BbTJBBgtylQRpLZQaxV2S4nvz+osw= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrI8CO10dj05 for ; Tue, 5 Jun 2018 14:50:30 +0000 (UTC) Date: Tue, 5 Jun 2018 10:50:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528210230; bh=CI1Q4PzJt3YMs7LFjG7Ml5gMFtZ9eOUq5EuUpAUpqlY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=FgftagYLqnmUOwRkfnKROBnErB9MBi1awBzaPdmMiIZyYI5FQvTql/ySuqapwO+Rr 7f7KMQfXc0xnpuQTtphW4TyNDd2dMMJRLDDM4fBzMuUorCqH4iddZJLC3hb3alshTI Oxar0wpZJRd6s7KazvULoPotbNAFBebZUyKM1c7o= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180605145029.GI3011@mx4.yitter.info> References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:50:34 -0000 On Tue, Jun 05, 2018 at 02:48:30PM +0000, Paul Hoffman wrote: > In both cases, the TC bit means "here's the best I got". 'Twas always thus. Except that in DNS there's a clearly defined path for what to do next, whereas I am equally mystified what a DNS API client is supposed to do if it receives such a bit. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jun 5 08:07:47 2018 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 C7F3F1310D8 for ; Tue, 5 Jun 2018 08:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jEJQ_vwddyvT for ; Tue, 5 Jun 2018 08:07:44 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 D8EEC1310D3 for ; Tue, 5 Jun 2018 08:07:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35507) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQDYk-0005m0-hQ (Exim 4.91) (return-path ); Tue, 05 Jun 2018 16:07:42 +0100 Date: Tue, 5 Jun 2018 16:07:42 +0100 From: Tony Finch To: Paul Hoffman cc: "doh@ietf.org" In-Reply-To: <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:07:46 -0000 Paul Hoffman wrote: > On Jun 5, 2018, at 7:17 AM, Tony Finch wrote: > > > > Thinking about this further, I think this is a bug, because a DoH client > > doesn't have any way to recover from TC. > > A non-DOH DNS client that can't get a TCP connection to the resolver > open can't recover either. That's not a supported configuration - RFC 7766. > In both cases, the TC bit means "here's the best I got". 'Twas always thus. No, TC means "I have more to tell you but it wouldn't fit in your buffer". Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: East 4 or 5, decreasing 2 or 3. Moderate or rough, occasionally slight later. Mainly fair. Moderate or good. From nobody Tue Jun 5 08:13:46 2018 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 E73001310DF for ; Tue, 5 Jun 2018 08:13:43 -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 RkEPK-rmNkOj for ; Tue, 5 Jun 2018 08:13:39 -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 84BEF131104 for ; Tue, 5 Jun 2018 08:13:39 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D27FC2800F3; Tue, 5 Jun 2018 17:13:36 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id CCB592806CC; Tue, 5 Jun 2018 17:13:36 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id C52BC2800F3; Tue, 5 Jun 2018 17:13:36 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C22AA6424E40; Tue, 5 Jun 2018 17:13:36 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id B2481401BD; Tue, 5 Jun 2018 17:13:36 +0200 (CEST) Date: Tue, 5 Jun 2018 17:13:36 +0200 From: Stephane Bortzmeyer To: Andrew Sullivan Cc: doh@ietf.org Message-ID: <20180605151336.3rgte7rbnghvnekq@nic.fr> References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605145029.GI3011@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180605145029.GI3011@mx4.yitter.info> X-Operating-System: Debian GNU/Linux 9.4 X-Kernel: Linux 4.9.0-6-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.000009, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.6.5.150316 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:13:45 -0000 On Tue, Jun 05, 2018 at 10:50:29AM -0400, Andrew Sullivan wrote a message of 17 lines which said: > Except that in DNS there's a clearly defined path for what to do > next, Clearly defined, but certainly not implemented everywhere. Many resolvers cannot retry over TCP. (At this time, 'DNSKEY renater.fr' cannot be retrieved with a typical EDNS buffer size. Try it.) > whereas I am equally mystified what a DNS API client is supposed to > do if it receives such a bit. The way I understand it, it is a local decision by the client. Give in for this data, or choose a better DoH server. I think that a DoH server returning truncated answers is legal (RFC-compliant) but bad and, as a client, I would prefer to switch to another one. Practically speaking, for the RFC, what do you suggest? Forbidding TC? Then, what would the client do if it still receives one? (The point of DoH is to use DNS wire format, so a client has to be ready for anything which is legal DNS.) From nobody Tue Jun 5 08:24:06 2018 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 A842C13111A for ; Tue, 5 Jun 2018 08:23:58 -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 1WKIiNuLM2Mu for ; Tue, 5 Jun 2018 08:23:57 -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 3DACE13112E for ; Tue, 5 Jun 2018 08:23:57 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id B2D102806C8; Tue, 5 Jun 2018 17:23:55 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id ACB142806D1; Tue, 5 Jun 2018 17:23:55 +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 A59912806CC; Tue, 5 Jun 2018 17:23:55 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id A28BF6427BE0; Tue, 5 Jun 2018 17:23:55 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 97107401BD; Tue, 5 Jun 2018 17:23:55 +0200 (CEST) Date: Tue, 5 Jun 2018 17:23:55 +0200 From: Stephane Bortzmeyer To: Tony Finch Cc: Paul Hoffman , "doh@ietf.org" Message-ID: <20180605152355.6tlbeqvt7luklwjl@nic.fr> References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.4 X-Kernel: Linux 4.9.0-6-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.000007, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.6.5.151516 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 15:24:05 -0000 On Tue, Jun 05, 2018 at 04:07:42PM +0100, Tony Finch wrote a message of 25 lines which said: > No, TC means "I have more to tell you but it wouldn't fit in your buffer". TC is supposed to be hop-to-hop but DoH makes things more complicated, the HTTPS link having different semantics. For DoH, it means (I quote the -10 draft) "I was not able to retrieve a full answer for the query but I give you the best answer I could get" PS : what happens when a DNS-over-TCP client receives a truncated answer over TCP? It is technically possible and nobody expects RFC 7766 to address this point. From nobody Tue Jun 5 09:17:09 2018 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 2CB1313110A for ; Tue, 5 Jun 2018 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 szTdN5CFTtdB for ; Tue, 5 Jun 2018 09:17:03 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 EDA2C131100 for ; Tue, 5 Jun 2018 09:17:02 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35097) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQEdo-000TFO-MR (Exim 4.91) (return-path ); Tue, 05 Jun 2018 17:17:00 +0100 Date: Tue, 5 Jun 2018 17:17:00 +0100 From: Tony Finch To: Stephane Bortzmeyer cc: Paul Hoffman , "doh@ietf.org" In-Reply-To: <20180605152355.6tlbeqvt7luklwjl@nic.fr> Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 16:17:08 -0000 Stephane Bortzmeyer wrote: > > TC is supposed to be hop-to-hop but DoH makes things more complicated, > the HTTPS link having different semantics. For DoH, it means (I quote > the -10 draft) "I was not able to retrieve a full answer for the query > but I give you the best answer I could get" That is not consistent with RFC 1035: TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. Since https's permitted length is longer than a DNS message, it is invalid for a DoH server to truncate. > PS : what happens when a DNS-over-TCP client receives a truncated > answer over TCP? RFC 1035 doesn't allow TC for TCP messages. Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth: Northeast 4 or 5, becoming variable 3 or 4. Mainly slight. Thundery showers in south. Moderate or good, occasionally poor at first. From nobody Tue Jun 5 09:43:03 2018 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 6D21B13110C for ; Tue, 5 Jun 2018 09:43:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=ihYP9V+n; dkim=pass (1024-bit key) header.d=yitter.info header.b=UQuBbUUl 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 XqP8VsoChXdK for ; Tue, 5 Jun 2018 09:43:00 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31043126CB6 for ; Tue, 5 Jun 2018 09:43:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 96E4BBDEF9 for ; Tue, 5 Jun 2018 16:42:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528216949; bh=/Uz/dbjn+tm+WUKkXC2VYEfRnBjbQdkxu6PwRASTWHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ihYP9V+n1QM7zNYmFsVFFUKxKBFddJ/9QxTl70+hd8pvY36gnlYxgodYM3qBoHMPb xmIsIFevVVw/c31A74MBuFZ4y+gKM7XoasRL9aeI01SyZ6KYwOWggZMlreKCAY0bY+ knzwiSNEZKOU7KeVnIyCM0H/fhNe9WiPPi2MYiLY= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0nbdP6Rz2Eb for ; Tue, 5 Jun 2018 16:42:28 +0000 (UTC) Date: Tue, 5 Jun 2018 12:42:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528216948; bh=/Uz/dbjn+tm+WUKkXC2VYEfRnBjbQdkxu6PwRASTWHQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UQuBbUUlAJYCfrgISxBkZ4lrdhwUA2CRKNrXZvho6eL2dJb7fG8fTbdqqFemlBKw2 vX3DffiIzC/yeG+KMAAASSBy4nQuxNfVCyaFBCdn8rl+DYCCViUzZEruZYvDOHdBLE zjmRysKMvpjEpKMvoSsR9mpIWOdL3KggNuSzHAwA= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180605164226.GN3011@mx4.yitter.info> References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605145029.GI3011@mx4.yitter.info> <20180605151336.3rgte7rbnghvnekq@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180605151336.3rgte7rbnghvnekq@nic.fr> Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 16:43:02 -0000 On Tue, Jun 05, 2018 at 05:13:36PM +0200, Stephane Bortzmeyer wrote: > Clearly defined, but certainly not implemented > everywhere. Many resolvers cannot retry over TCP. Oh, for sure. But I'm not trying to fault any document for developers not implementing things :) I'm just worried that this document doesn't actually tell anyone what to do if they get such a bit, or if it does I don't understand it. (This could well be a failing in me, please let me emphasise.) > Practically speaking, for the RFC, what do you suggest? Forbidding TC? > Then, what would the client do if it still receives one? (The point of > DoH is to use DNS wire format, so a client has to be ready for > anything which is legal DNS.) I wonder whether the TC should be an indicator that the upstream resolution process got a truncated response and was unable to fetch a response that was not truncated. In such a case, the DNS API client can do whatever it would do in such cases otherwise. (Some resolvers in that case throw some kind of error, whereas others will happily give you the truncated response and let you attempt to go ahead even if you may well have poison, &c &c.) I guess I don't have strong feelings about the right answer, but I want the handling to be clear. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jun 5 09:44:04 2018 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 3152C126CB6 for ; Tue, 5 Jun 2018 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=hotmail.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 vit5cljSzljX for ; Tue, 5 Jun 2018 09:44:01 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-oln040092008035.outbound.protection.outlook.com [40.92.8.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FA912D949 for ; Tue, 5 Jun 2018 09:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ogFJ76F0xm1r1u6ZSLV27UbPmUwHQ/QDeMoQSY4EbY=; b=QH+OIwYI0K6B+jgmVhHSm+Pd+Gr2SlZ792Vcm6dwig0a0oxbtpzazE1l2uP92qwFFVaauHYFWTQUMLMAe/+EeoWfvYuFQqGMM6pyfN0RfRAwsPxuL/xhgDC3d7ZtuWxA+3AY8c5WDpeHIWC+Z4YHLSdzz0sjPEPQBHlJfl6faGhjcgBjhKOB9ijCI/mK1jvrmGetcK7hCBS2p/Z9ZZsHs0+ViTI/Q1DRSp3fjSWs6aSQxqGw0CmCoe0PWsdNDEbhzc00sj0FUfwd+OzY6ypmycDDgju1o9V600hyNwG2cM4s/SP5vJhDPMOke4esopjr2NebxHOPL8Gf29dPuhw6yA== Received: from DM3NAM03FT007.eop-NAM03.prod.protection.outlook.com (10.152.82.56) by DM3NAM03HT186.eop-NAM03.prod.protection.outlook.com (10.152.83.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.755.15; Tue, 5 Jun 2018 16:43:59 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.82.59) by DM3NAM03FT007.mail.protection.outlook.com (10.152.82.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10 via Frontend Transport; Tue, 5 Jun 2018 16:43:59 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb%4]) with mapi id 15.20.0820.015; Tue, 5 Jun 2018 16:43:59 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] [Ext] a tad confused on response sizes Thread-Index: AQHT/NdXdt//5ho9S02KYza5xDwOp6RRtiwAgAAIrgCAAAVeAIAABIeAgAAO1QCAAAOGWA== Date: Tue, 5 Jun 2018 16:43:59 +0000 Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:3DD783BB72AC6211D51E9B3F533601222AC0F053D57A172996B18D01D39555FB; UpperCasedChecksum:1DD7F15C34037186FCE7870F43CB050FA523199F01C70DE264CD5930AEB3B3D8; SizeAsReceived:7422; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [e6yGR1CoqOPZZqhCpDg39E/Fj2WHAMsnhM8+3ZrcMoi7IcACP7tm8g==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3NAM03HT186; 7:U7BKNy/5gLpIQh/WQaRua9ZPHM01htkqiInbvjwFZPwM/weURl4hchrvPOtz9S7QhxADsCoENMbCyx6C6Vgpp7bDursoC86XyCKgAVjhGmMB7eoj6rILQX00REcd3IAUy4UeM8EaaisD6AViM5Ic0dgKFPO/i2UbHFI15qQJ1vgQhx4nurSd8DHUC0xTrwlDEP3gMzNpkGJurIIq8ssEs9RolYRMq8JvjQT7ropHMpEsHTzz8FDvxNdqSBUCC/gL x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:DM3NAM03HT186; x-ms-traffictypediagnostic: DM3NAM03HT186: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DM3NAM03HT186; BCL:0; PCL:0; RULEID:; SRVR:DM3NAM03HT186; x-forefront-prvs: 0694C54398 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(6916009)(5640700003)(9686003)(73972006)(33656002)(6246003)(106356001)(55016002)(105586002)(305945005)(5660300001)(74316002)(25786009)(82202002)(97736004)(8936002)(81156014)(14454004)(486006)(104016004)(83332001)(6506007)(46003)(87572001)(93886005)(476003)(20460500001)(1730700003)(3280700002)(11346002)(2900100001)(5250100002)(8676002)(86362001)(7696005)(3660700001)(229853002)(102836004)(6346003)(99286004)(76176011)(68736007)(2501003)(6436002)(446003)(2351001)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM03HT186; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: PIOPkeQ0Eor1qsUGFyPDffKJ0JRNrN5BIINF/EeazdWUeg8z85kR3AYYNxjKXIo1hdT7AwawFGJ1Imyht59VOt4AbfFI1aTDqOWWjLTlKkW5acS+mNBPGqL5ZvbKEZy+iQ+R+3AORn8kg20HOWYL8Rn1hQBNY2oZTks5uW9Fk3DqYaJ22VaYDuINrCe+rs1N Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 7454a594-6e41-4455-d3fc-08d5cb038997 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: 7454a594-6e41-4455-d3fc-08d5cb038997 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 16:43:59.6132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT186 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 16:44:02 -0000 Tony Finch wrote: > Since https's permitted length is longer than a DNS message, > it is invalid for a DoH server to truncate. No, DoH server never truncates messages. It is the upstream server that truncates the message. > RFC 1035 doesn't allow TC for TCP messages. The fact is that there are TCP servers that do truncates messages. There are also servers that firewalls TCP by mistake so only UDP could pass= . Some of them are even authoritative server that you have no other ways to b= ypass. So here is the question: what should you do if you received a TC from a TCP= upstream? I run massive deployment of DoH server, and I see this kind of packets quit= e often. Yes, we know it is not RFC1035-compliant. But what can a DoH server do with= this kind of malformed packet? 1) Ignore the TC bit and return the truncated answer to DoH client? 2) Take the TC bit and return the truncated answer to DoH client? 3) Return SERVFAIL and persuade users to give up your DoH service? 4) Return HTTP 500 / 502 / 503 to mislead users that your server crashed? 5) Throw a Segfault with a pretty-printed stacktrace in your syslog? You could do nothing but keep the TC bit. That is why DoH allows TC bit. TL;DR: It's not the DoH server that truncates. It's somebody else truncates= and DoH could do nothing (even with TCP) to fix it.= From nobody Tue Jun 5 10:14:42 2018 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 F3C98131117 for ; Tue, 5 Jun 2018 10:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YihWumk5GUyT for ; Tue, 5 Jun 2018 10:14:38 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 A80B71277C8 for ; Tue, 5 Jun 2018 10:14:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38668) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQFXY-0007uV-M2 (Exim 4.91) (return-path ); Tue, 05 Jun 2018 18:14:36 +0100 Date: Tue, 5 Jun 2018 18:14:36 +0100 From: Tony Finch To: Star Brilliant cc: "doh@ietf.org" In-Reply-To: Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr>, User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:14:40 -0000 Star Brilliant wrote: > Tony Finch wrote: > > Since https's permitted length is longer than a DNS message, > > it is invalid for a DoH server to truncate. > > No, DoH server never truncates messages. > It is the upstream server that truncates the message. If a DoH server talks to an upstream resolver over a truncating transport, the DoH server has to retry over a non-truncating transport. > The fact is that there are TCP servers that do truncates messages. > There are also servers that firewalls TCP by mistake so only UDP could pass. > Some of them are even authoritative server that you have no other ways to bypass. They are all broken and don't implement the protocol correctly. > Yes, we know it is not RFC1035-compliant. But what can a DoH server do > with this kind of malformed packet? > > 1) Ignore the TC bit and return the truncated answer to DoH client? > 2) Take the TC bit and return the truncated answer to DoH client? > 3) Return SERVFAIL and persuade users to give up your DoH service? I think those are all reasonable. My DoH server just returns its upstream's header verbatim. Its upstream resolver is responsible for correct DNS semantics. > You could do nothing but keep the TC bit. That is why DoH allows TC bit. The point of this discussion is what the client is supposed to understand by TC in a response. RFC 1035 implies that (over TCP) TC must not be set by a server and must be ignored by a client. DoH should be the same. Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: Cyclonic 3 or 4. Slight. Thundery showers. Good, occasionally poor. From nobody Tue Jun 5 10:23:30 2018 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 15AE91271FF for ; Tue, 5 Jun 2018 10:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 aCL4UOo_wJIA for ; Tue, 5 Jun 2018 10:23:27 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 38735124D68 for ; Tue, 5 Jun 2018 10:23:27 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Jun 2018 10:23:24 -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, 5 Jun 2018 10:23:25 -0700 From: Paul Hoffman To: Tony Finch CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] a tad confused on response sizes Thread-Index: AQHT/Nf1Q8eIdA6YbUmlfXswbBzsLaRSNDGAgAAFXgCAAASIgIAADtUAgAAHioCAAAiOAIAAAnUA Date: Tue, 5 Jun 2018 17:23:24 +0000 Message-ID: <61406BA8-2C05-4BBC-8F88-92C21A23D294@icann.org> References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> In-Reply-To: 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: <4BF0048E6ED28A4A8C4842000E931F53@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:23:28 -0000 On Jun 5, 2018, at 10:14 AM, Tony Finch wrote: > RFC 1035 implies that (over TCP) TC must not be set > by a server and must be ignored by a client. I don't see that implication in RFC 1035. --Paul Hoffman From nobody Tue Jun 5 10:46:45 2018 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 9B591131119 for ; Tue, 5 Jun 2018 10:46:43 -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 Xtzn8KYhwj70 for ; Tue, 5 Jun 2018 10:46:41 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87655131123 for ; Tue, 5 Jun 2018 10:46:41 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 8C12F23891; Tue, 5 Jun 2018 13:46:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23318.52352.556862.424875@gro.dd.org> Date: Tue, 5 Jun 2018 13:46:40 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:46:44 -0000 Tony Finch writes: > RFC 1035 doesn't allow TC for TCP messages. It doesn't? By inference do you mean, only because it got mentioned in section 4.2.1, UDP usage, and not in 4.2.2, TCP usage? It's a bit stronger statement to make that it isn't allowed, especially since what you quoted from 4.1.1 is transport agnostic: | TC TrunCation - specifies that this message was truncated | due to length greater than that permitted on the | transmission channel. From nobody Tue Jun 5 10:49:57 2018 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 030A4131123 for ; Tue, 5 Jun 2018 10:49:56 -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 qEqh5jnQ2nfa for ; Tue, 5 Jun 2018 10:49:54 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC298131119 for ; Tue, 5 Jun 2018 10:49:54 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 16B4823895; Tue, 5 Jun 2018 13:49:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23318.52546.69002.683919@gro.dd.org> Date: Tue, 5 Jun 2018 13:49:54 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:49:56 -0000 Tony Finch writes: > The point of this discussion is what the client is supposed to understand > by TC in a response. RFC 1035 implies that (over TCP) TC must not be set > by a server and must be ignored by a client. DoH should be the same. I do not read that implication at all. What I would understand as an implementer if I got TC on any channel is that the message is missing information it should otherwise have had. Whether it has enough other information to me to find useful is a separate matter, but it is still providing useful signal that the message is incomplete. From nobody Tue Jun 5 10:50:25 2018 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 CC32513113B for ; Tue, 5 Jun 2018 10:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=hotmail.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 MZGg9kZScunu for ; Tue, 5 Jun 2018 10:50:14 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-oln040092012045.outbound.protection.outlook.com [40.92.12.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53000131154 for ; Tue, 5 Jun 2018 10:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2OnVDyRiw15zjVmt5dTV3MDCYHKsFpp1H36WUPYUuMM=; b=RX8Y7fFhz3S+TH/baIkLtiQBsygslO0NFoiK6BzT4TZswNRBlWQX+k5iR07G11jFdibCbXAHftaDQo8zMsH3Tzmb04egAMcD/BYbosN1ZWZOmMeFWVpzF8Y7hDBkdAizti8/t37lKKNUsgY2pY9KaT/JNeVutGnAgmH38JyjRf8bl6eAjmH63WHdaoOWKw9Xji34Re+YT32nBCIJlP2lopE9nBTqyS2GcQLr93F3hCTOloVbqevRF0dPh4e8nHmB39sK4e0aKEb+/PYHOGWJlA0YvEPZdd+2xNqeTogdAWKHmDO4S6VM7nfBsL8uM+icM7wJXBAaAM98PNLv6jhpgg== Received: from BY2NAM05FT013.eop-nam05.prod.protection.outlook.com (10.152.100.51) by BY2NAM05HT175.eop-nam05.prod.protection.outlook.com (10.152.101.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.841.6; Tue, 5 Jun 2018 17:50:13 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.100.58) by BY2NAM05FT013.mail.protection.outlook.com (10.152.100.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.841.6 via Frontend Transport; Tue, 5 Jun 2018 17:50:13 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb%4]) with mapi id 15.20.0820.015; Tue, 5 Jun 2018 17:50:13 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] [Ext] a tad confused on response sizes Thread-Index: AQHT/NdXdt//5ho9S02KYza5xDwOp6RRtiwAgAAIrgCAAAVeAIAABIeAgAAO1QCAAAOGWIAADJIAgAAEt60= Date: Tue, 5 Jun 2018 17:50:13 +0000 Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:6A4992ED13DF1C49BB7E50F505FEE7897B729E1C30226E4601088CBFFBB0BE57; UpperCasedChecksum:B0884EBED9D95ED1722D443954C4C26C6AEA6E7719F738E89006B035291194BA; SizeAsReceived:7586; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [0IWTit2HrVuz7hhGzNiKDQdGrpQrao2M2AmrRi5UySvHG5SiUfXjDQ==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM05HT175; 7:EwHnV3pzNrbUynV7Y4DhaczpAwB6Qliq+4E9Gvp5p7+aKfNnk9VVpczdsPgYo+oH50msY+JCsf/55DTXB5nA9DyjtLITL9ekuvowl/bPfMR5WY2irhraL3V7mOIW9pLuePctAbV6UP86EmvB4+FBjwdmEGm6y/2ae1UMat+WWpMMfajwSg3ORVCL3C3B98OUMoHOLUMM4bDWSi4VVb4xHVr06PM8sBx1P6tYg7YD5FpSzexdXWlvW5yjEMPA9O55 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:BY2NAM05HT175; x-ms-traffictypediagnostic: BY2NAM05HT175: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM05HT175; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM05HT175; x-forefront-prvs: 0694C54398 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(52314003)(199004)(189003)(106356001)(20460500001)(486006)(2351001)(105586002)(73972006)(81156014)(8676002)(104016004)(1730700003)(3280700002)(3660700001)(8936002)(55016002)(102836004)(76176011)(6346003)(68736007)(93886005)(14454004)(6506007)(46003)(59450400001)(11346002)(446003)(2501003)(74316002)(305945005)(7696005)(6436002)(99286004)(5250100002)(5640700003)(2900100001)(97736004)(229853002)(82202002)(5660300001)(6916009)(6246003)(87572001)(9686003)(25786009)(86362001)(476003)(83332001)(33656002)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM05HT175; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: Ivjige+5Dt5AcCP6Xmkh7NjnrmkDoj7lgvQzSZDHojxd+mw8amueFZ24Fls/HFCyuQgxEWSSbtxCwJiXQ+rIQI0EnmhMiTxBiVTLrqU0sg0kRtpciMGDPBM5RntwQNqSB3b84du23J2hZQbezmilHqkBM2IpMLdTF0bX60Jm8MccuBpIcAuO1edPFQ2OvRLv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 17a0616b-385e-4c00-1ae6-08d5cb0cca2c X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: 17a0616b-385e-4c00-1ae6-08d5cb0cca2c X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 17:50:13.4267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM05HT175 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:50:22 -0000 Tony Finch wrote: > If a DoH server talks to an upstream resolver over a truncating transport= , > the DoH server has to retry over a non-truncating transport. I agree. But obviously you did not read my message well. A DoH server should retry over TCP. I am only talking about the last resort, when TCP does not work or still re= turned TC. > They are all broken and don't implement the protocol correctly. As we know, the browser that can render broken HTML tag soup wins the battl= e. That's the same with DNS. If you are not compatible with broken implementat= ions, users will not use your product. Our code don't produce garbage, but we need to consume garbage produced by = others, right? So please don't make excuses for your writing less compatibility code (in c= ase if so). > The point of this discussion is what the client is supposed to understand > by TC in a response. RFC 1035 implies that (over TCP) TC must not be set > by a server and must be ignored by a client. DoH should be the same. The DoH client does not need to understand the TC bit. It just pass the TC = bit to downstream. Let me explain how this work: When the downstream finds the TC bit, it should retry with TCP to the DoH c= lient. And the DoH client should return the exactly same answer with TC. The downstream should stop retrying with the second TC (since there are no = more methods to retry). I think it makes sense. > My trivial DoH code makes upstream queries over TCP, so the EDNS buffer > size is ignored. Just a friendly warning: I have done this thing in my productive server, and soon get banned by some= authoritative servers. Most authoritative servers on the Internet are really really fragile. Anyway, it's okay to use full TCP, if you don't do recursion yourself. And in case if I misunderstood... Could we make this discussion less gunpow= der-smelly and more kind?= From nobody Tue Jun 5 11:02:46 2018 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 06418126F72 for ; Tue, 5 Jun 2018 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VomSOVXkMT_s for ; Tue, 5 Jun 2018 11:02:42 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 64C2C128CF3 for ; Tue, 5 Jun 2018 11:02:42 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:34818) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQGI4-000Mp9-0t (Exim 4.91) (return-path ); Tue, 05 Jun 2018 19:02:40 +0100 Date: Tue, 5 Jun 2018 19:02:40 +0100 From: Tony Finch To: Paul Hoffman cc: "doh@ietf.org" In-Reply-To: <61406BA8-2C05-4BBC-8F88-92C21A23D294@icann.org> Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> <61406BA8-2C05-4BBC-8F88-92C21A23D294@icann.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:02:45 -0000 Paul Hoffman wrote: > On Jun 5, 2018, at 10:14 AM, Tony Finch wrote: > > RFC 1035 implies that (over TCP) TC must not be set > > by a server and must be ignored by a client. > > I don't see that implication in RFC 1035. On the server side, RFC 1035 does not say that the TC bit is for TCP transports, therefore it is left clear. On the client side, TC only has a defined meaning for UDP. Tony. -- f.anthony.n.finch http://dotat.at/ Fitzroy, Sole: Northerly 4 or 5, becoming variable 3 or 4, then southerly 4 or 5 later in west. Slight or moderate. Showers at first, rain later in west. Good, occasionally poor. From nobody Tue Jun 5 11:12:38 2018 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 F202C12F1AC for ; Tue, 5 Jun 2018 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xNGmKKSKVb1Q for ; Tue, 5 Jun 2018 11:12:32 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 BA4AE126F72 for ; Tue, 5 Jun 2018 11:12:32 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35069) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQGRb-000Zgf-1U (Exim 4.91) (return-path ); Tue, 05 Jun 2018 19:12:31 +0100 Date: Tue, 5 Jun 2018 19:12:31 +0100 From: Tony Finch To: Star Brilliant cc: "doh@ietf.org" In-Reply-To: Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr>, , User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:12:37 -0000 Star Brilliant wrote: > > The DoH client does not need to understand the TC bit. It just pass the TC bit to downstream. > Let me explain how this work: > > When the downstream finds the TC bit, it should retry with TCP to the DoH client. > And the DoH client should return the exactly same answer with TC. > The downstream should stop retrying with the second TC (since there are no more methods to retry). I'm afraid I don't understand that at all. In many cases, the DoH client will be embedded in an application as an alternative to a traditional stub resolver, so it doesn't have a downstream that can retry. > > My trivial DoH code makes upstream queries over TCP, so the EDNS buffer > > size is ignored. > > Just a friendly warning: > I have done this thing in my productive server, and soon get banned by > some authoritative servers. My DoH server is a proxy that talks to a full-service resolver that I control. Tony. -- f.anthony.n.finch http://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression From nobody Tue Jun 5 11:28:26 2018 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 D37B11310F3 for ; Tue, 5 Jun 2018 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=hotmail.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 qVBg9nTpsGxj for ; Tue, 5 Jun 2018 11:28:22 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001089.outbound.protection.outlook.com [40.92.1.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFFE130934 for ; Tue, 5 Jun 2018 11:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IzGj5ejnz/j0TFRKqaV/CTfjkXB0SPdlPtK940HnBa8=; b=jed/KIc6U//G0/cjFWAOZp6zTXYW8I66Rex//C/1yIg/A5rvh0LHD6B0DHy6bX4oB5scgu2Ze2vm2UV3wHeRFWbuPi7iXCqWgXtdQWxD5x8LmGHNbq0Vd9llba8bvVokZsDYGN2794kziQ8n4MHwuHF1XZVP6wbsjhw5QFATkd3QeKMqY9nhwUO0wO/TVmAKh/VgvZIK5G1IlIPib8PhnVLK0Lbvu9oMurfhKyBuaWiaj+nV9WNYZWxK34uf9asuFMR59ndJsRJDNBdZEdBiEe6Cpf8/oxs+KpDdx/3G49ILZzr75cnNwxHs8Vz0tGRex234QR+31c5RKZS+0gAEaQ== Received: from BY2NAM01FT039.eop-nam01.prod.protection.outlook.com (10.152.68.54) by BY2NAM01HT157.eop-nam01.prod.protection.outlook.com (10.152.68.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10; Tue, 5 Jun 2018 18:28:21 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.68.53) by BY2NAM01FT039.mail.protection.outlook.com (10.152.68.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.841.10 via Frontend Transport; Tue, 5 Jun 2018 18:28:21 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb%4]) with mapi id 15.20.0820.015; Tue, 5 Jun 2018 18:28:21 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] [Ext] a tad confused on response sizes Thread-Index: AQHT/NdXdt//5ho9S02KYza5xDwOp6RRtiwAgAAIrgCAAAVeAIAABIeAgAAO1QCAAAOGWIAADJIAgAAEt62AAAt4gIAAAOwY Date: Tue, 5 Jun 2018 18:28:21 +0000 Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr>, , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:D43E0B5178C79F8269A2AF98D371B3DA10CE3DC740B4FBC145D1762554E54D2E; UpperCasedChecksum:6E0B4FAD7218478BC128EBED546E3F7D657463C7A4F528A25DF186535EE45E4A; SizeAsReceived:7738; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [oqW3dR3HNOjbypihdq23o/INEq+hHNd5U6xfGJBCSeGJZKg9EdvDcg==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM01HT157; 7:M2eaDWiWPSB3OLIeK3GX39OSXmaho+2HxaZQP9hpwxf4XGsj338fF/oHarMi+bgtozEJqyYsGbKzzI6wFuuILarTZ2Wp2RraQhlw4NnK8mZsYw20SgPiuYRV+Z8qP5lLF97XtN4DDfuatYYWU+nf8hLFx2gfVqTEV7d4n68entzLlfeNVAgrfWO7iphtbKYVK6Nj8bl9jFp+X6kO81TmUnTObp5HmafkZA2rCliqtyvzs+oZ670U1KOv4gQi8TE8 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125466)(1701031045); SRVR:BY2NAM01HT157; x-ms-traffictypediagnostic: BY2NAM01HT157: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM01HT157; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM01HT157; x-forefront-prvs: 0694C54398 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(7696005)(229853002)(87572001)(99286004)(20460500001)(6506007)(2900100001)(104016004)(33656002)(6346003)(102836004)(82202002)(76176011)(73972006)(5660300001)(3660700001)(3280700002)(2501003)(446003)(11346002)(5250100002)(83332001)(6246003)(8936002)(97736004)(25786009)(6916009)(106356001)(2351001)(93886005)(105586002)(68736007)(5640700003)(86362001)(6436002)(8676002)(305945005)(46003)(486006)(14454004)(74316002)(81156014)(476003)(1730700003)(9686003)(55016002)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM01HT157; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: 9Pv5jkWIsPRKdRglijjFRoAKg5h84ino13onZGtJMbhqpNUK/jlsUYvZelm/rtzSXenIXJOEzEJzXdSXomjqZo7EqV9BmPtzqPd3NgP6jbp70usWCh7Ol3Vy+vZ7hb4DYfzeD+NI8I8s30f7gEwtQuUk9mBcDJAPpoCQ/x1phfyNDdidYpsTs8Ycd9fMq11e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ef77a330-b1c4-4e42-bc2b-08d5cb121de3 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: ef77a330-b1c4-4e42-bc2b-08d5cb121de3 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 18:28:21.3426 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT157 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 18:28:24 -0000 Tony Finch wrote: > In many cases, the DoH client will be embedded in an application as an > alternative to a traditional stub resolver, so it doesn't have a > downstream that can retry. I think the problem is simpler when you state your application scenario. In my opinion (other people may disagree with me), you could just treat a D= oH response with TC as a resolve error and give the user a "network error" = screen. In other words, a DoH with TC bit can happen, and that's a common error. (N= ot as common as an unplugged network cable, but actually happens really fre= quently on a busy recursion server.) And TC bit needed to be passed all along the way through bouncers/proxies/S= LBs to the user's application, because errors should not "silently fail". > My DoH server is a proxy that talks to a full-service resolver that I > control. That's good to know. Thanks.= From nobody Tue Jun 5 13:26:23 2018 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 C87F013115C for ; Tue, 5 Jun 2018 13:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 y20FpebaJoYa for ; Tue, 5 Jun 2018 13:26:18 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 1718D131154 for ; Tue, 5 Jun 2018 13:26:18 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:56238) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQIX1-000URM-eD (Exim 4.91) (return-path ); Tue, 05 Jun 2018 21:26:15 +0100 Date: Tue, 5 Jun 2018 21:26:14 +0100 From: Tony Finch To: Star Brilliant cc: "doh@ietf.org" In-Reply-To: Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr>, , , User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 20:26:21 -0000 Star Brilliant wrote: > > In other words, a DoH with TC bit can happen, and that's a common error. > (Not as common as an unplugged network cable, but actually happens > really frequently on a busy recursion server.) I would be interested to know of a query that produces a TC response over TCP. Tony. -- f.anthony.n.finch http://dotat.at/ Southeast Iceland: Variable 3 or 4. Slight. Fair. Good, occasionally poor in north. From nobody Tue Jun 5 15:10:38 2018 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 119B8130DEC for ; Tue, 5 Jun 2018 15:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 Zr8F7y7u1oLB for ; Tue, 5 Jun 2018 15:10:36 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 34DA5130DEB for ; Tue, 5 Jun 2018 15:10:36 -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, 5 Jun 2018 15:10:34 -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, 5 Jun 2018 15:10:34 -0700 From: Paul Hoffman To: Tony Finch CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] a tad confused on response sizes Thread-Index: AQHT/Nf1Q8eIdA6YbUmlfXswbBzsLaRSNDGAgAAFXgCAAASIgIAADtUAgAAHioCAAAiOAIAACfOAgAAGO4CAAARtgIAAIO8AgAAdJAA= Date: Tue, 5 Jun 2018 22:10:33 +0000 Message-ID: <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> In-Reply-To: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 22:10:37 -0000 On Jun 5, 2018, at 1:26 PM, Tony Finch wrote: >=20 > Star Brilliant wrote: >>=20 >> In other words, a DoH with TC bit can happen, and that's a common error. >> (Not as common as an unplugged network cable, but actually happens >> really frequently on a busy recursion server.) >=20 > I would be interested to know of a query that produces a TC response over > TCP. Resolver 1 sends a query to a Resolver 2 (who allows forwarding) over TCP. = Resolver 2 asks an authoritative, gets a response with TC bit set on, trie= s on TCP, and gets a failure on TCP. Resolver 2 should send the partial ans= wer it got over UDP to Resolver 1. That answer to Resolver 1 should have th= e TC bit set on, or not, depending on what you think that RFC 1035 "implies= ". --Paul Hoffman From nobody Tue Jun 5 15:24:23 2018 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 1262F130DF9 for ; Tue, 5 Jun 2018 15:24:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=ca5bAWiu; dkim=pass (1024-bit key) header.d=yitter.info header.b=W5AX0mVf 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 W_suYSmVti26 for ; Tue, 5 Jun 2018 15:24:20 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D90B130DE2 for ; Tue, 5 Jun 2018 15:24:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 247E0BDEF9 for ; Tue, 5 Jun 2018 22:24:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528237459; bh=aJe9m1im4goKs8PTTCPhoZGNoq316ZiqapED564zqKU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ca5bAWiu9OZZi+3JzBGHz8mGyJDgoa8psEJ3gtlbZGP2Tcg7XnU9EV1C4gD7T6ZIN fOLfbHNamuj7/YnL3c7tu/FIvM1txqS0gfqMFz8rRuvUXMSJ67O7NqaX2c8tdEPGBk eFA0HXuoeEEsArubdWRqAwZiMG7SnvEyG+NWGezk= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPpCbMIwU0bJ for ; Tue, 5 Jun 2018 22:24:17 +0000 (UTC) Date: Tue, 5 Jun 2018 18:24:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528237457; bh=aJe9m1im4goKs8PTTCPhoZGNoq316ZiqapED564zqKU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=W5AX0mVfk17BAMLQrQsAy9o8VvFyB9NB0/cI9qS90B25vB4nmc8qKXR8kWK46BU7C 929GvdjKKqWqEuCZ0dDWHwX0zfbChajuzGgLk56tVcGGp3iSPj6SqvsiQuRvjMy8xp kPM4hqXrRbXWKAQRzRhWtMEcndyEDuNrcYmwxBAs= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180605222416.GZ3011@mx4.yitter.info> References: <20180605152355.6tlbeqvt7luklwjl@nic.fr> <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 22:24:23 -0000 On Tue, Jun 05, 2018 at 10:10:33PM +0000, Paul Hoffman wrote: > Resolver 1 sends a query to a Resolver 2 (who allows forwarding) over TCP. Resolver 2 asks an authoritative, gets a response with TC bit set on, tries on TCP, and gets a failure on TCP. Resolver 2 should send the partial answer it got over UDP to Resolver 1. That answer to Resolver 1 should have the TC bit set on, or not, depending on what you think that RFC 1035 "implies". > Alternatively, maybe Resolver 2 should send some error (I'm guessing SERVFAIL is the answer, though I suppose Vixie would be unhappy with that guess). The problem, of course, is that a TC'd answer is literally telling you it's incomplete, and in principle you have an incomplete RRset, which is maybe important. It's not clear you should use it, and it's pretty clear (at least to me) that you shouldn't cache it. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jun 5 15:26:29 2018 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 A0F96130DF9 for ; Tue, 5 Jun 2018 15:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 Grn8X6j9fwqV for ; Tue, 5 Jun 2018 15:26:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDC9130DE2 for ; Tue, 5 Jun 2018 15:26:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 22CAC21CB9; Tue, 5 Jun 2018 18:26:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 05 Jun 2018 18:26:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=r0TLMH bBfQIwTLFbtVxgF5Nam26uGZykG4gjdMmke50=; b=WxHnJqizA935S8ul49ehqi lvfay5BtsiYKn6B0pWs8mqqSrjj1q7CDMSvPBmFgpReO+yxHl4YsoIXJqdaEKiMH R1+AAp8OStvh+lKElDGbZ5EhMuAQtlAoeTeHPG5IkuZ0f2VZITBvLAOP47vEqCLa ebyIROJe2xbtlkZwhxJqnSc8u2v7awtZn77bwKCvN+iYxVq1xft554lO7LgQVegq MwtvG75afniEuCnnHmmD5BeLY+ghGr+t/e9jAONRAdci/2h2e37gOnDFK/2h2/78 JGVK9jy53SDGirKru/CqXWeul+dSVmN5cKtVFxdlVACj0hb2m7PuqgFseMbMRomg == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.72] (unknown [195.147.34.210]) by mail.messagingengine.com (Postfix) with ESMTPA id BA5BB1025E; Tue, 5 Jun 2018 18:26:24 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F493D8EE-D2CD-48BB-AF8C-A3BDB8B1B4E9 Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (15E302) In-Reply-To: <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> Date: Tue, 5 Jun 2018 23:26:22 +0100 Cc: "doh@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <1FA8A1B3-82F9-4D1E-A555-C82A8E745B53@dotat.at> References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> To: Paul Hoffman Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 22:26:28 -0000 --Apple-Mail-F493D8EE-D2CD-48BB-AF8C-A3BDB8B1B4E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 5 Jun 2018, at 23:10, Paul Hoffman wrote: >=20 > Resolver 1 sends a query to a Resolver 2 (who allows forwarding) over TCP.= Resolver 2 asks an authoritative, gets a response with TC bit set on, trie= s on TCP, and gets a failure on TCP. Resolver 2 should send the partial answ= er it got over UDP to Resolver 1. That answer to Resolver 1 should have the T= C bit set on, or not, depending on what you think that RFC 1035 "implies". In my experience this results in a SERVFAIL. RFC 2181 has a specific instru= ction not to do what you suggest: >> When a DNS client receives a reply with TC set, it should ignore that res= ponse, and query again, using a mechanism, such as a TCP connection, that wi= ll permit larger replies. << Tony. --=20 f.anthony.n.finch http://dotat.at --Apple-Mail-F493D8EE-D2CD-48BB-AF8C-A3BDB8B1B4E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 5 Jun 2018, at 23:10, Paul Hoff= man <paul.hoffman@icann.org= > wrote:

Resolver 1 sen= ds a query to a Resolver 2 (who allows forwarding) over TCP. Resolver 2 asks= an authoritative,  gets a response with TC bit set on, tries on TCP, a= nd gets a failure on TCP. Resolver 2 should send the partial answer it got o= ver UDP to Resolver 1. That answer to Resolver 1 should have the TC bit set o= n, or not, depending on what you think that RFC 1035 "implies".

In my experience this results in a SERVFAIL.  = ;RFC 2181 has a specific instruction not to do what you suggest:
<= pre class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; break-be= fore: page;">
>> When a DNS client receives a reply with T=
C
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies. <=
;<

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at

= --Apple-Mail-F493D8EE-D2CD-48BB-AF8C-A3BDB8B1B4E9-- From nobody Tue Jun 5 21:37:28 2018 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 7BF4C130E95 for ; Tue, 5 Jun 2018 21:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 28hu1oZkQ22J for ; Tue, 5 Jun 2018 21:37:24 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003061.outbound.protection.outlook.com [40.92.3.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB14130E79 for ; Tue, 5 Jun 2018 21:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=adIuRuok6O7phjLy0AMZG/YYe6t81A8/fRUS9njbNS8=; b=Za4IWBYhaVaN2LXCM3hAO/mWj3zx7AS8QJ2iG0lP2QH6c7QdvkyVH+/OY7tQnc4vUyRsbMnHdiF8+Wi1f4kh/2XkKQESGBEhJO4jYZ2V1G3OkgSo2oYz84QTtN7ReTvNPRkeONyeDY1nl3A0K56qghdzDjoLCTtiL4QHoOfMMzK900HtZue6s/AEdTGKcmBwmqGDXJcq8UBbCSCFgXE+HL+hjedJ8Ilo588zVKSKEGwJZ+LZqD35ndHImr+uT35p6xHrNmOsgfMVhjHDWV/ShbbGogUJyWRdXrc3Kc7g8d/pEj020xFbmTYOCCBjRYrGZ0rkaJoj8F538U6i/mYvOg== Received: from BL2NAM02FT033.eop-nam02.prod.protection.outlook.com (10.152.76.59) by BL2NAM02HT075.eop-nam02.prod.protection.outlook.com (10.152.76.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10; Wed, 6 Jun 2018 04:37:21 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.76.54) by BL2NAM02FT033.mail.protection.outlook.com (10.152.77.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10 via Frontend Transport; Wed, 6 Jun 2018 04:37:21 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb%4]) with mapi id 15.20.0820.015; Wed, 6 Jun 2018 04:37:21 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] [Ext] a tad confused on response sizes Thread-Index: AQHT/NdXdt//5ho9S02KYza5xDwOp6RRtiwAgAAIrgCAAAVeAIAABIeAgAAO1QCAAAOGWIAADJIAgAAEt62AAAt4gIAAAOwYgAAkcACAAB0lgIAABGsAgABlzM8= Date: Wed, 6 Jun 2018 04:37:21 +0000 Message-ID: References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> <20180605152355.6tlbeqvt7luklwjl@nic.fr> <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org>, <1FA8A1B3-82F9-4D1E-A555-C82A8E745B53@dotat.at> In-Reply-To: <1FA8A1B3-82F9-4D1E-A555-C82A8E745B53@dotat.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:4C0CA6295C82EF8C654AC1EBB51804116ED5BDF393561344311FC1B839EEB7B7; UpperCasedChecksum:7580FC0A0C3C4805EA55ACA00D8D5C24C507563F72CC660FB9735095BDD1BB34; SizeAsReceived:8005; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [GDKV3R6zrLsEdKHRwKKAQOLdCgWvdH7ksOlNTJEGtiI4901M4T60dQ==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL2NAM02HT075; 7:GbPdUwpbp7Lc42A+SPFuUIpN9M3lm4TFO7elRY3/+TpLRkNZ+xDVUVuL8Mk6n+F9jm6V9tsPEN85X7J7v4mZO/uubvlE0CS5rY/VjCx0SwcpxW8cti1ZXBXrOAcPjz8k/nGAZbztJ6Nj203c+bBE+kRdg9Q6b9rBcRQOCd6X6PB96REY6HOTZ1D1q4GRMzQJzXfbLYqQGxDV4wl5zyz+qdJBO4WUxkligoeUbB/Pm4LhwzV7WQG9hOXx+PRf5k1V x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045); SRVR:BL2NAM02HT075; x-ms-traffictypediagnostic: BL2NAM02HT075: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BL2NAM02HT075; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT075; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(52314003)(189003)(199004)(6436002)(229853002)(11346002)(8936002)(446003)(476003)(9686003)(5660300001)(486006)(53546011)(6506007)(73972006)(59450400001)(6916009)(6346003)(102836004)(5640700003)(99286004)(83332001)(1730700003)(76176011)(7696005)(86362001)(8676002)(2351001)(3660700001)(3280700002)(20460500001)(81156014)(104016004)(5890100001)(93886005)(14454004)(305945005)(74316002)(68736007)(33656002)(6246003)(25786009)(105586002)(2501003)(55016002)(5250100002)(46003)(82202002)(106356001)(2900100001)(97736004)(99936001)(87572001)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT075; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: X+LNSdCWfXGJVXlT/e0/AZqOKeR4Ji+zFOdw0348MIP/BIlf1pb5Nu7zhJfGJLsGK0K9Ah6ulsY3h+Ba/X6GIRSeg5u0rwOQza9UUf+Rj1A5lcHexjgESSLB+XmEsTA3dr+hQfjKYnHrTYcIbWhI1ea5y4Cxtt1KyYeu4Uyc4Wr5LIO36lZIOgHogW2tic9v Content-Type: multipart/mixed; boundary="_002_BYAPR19MB2248C54302A11BB5967F529994650BYAPR19MB2248namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8ad40d1b-6376-4894-a39c-08d5cb673177 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: 8ad40d1b-6376-4894-a39c-08d5cb673177 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 04:37:21.3896 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT075 Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 04:37:26 -0000 --_002_BYAPR19MB2248C54302A11BB5967F529994650BYAPR19MB2248namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed, Jun 6, 2018 at 6:26 AM Tony Finch wrote: > In my experience this results in a SERVFAIL. What is your "experience"? In my experience, Google does produce TC (see at= tachment picture). In other words, even if the RFC is changed to "the DoH server never produce= s TC bit", your client should still be ready for a TC bit, simply because s= uch implementations already exist. > RFC 2181 has a specific instruction not to do what you suggest: RFC 2181 defines what a DNS server and a DNS client should do, *not a DoH s= erver or client*. A DoH server or client is not a DNS client or server, because it does not n= ecessarily need to fully understand everything inside a DNS packet (althoug= h it can, for cache or whatever reason) A DoH server *never* touches the TC bit, it's the buggy upstream DNS server= that sets the TC bit on a TCP connection. (It's their fault, not DoH's.) A DoH client *never* reads the TC bit, it just verbatim passes the response= to the downstream DNS client. It's the downstream's responsibility to eith= er drop or consume the response. In your case, you don't have a downstream DNS client, then just imagine two= modules in your code. Anyway, whatever DoH does is not violating RFC 2181, as long as DoH does no= t touch the TC bit. "Garbage in, garbage out." If your network software can't consume garbage produced by others, you are = out. (Hi Netscape!) your software loses users and loses the competition. That's simple. P.S. I'm not going to talk about this issue any more since I don't think th= e current specification is inappropriate. Also practice shows it is working= . And just for joke, I'm just too lazy to change the behavior of my software = that some hundred people are already relying on. :-)= --_002_BYAPR19MB2248C54302A11BB5967F529994650BYAPR19MB2248namp_ Content-Type: image/png; name="Screen Shot 2018-06-06 at 12.04.05.png" Content-Description: Screen Shot 2018-06-06 at 12.04.05.png Content-Disposition: attachment; filename="Screen Shot 2018-06-06 at 12.04.05.png"; size=83880; creation-date="Wed, 06 Jun 2018 04:30:55 GMT"; modification-date="Wed, 06 Jun 2018 04:30:55 GMT" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABIUAAAILCAIAAAD5RLtoAAAABmJLR0QA/wD/AP+gvaeTAAFHXUlE QVR42uy9+79N1f4/fv6Fz4/f34+73ItChcqt3InccgmFStid0IVKoVCulUvRVZxTKSFRjggJ220f pOyOTkgo1x3299l+Hq/3OGPMOdZYc621bdvr+ZiP/Vh7rrnmHJfX7TnGa4z5l2KFQqFQKBQKhUKh UFwJ/EWbQKFQKBQKhUKhUCiUjykUCoVCoVAoFAqF8jGFQqFQKBQKhUKhUCgfUygUCoVCoVAoFArl YwqFQqFQKBQKhUKhUD6mUCgUCoVCoVAoFMrHFAqFQqFQKBQKhUKhfEyhUCgUCoVCoVAolI8pFAqF QqFQKBQKhUL5mEKhUCgUCoVCoVAoH1MoFAqFQqFQKBQKhfIxhUKhUCgUCoVCoVA+plAoFAqFQqFQ KBTKxxQKhUKhUCgUCoVCoXxMoVAoFAqFQqFQKJSPKRQKhUKhUCgUCoVC+ZhCoVAoFAqFQqFQKB9T KBQKhUKhUCgUCoXyMYVCoVAoFAqFQqFQPqZQKBQKhUKhUCgUCuVjCoVCoVAoFAqFQqF8TKFQKBQK hUKhUCgUyscUCkXZxfnz54uKirQdyjh+//13bQSFQqFQKJSPlWn89ttvO3bsOHr06JUtxtmzZ3fv 3r1v3z6EueW7wa+dmpZj/PDDD61b37lmzRptirKMQ4cONWhw48aNG7UpFAqFQqEoE3zsnXfe+etf K3799debN2/Gh4ULF/L8H3/8cbIEZ86c8d/hwoULvPL06dPloE337NnTpcvdaAoeN998y9ChD6KO csG//vUvfpXunREDdevWDR969ux5/fU3+C9GYz7x5JMVKvy3GJ988kl5FeKruqZFRUX5+fkXL14s zYee/F945jpEiwXgvTkq1dGjRxs1alyt+nXbtm0DqT4ZgFOnTuGHsDD4/Ntvv3kGR+Rifk4JVPwK SsUHH3wASQY1Dbn40qVLIEiwwGCzgZ0ImBbJLx4Wzp07d+zYMfRU1WrV0VNXo8U4ePDgkSNHymbZ /va3v6Hrxz39dI7u/5///Id20qMvxBtvvIHL7rnnHo2Tyj5+/vnnwG6NE7mnn3lGm1GRXdFKiV27 dqUkCOEm64pEU2WRj23cuJF87K233uL5f/7zn2zEJk2aImLw3GH+/Pm8sk+fvle77MLN16pVm9Vp 1uy2O+5oDp4ASmZekwkf6969O/nYDTfU9188ZszjfErLlq0eevjhnTt3lld7cVXXdNCgQSj5+PHP ldoTQXVksECOGjVqovXgkq0Z3S+//NK9uF6969u37wC1zeJUJExEx46dKlWugidKLJjy6Ny5Cy7+ 6KOP+G/kxNqWLVv47euvv45/69StF3JnmK+yz8fAjWfNml27Tl0pdt161/ft22/v3r3mZWKKzQNN DQM1ZMhQ62KQN3/LPPvseFy2ffv2KlWr1a/f4JdffrnqxstQCxT++PHjyseUj2nQrHxMcUX4GDwy btu2bbtsmazSj6bKHB97++230QTgGJs2bTJnJ8wgYN26dZ47NG/eItd8bO7cuV27dp03b16uG/Sp p57inNh3333HM7///rsV8STmY4h+HnhgMD706NEDTM9z5cmTJzlftGDBgqtRLjds2ID+GjFiZMor y1pNUZ6uJQg0Xnl5eSj8tGnTS5+P3X77HaBVOGAQQe958rrrapp5aMLHeCUOkAQZcbjllluzFY4v X74cN3z88Sf4L8yIPJEHexkUwjyJSILXg4Tg28aNb7YG28AuwDPxVYcOHTls1qtXL/MODRs2wrfV q9ewHndlZ35C+Bj6EQyWHYHue3jYsKFDH7z11ib4Fx309ddfu3zMrCBasmLFSn8Ss0qVX331NZeP iXhYh1hRWv6JEyddXbblwIEDIGMgsbkY7lU+VtaQrkEu30Hz8OEj0BSmcVA+prhSfGzx4sW4bc+e Pf3aGm6ySj+aKqN87OjRo+RjiKRdPjZ48JC4n3NWLdd8DHEe7v/Ek0/mukGZqfj88xM812TCx8aM eZx8DCLruRLRJO5fuUrVq9QJIRxH+UHUU15Z1moKfsLOPXbsWOBPSjl1SvjYN998Y57ft29fp06d cR4UBWbR5GOVKlexbrJmzZoGDW7EV/369c9KqcAJq1W/ztMUIIp43BdffBH57aFDh3iBNTY2a9Zs lr+goCDyh6AiJCplSv5D+BhqSiYGFZAEhAsXLrz00kvUCLSJaYrdToTKwCTiKxAzWG+Lj1ni4QJX 4ungfledkUGBc5d2q3ysTCGBQS7HQfMddzR3U/qVjymuCB8rLlmkYGbPRWpruMkq/WiqzPGxt956 q0KFiogDNm7ciCaTuSAGATfeeBODg7idLR55ZDgHtssHH2NFPvvss1zwMUQ/U6ZMwYfu3bt7KC6w evVqtupVKpfhfKys1bTsu/84PkbjWKNGTdNhx/ExUrJs1ZS24rHHRnmu8fOx4svJD5UqVd61axfP FBYWVq1WHSdffPHFuF9dvXzs9tvvwDUImt2vOnfu4qaOR3Zi8eWpxfvuG5AuHwOefXY8rpwxY6ZG LcrHlI8pH1MoH8u6tqbFx65qZIGPLV++nBOOCIPatWsvSfkMAtq0adurd298mD37Ffe3J06cqFK1 GgOmSD62c+fO8eOf69atGwJu/AUbidx7YOXKlf3739es2W233XY7PpjmBrZm4MBBN998C9Or8Pmh hx82f1tUVPTuu+/C6+ARXbt2hSM8fPiwecGCBQvwq48++mjbtm1Dhz7YpElT2bPEMmq4jPFfx46d 8JnJVIhv8BkHxNrPx3799dfJkycjNERpESTNnDnLWp9zb58+H3/8MenlrFmzI7sjPz8fz2IiU7Xq 1/HR77zzjnkNgtpBgwahrUB4Hh427B//+Id1E1Br/AqdggB99OgxuGz48BHUFpzHT/B5yZIl99// QNOmzdB0uBJdWVwy3YyO7tevP6qAxsRnd+9ynIGnRy+gAK1atX7ggcFmgtzcuXPxCDQCFzWx/AcP HizlmnqGc5555tlOnTpDWhD1jhs3TroVAo9bQYbZuehB/Etmjp5l8VD3l156CWVGMM0NFcAHcJ7d Klc++OBD5EKPPDIchb/rrjajRo2OHNH48MMP0YCQSVB01OL06dO8oSeY9vAxAL2GryCHKfkY6oLz +Hb9+vXmzefMmdOjRw8IwJ133oU2RzeltCFQbdxn1apVmfCxixcvdujQEdfACjE1sfe99zLF0bPO LRkfS2mXaDRgl+BC0C/oHRgfWELpaEuoEAyh8JAKdP2GDRtC+Bgt54oVK9yvYDpQMM6lp+RjUGRz RCMtPkZTdv31N/inm2Cv0BoFBQUQV3TKrbc2MdNBUbwBAwZChuEs8vLyIjNFYZOha1Ac9ObgwUNW r1594MAB3NOcDn3ttTk4g0dYv33qqadwfsuWLfz30KFD+BcItPApzXJisS8umd5HlWF22rZtBx3/ 97//HcfHUpqytWvXohYvvPCCdf7tt9/Gefg4N7hB1+MrWg/U0cr1jeNj+/fvRyFbtmyFwqAv3AaP w7fffjtyZF6LFi1h0FBr3AfBAwqwePFiuQbncWbPnj3mD1FU2k9Ly+CPoHqQCkgvGh/C8NNPP5ly FWeQ05K93bt3Dxv2CLoVnYtQ55VXXk0wuQodf/nlaQhOcBPI0mOPjfrxxx9dTzR9+oxLly5B/FAq WIwuXe6eNm16pA9FANCrVy+oEu6JzvXHrFAfNiCH21AAfJZhFOFj+C3kBz3uMVZZVIeUoVeG5jdO oxMLcLakBe7pq6++mjhxElwV1AFlsDJI05IZhEzw+/AyaHDIA0q4aNGiyPKHVDxd0ZKYzZKWvXv3 4qSVOgjBQNCI81zmsGbNGnxmsOHRVrMACEjQvHFBkRVNiev54YcfUPcnnnwSZha/RRnK5i4DOdzv nkEAnAciBnxA77q7esybN4/5o9wUxOJjUKHKVaoykqhduw67pGHDRtaSFUT2/AoBCq/ncC9jMk7Q mUfNmrXktygS5FKWwnONCsILkyHQWqGQtGU4XJ8HcCGKeeCMGf4igPDwMfBYhBo4iTLUq3c9L4Da S7gfiM8//9xdgm9ODDIAZXMxxsUBATWVDc5e9iMxN05AuMDuGDJkKNOczJ0Vvv/+exgXXiDnYdbN 4sFfyqIXqSYOmHVeANvtln/Hjh2lXNM4risyACniB1BBSgssl1sexIimQYFpkK+4gx/YFD6DpJnR EmQAhuy/+y5UqswP9es3MEsO0eViRdmegTuacLlUpCsN4WOIzMysPw8fQ/lJCRAc8wzYuDSjtA8O c3mSC1QK11StVt0f5aTkYwAifrbD/Pnzly5dyqdHurpM+FiIXaLRAJ3mLJZ0Ig54aPNuCD3FdPC2 6H2mPfv5GFwL5TnQFMfxMZBGLjlLwMcAqjzCC881iGAs4ZftUmTjFhSA4oRyWpN+27dvZ3IsDmlw cnh4ZbkMgVfkXCi7YNmyZXHm12PhQ8xyMrEvLtmHhlWWrkftWrVq7fKxEFP21ltv4eTdd99tPYXb HcFWWHwMPzdNBxvTzPaJ5GOIQTnmiJLIOlJESJ7tOon3339fvDN3oOGiTXx45pln5TIuZLXECVEX fwgyYJ7kakkcskkP7iyMy2OQw2WPrUoBkJZPd93spk2bRIARXUhXmqaJnggNgnja8q1WXHTixAkK v2lYOI4WFzTDNbtNgWjblP9+/fojVPUbqyyqQ0jolaH5jdToxAKcRWlhljhXa0trm1qQlszATXAL BjPuGjkyz6pRSMUTiJbU2or0OMWC9jfpOnPoZOzPtDAh4RPTMTxBkRVNieuZMGEiqyw/RFsFOrhy xcdgMeHgKVjulmXUW3hKdoxpd2RXNPQTWhw3wc9pCzg/Q/z973+nhCE6RzwHW4Dr2eiIyUyWHJmv yDUYYAjcKvr06dP0XlAhGZSiblPuUc5vv/3WGqUw0ahRY1yJwrjhr4eP4RpGYHgWxQvMh2cQ0iVo /LgsPu5EByX55JNP8FBQVmgIKWteXp6l5zQEL788DSaAA5bkY3R7HPs/dOgQdIaGAM2O6r/33ns4 j5tzYaEVQ/fq1YsazvEJaNrEiZPofvbv3y+XZZ6vmGFNIwGpwJXgonBvNHCsDmIIMTr+CXeY6XHj xq1atQrizeGJSD7GK2fNmg1Jg4mESNOxmYaGTYRj+vQZCFMg/GvXrmW6bGI+hhCHD4JapeRj6Fbe B1IhY9vsNbQMGrywsBBhJeviGY7CV5zU8nd0CB8z3QADO9nwI1t8LNAuidHAndEvaPOtW7dy9ye0 sIzmQgYYf+Mv2gGNBtGiUeJJT0lgNiVc8whtSj6GSAXfwtok42MMH6156Ug+xmEyiBbEg9PpUATI Bnwq4m80BSIDWA+YEVgDsZZoE4aJaI19+/YxKESYKBQiW3zMtfCBZjmZ2EPTGdU9+OBDuC3qDtrJ Gd0/+di4cemasnT5GOQBoe3hw4dxT6g5Yz4zO8DlY6gaLuMP6R8lakTHeQQA7UkfAR2hYcQZVNyN RAP5GDw1xyNAKlAjSgXHpxCs0z57DHKg7B08eJCxxMyZs/BzNBQ8O3NtBg4cFGgxzp07x1gQxaOp 3L17N4pNFiGD1KYn+uCDDxDJoLWpm9y/2pzvJXUH88TNUcFFixYJsZelv5Hw5CumNFbZVYeQ0Ctz 82tpdGIBzqK00OPcdFND9CnaB7KNM2RKS5cuTSYz6FbcDU/E3URmzCn0wIonEy0EgRyYNqkX/Zrl srm2WRI3XAuTMnzyB0VxfIyWLT8/HyVEV3LMugxmYuecj8Ft4PPkyZPdXT24/wdEHEpFGTX5GGQa ftRiUFwiYm71PmLESMstyUnzbpF8THRb9kKk0aEmiJhSt8E0QobEkvGxGTNmUkXNsQruVAERlB9m yMcQslO1li9fbp5H9WFW8CCZhqKeQ3tllT8hfMyi1hJGLFmyxI3DJPkN+tyiRUvYDnPDSfQ+QwFZ 7pI5H8u8pi6k7kI/ikveX8yBTEld8BsUN2s3jo9Zo4mcBL63Tx+J4zkkZg2qQVQ4IpiAj+G33M8D MiyGNY6PQQCguWSncpJsULhcccn2EhzDtsZZTbCvzfyxTPgYSk73TEPhj04S8LFAu0SjAWdsigFa mAUTaSGnql69hjnwD4wePSYlH2PhxVnCx0ybNj3SVnj4GMSeoYBMUAsfg19/34F7f7pw/w5GtAN9 +/Yz3wyDnmKfvv322+bFTFmRCO/DDz+ks7fiaRLvLPIx18IHmuVkYs92Qzxqpo3AcKFGJh8LN2Xp 8rE333zTyn3imJrYNzda4vATs6kF5MZoBM9bbR57bJSrZWglDr0n4GOMKBBtW+8aGjbsEXMxZJxB DpQ97v9mpfbwJMxs4GuOUBdIIHiLGa3ypQtm7EFPhL42zTKeS+ItjkNoPN8LIpB0gMR8LKWxyqI6 BIZeGZpfV6OTCXAWpeX48eOsuJXAyRkz0bW0ZKZeveutLCqGu+YW3CEVz0S0yHBk7g70j+2Pv6NG jZbLUEEzPE6Xj/mDIg8fk3Q5gul48CnXHB+rU7ces9Qq/mnqq5jpnjSdnEdmdlbK/TwQ/rJjJNN9 ypQp+Ldp02bmmApCilOnTpnpT5F8jOLIN3qZePTRR82R9bRWuybjY1Tsl1+eZt2NVsxdKpCMpZAA I1p17Q5Dmeeee97U8zvvvCuOk1hv7mYoALtgvUWXMQc62l9aSoK5FCRDPpZ5TV1IYGSudigueRkx hE1cVLoLUuP4mHUl54Fho/kvFMolhwQnEzwvxRaBROR3Twm6desGs0ViiQiJ480mH6PRJOAkJI8C CmU6DEZX1lsKcAHax7OCCy4Wvxo7dmxW+Fjx5T0VAzdFyMp+Hq5dijMa1GhhyyNH5kVuZBL+Puh9 +/bBy5JTSSKfxbRpihEzTZr0ghwwiZKaAlYgAux//5gsQ7KsqH97ITpFa+kOI7maNWtZxoSijp+Y g2vuPCcva9Ombbb4mNtZgWY5mdhz4NxdwmGtHws3ZenyMdcWMfVUxtSsaAkBDcd6rIwyjo7jwJ0h /wf/F5xdYYwOqbaeyLkUvtEuLT7Wo0ePyBsiVLU8VKRBDpS9DRs2cCDDHIZAR5wqQYYBEoiNmewd 54kYjciUAld7Qh6sy3Kxn4dlrLKoDoGhV3bNb4gAR94/i9Kydu1aXNOpU2frESAwAwcOSpkMFSgz pEM4mH4cWPFMROv55yeYtnfu3Lnk5LVr10G0QNuF3kcEhUO6KV0+5g+KPHzMcj0SPsXtMlhu+Rii KP7LyVbZheL48ePoGIQIDCjj9vPAZQsXLkSkDt8DjkuWb1pbiD4teMOGjWDW161bZ1ECDx9jAn3v e++d8r/gOgdY/FLjY3VLUrFHjx5jlQSalux1CpEshaGntZ0J8dprc8xhxXT5GIf5XU1mt6LvrPOw XKgUwlA0NR7KRssiH8u8ppGADDCu7du3H8Qy0nzniI+tWrWKY2/mYLas+UnGx9wD/sBKOo98HzQP N0UND2VWUtu27dC/u3fvDmlV+uCUQh7Ix9D+spgELIXJMFnnYyntUpzR4OyHDB6TEbmvzgvnYwSk BUwJJoukunKVqkI/imPeBy1rIdDypjoLH0MIOHv2K9bhJkYym86cpwrkY3TGEFfL6FHLUAWOaDK8 c7eRLAU+FmiWE4g9GpmpTdarKV0+Fm7KMudjXBUsAbcVLRUUFFCnpjjgMh5QR64VN4+3334blaVY ouWzwsckvoycDWYWk2yyGmmQA2WvqKiIK9xgfEaOzFu6dGnkdmIhwK3w8xdeeGH48BEDBgxEr1Wr fp0ZKsR5omeeeRbnYST579SpUyOHP3LBxyxjlUV1CAy9smt+QwQ48nFZlBZOPEhv5khmRAu2bt0a XvFMRIsBifBMGG2+gojbp7MYX3/9tTWdlSEfs4KicD6GfuENze1/rgk+Jkky3B1bJnNJoBHX8tvn nnve5WMzZsyk/MF1wUwj3OcCHhzm6BT3y5K8HURj0EaroSP5GEco4w6h3bnmY0Jy4g4ZG8uQj3Gr DBlPdaekW7ZslWs+VlhYSCvPSXx0AX5F22F65Qz5WOY1jQPcgKTDcWLBmi4rHT7GWsBDZMLHYKSO XMa4ceNwpkWLllYSzn/zFStVPmKgXbv2cWIJm8ukRx5NmzabPHmyZ5ag+PIbLySpNUM+xqD8xhtv YuThDsFmzsdC7FJgiMOhZSsVLQEfMzWUq+QRAcssGU0xziw3sH79ei5bcqlCWuvHKJmu7qfkY5wb 9BwcvIxrolzzsbTMcrpiLwO0XEfn4WPhpixzPjZ27FhzttaKljh87jk+/vjj/Px8qLN5QMw8lU3G x2R3isgdgGgAP/30U49BDpS94pKVPOiLupf3rkCYgbB48+bNaWklgh/ZVwzxCdQB+kLSIpvKBvIx jl652QS55mPZVYfA0Cu75jdEgCOfmEVp4ZpJz/tXsiIzAKMUGr3AimciWvAatWrVRo+A6kBJ4Wu4 vQc3i5o4cZLwPXNkTfnYFeNjiPOYtMClR/SRIlguH1u0aBEFkYuY/XwAgCriyuHDR3B0HIq6fft2 Px+jbYJufBkFGSzJNR8TEUT5I0vijqEmYymMuSPDaGs/lRzxsTNnzrDfEWSYQ5u0d1mcH8u8pn4U FBRMmzZdXI453FU6fAxRjmzgmZiPmQH38ePHmbtvJaRFrh9DtER3aG7BYuLw4cMgrv3738eNsMB2 rPVRJphynDJHJYSPyZabK1askBfN+xdqp8vHAu1SIB/jeKq51iJDPlZckiHDOSUJ4v37eWTIx95/ /30OdafLx2iTEa98GQM2b1wT5ZqPJTDL4WIPIhEXEFh8LNyUZc7HmDcuYmNFS7TJiKTj+itus3Kp rLygPEM+dvLkSU+6EaNh/4LeQNkTXLhwASYXEkJJhirFbSke6SyqV69RocJ/t3mwOEm682NMDHMn WHLNx7KrDoGhV3bNb2IBzqK0cMjD3K0nFzIjWrBu3brwimcoWhwHRKDCJXNcngrdR0VIsOmVzHcX KR+7YnwMmD59Bs7wfVNc7Sejsy4f47491v4QHj4mwFd04ebEqydfURayx6EU8hXJIb/99ttsNX4k S4Fx5Caw7vX0+lOnTs0pH4N14AZK1lqIrPOxzGsaCNnkULxR6fAxGDXOeLhj8Mn4WPHl5dr16zcw OzduPw+miMiOyXEoLCwkj3JT8qzAul+//hnyMRhZbhwvm1mNGjWau0WZu3hnyMcC7VIgH+Nwqbsk IyUfmzVrdo0aNeHhIr9lVoy8uSGnfGz27Fcit65NycfojK1dkl0wic50sXF8jFNJphnJhI9lYpZD xJ7b4bi7e1t8LNyUccPotm3bJeZj4HLmPh9x+YqB+1iYIMtyK+vyMc4JmA60OGr9GLeAcuepSNWq VK3m3/A2UPZcoO5cFI0aefYvcZ0gfJx1Phkf467F7rR/KeQrZlEdAkOv7JrfxAKcRWnh1iMDBgzM qcygHdggJD+BFc9QtEjDYLi4465sMcIIZ8+ePdBKK6NH+diV5GOIivAvDgZzZhTi8jHye9kA1Lyn KB5sLgQUsm7ZZbpqM0YnH8Nf8zJuJBD5ulh5q3Xp8DG+MttVP/DVZK8kj2Qp3J/H3KFVtJemVoLd HPExycO26siBE5ePmRsElXJNXbz22hxImmtJmU/1/vvvWwbF3Nkp63wMQTNDHGuY9uzZszyfgI+d OXOGG3VIhOfhY9yk3txSCX4aj27atJlVcmZBeN6yzYksM7BOxse4RVXNmrXEE6AkjHrRyNniYyF2 KTzEmTNnDvN5LE/JpUEePkZ5qFylqruhizxd9C6nfIzxIiqSLh+DwLAK7iog0/yyg9wm4h5ZpthM mDARZzp06Ghedu7cOcpAAj4WYpYTiz0XVLuj0TwvfCzclImqWltNcE2Oy8est9n++OOPfAeUBNxW tAS7wcRyKxqmovlf39S3bz93G+TiyzukmXyMr3RHV7r23ORjDOjd/Q+4l4+pzpEGOVD2YDfQudYm mZJ+6XntjWvhR48eY82+culOunyMhhfyYD19x44dueZjWVSHwNAru+Y3sQBnUVq4saS7oS5sozkA nZbMuMsW3nzzTb6UiLvcBVY8Q9HioAn6tFr160wF5Aa59/bpY2m6n4+FhE/KxzLiY8WX5zSZ7GTu 0enysc6du3CBoKyJ3Lhxo7zGTqIQeq9u3bqZqeTcCMhMoaHztnI5oL0cUIeJgds2R5ehMJJLWQp8 DJrAFc/mHsSo0X33DQDTMN+mkgkfA2AQuepJxB3F4yA9HKE0Qo74mNhNiY0QOnD5kLUjEzfbNbfi KeWauhAGYlKCrVu38iRXrJpDvGbKTdb5WPHlLarAoGSLBUTSEJhM3j/GETIwH5lQ8rx/jI3Ztm07 jvzh6XzN68SJkyR0hvKSH8pGPi4OHz7MFBT/6J2fj0l24sKFCyMnMFeuXJkVPhZolwJDHOgRIwxE XTLcjhtyNaxnv3u0FW+Fa6w9NqBc3CtCvG9O+RgnVSyHF8LHhCq0a9fe9IsQuRo1akraIRSBUcjz z0+QJiooKGC7mfuIcBgOhtTUCHkJtcSg4XwsxCwnFnuaDgR5ZnAs71UzM5oCTZkYZ6iANBSJvTmB KRbmppsairiiwBwkldfQRUZL8+fP5z665gBoYWEhLH/Pnj096+WYEYPKrlixwpwEJgM097tn4I7A VCqLOE9eIiSj5nAQkGf0jrl8l5qIe8risTiDHCh7HC6B+JmZbJwQhjliIIuSjB071rMdEd8Hheul tQ8dOiRvZ5LyB/IxgKEtYh7xETDXsobKv989CbCV0xtorLKoDoGhV9bNb2IBzpa0yNgEImGpOKSa c/gzZsxMIDPW+lLYRo6rmrQksOKZiBbAheXWzCduJS+Ct3Qw8o3z4eGT8rFM+RhXnrivG3L5mLxt FqFJjx492EnUajMs27VrF7+qWq16v3794aU4GopfmRPrMuWKwAvmQ9wVNIpxHgzKsGGP4Oe8G0Rf QtJS4GPFl1OMaJEfe2wUFINWBqWK3DEyGUtBpfjeKmgmLAI8PWfAmzZtZk4Q54iPwSQxeuMusfjM 9ansVism5oJUFA/llM2ySq2mnhkY1hRSgQiJ5Ycwm7krfNkOug/nGRPngo+hC2igIfmwaLDyNWvW +vOdEiWhfDI+Bkljs8tqLg8f+/P1lyXVl12n0Zh8OtocNBvqzG3QUGzP+jExmhs2bEjGx1Aj+jP4 aTeJiP4Peh05vJcuHwu0S4EhDlkEoxy0EgSVQst0LP/7x1AdIRtgxUOGDL3//gfYDtboRu742KlT p3BbNIV/4+A4PoYgg84eyjJgwEA0GquPmGbLli3WaBobBMrVvXt3PJGyZ/IxiIGEDrAtiCq47p9/ E/CxQLOcWOzlrbVt2rSFHaAssetNPhZoyoovLwCjgerf/756JZQVAa7LxyByuAmoCyQfLc+HQsXM ZnejJRhwvmoSP4fwjxnzODQOFgf38WRmmmXDlei+UaNGo+PwmZ1o8rHvvvuOowm4LaqAZsezWAUr i2nu3LlUHNjh0aPHIKzk3RB6Wo92DXKg7J04cYIOC0XFU0CKRL/mzZtnhjSy6bkLNLhs8AD+zDc1 QWA4ZSEv7gvnY3v27OHUKG6LJgKFRsXZgymDZk5W4Hr0owTx4cYqi+oQEnpl3fwmFuBsSQsJPIuN iqN9UB4KPD4IyUxLZtjasAZ5eXmQB7YqLIApCYEVz0S0ii8vBcexb98+8zwnSCAG1pu+I/lYePik fCxTPoZoCXKD82vXrvXzMWD58uXcAoQyB42FxJP6wxab7gpxiWxyzRRY068QTOTlYY7EFxYW9urd W7ZnbNiwEZTE7PjS4WO07DBGHDLEXyj81KlTA5PUA1kKB7TgmzmIxQfBvqARzGtyt78iHCoiRdaR JVyxYgXjLWv3djHr7rBKKdQ0Du+++y6MI+MAmmMov7XN1+7du2VnJA6e5YKPMRpGFC6tdNtttyOG NjdWSpePSVeigjSpHj4mOoXGlwE26B0MPSNg/nDkyDx3Hb8FCoCVnhHOxyhmeJa7oTaFlvFc5P0T 7K8YYpfCQxzKsNwQRR07diznE1K+DxrG4fXXX4c/kxFi/mrp0qWmicsdH6NY+jvOw8cowwgOOANG hULcUFBQYF22cuVKaSKEEWhehBFumqu801wGfVB3pkMn42OBZjmZ2DPAFQOFuGfRokXMuLNW/IeY MlJ007rieggktcPiY4i3EBwj5BLrgTpaW5NHRkuoOM7zPUiUf4Senuxo84eTJ0+WKkBiEaTy5XJW FhN0nJMnNEToPtlQ0eKfUBMUW6wxfuW+FyHSIIfLHiJICIbIHt2cqb9UAVmrGQmEuVz4xL5DhA0h 5FRVyjevuHysuGSHSZgsdjSieRQbURC70h80Q0JEQSRdKC1jlUV1SBl6Zd38ZiLAWZEWAqoHx02P xkHniRMnWQmTackMOoVxtQxkuHuZBlY8sWgVX35RmxsHcmmrNQcTZ2HCwyflY1cA6AyIpkWsI4HA C+rheVHj0aNHd+7cGZmgDGXYv3+/9ZrzKwK4XtQ32bKxtIDmwoMSv1Al8zp6hsHEAqK/IADJSGnu aory79q1C8ocl2IHcYX1hGlLMLeZLvAs1E7sLwcj8/Pzr6AMQ5v27t2L6vt3ujcpIhxqXed94uXD LgXi8OHD3333XYLNEuhrQUVgwczkn1LAvX36IBo2t8xKDIRrqL5f02ExIFcUEnc/DwF0AXYjZfSQ dbOcrtibfRf3LtoEpoxFDfRlEGA4zQRtBTeKp6RVU6msZGG5+3kIYF1x/xB5pjXGPT264zfIIbKH GBpCZRHC4svbIHFH75QthnJm0Q3hVsm6AEQInZ5yLUDpqEOy0Ctz85tMgDOUlnQV3y8zFoeH3Qup UUjFk4lWFkOaUguflI8pFIosYP369daZb775hsNpng1Iyya40MV9x7SizIIroCJfVVwK8PAxxdUC Dx+7KgAuwby1LO6NrFAEIsPdoRXKxxQKRRbAnXOfePJJWfi+Y8cOJi3IXmpXEU6dOlW/foPadeqa GyspyizOnz/fpcvdlatUjcwRVT6muBb4WH5+fqVKlUNe76tQKB9TKB9TKMohjh49KvnlTZo0lbzw du3ae1J2yzK2bdtWpWo1lP+K5NAqwnHx4kXulBv+VlzlY4ryx8eAvXv3JssxViiUjymUjykU5QFF RUXz5s27//4HbrzxphtuqH/PPfe88cYbV3VwsGrVqpo1a7mvSVGUKRQUFFSsWGn27FeuYBk+/fTT xo1vTvkacUVZxvjxz6ETPZvFKxSKOKxYsQLqY22Dp1A+plAoFFnA999/7+4NpShrsN4mrFAoFAqF QvmYQqFQKBQKhUKhUCgfUygUCoVCoVAoFAqF8jGFQqFQKBQKhUKhUD6mUCgUCoVCoVAoFArlYwqF QqFQKBQKhUKhfEyhUCgUCoVCoVAolI8pFAqFQqFQKBQKhUL5mEKhUCgUCoVCoVAoH1MoFAqFQqFQ KBQKhfIxhUKhUCgUCoVCoVA+plAoFAqFQqFQKBQK5WMKhUKhUCgUCoVCoXzMxt/+9re//rXi0888 U5r1uXTp0skSXLx40f321KlTu3fv3rRp0+nTp1Pe6ty5c3v37l23bh3+4nPkNX/88Qee9dtvv8Xd 5Pz587jg999/T9yA455+Okdt9Z///Af3x+EpP/HGG2/gsnvuuUcVxsIHH3yAlmnd+s7Sf/TBgweP HDlyVbQS5B9aAF3Irm0xVaOoqCg/Pz9S6z3YtWvXmTNnrrgmPvDAYNz/pZdeKuV+SdZo5RX/+te/ aA9zqmWBIpcJfv7550DDniP89NNPGzZsKCgoOHv2rMctRgIu1bwSVYi8DK48c7+muILGJ9eIkxxX 3mAA+TnOQ4m44mKP6AbKp0Y7pY9//OMfKPmdd96lfKxU+di///1v2uIffvjBPI+wo2fPnvwKR8WK lVq1aj1t2nTwN/cmx44dQ+xVo0ZNuf6662o+9dRTR48eta785z//yQvQ35Hleffdd/HtbbfdrnxM +VgWsWfPHjy3StVqx48fL/ut1LRpM5QWupA7PjZo0CCcGT/+ufCbvP766/hJ27btrlk+lqDRrik+ lnUtCxe5q5GPwZlCx+vVu178ZqVKlR9//Ilff/3VunLixElyjXWsXbvWjIPjLuvYsZPyMeVjHtSp Wy9OeMwDIVxRUVHLlq3wuUOHjpGDU73vvRffNm58M1gWY6GUR+fOXTTaUT52ZfjY3Llzu3btOm/e vLLJxz777DOhYbDjKFivXr0qVa6CM0OHPmgNiuCHDB9xNGt22333DcBf/nvzzbd89913kXwMyu+y NeVjZQonT57sWoIs+uksWqhIJYrDgQMHECbWrlP3qog5SoGP5eXl4cy0adPDb7J48WL8pGfPnuWG j6Ur4Qka7ZriY1nXMlfkcmGUAvnY8OEj8Nyvv/46W8+lOMHJDhgwcMKEiY88Mrxqteo406ZNW4S8 1qNxHt/WrFnLOtavXy+X/fjjj6yIexk8eOnwsbTMsvKxsgNISPv2HeRo2LARqlm9eg3zJI5t27bh 4q1bt1ao8KfMLFiwwLrP0qVLKU6rV6/Gv5988ol1B/4QUaJ5Ei5D+ZjysSvDxx5//AnU9oknnyyD fAw0iTNdKMmJEydMX9ukSVOcHzPmcTn5xx9/tGrVmtQL7lnO79u3jxffcUdz07UIH8MxePAQ5WNl Gb/88gvre+zYsTJooSKVyAP0Wlw60DXIx4AEeWUwDpEz5FcpH0sg4VdLyusV4WO50DJL5HJhlAL5 GHwZrkF8mZWHrlq1ihSLAa40KSJgnAersWJlnFy5cqX/nt98800C65pdPpauWVY+Vjbx6quvoZpg SnEXjB07lswf6mOq/w031Mf5Bx98KO6H1133Z3j5xRdflHsLqXxM+VimfOzjjz/Gv/XqXe/ORJNN 1a/fQBwk80nA39zJrl9//bVWrdr4ds6cOZF8DMeKFSuUjykfU8d/RfhY7lCO+ZjCz8euRqN0RfgY AtbI3FdoDc5Dwt1H79ixw39PlA2X9e9/n/Ix5WO55mOnTp1q1Kgxrrn//gfk5OjRY3Cmdp26kdlP yseUj5UtPoZIZeDAQTfffAtqe8stt+LzQw8/bPExmMUXXngB0Twu6NW7NwiSe5+ioiKEa7imceOb u3btCiN++PDhrPCxWbNm499WrVq7F589exZFwhMPHDjAM23atMXFzz33fOTNJ0yYiG/vuquNxccq VKhIqw1qd/LkyWR8bNu2bXl5ec2bt2jbtt2oUaNRkbgoEJo/aNAg3BMXPzxsmLt0be3ategItLl1 /u2338Z5CYtNv7VkyRJ81aRJ0+7du0+ePNlacR7Hx/bv349CtmzZCoUZPHjIhx9+GNhN6Nxx48Z1 7NipWbPb8MPVq1ejC1AA052jNXBmz5495g9RVJzEYW2RgrBmypQpuCF6s0ePHrjPTz/9ZHYTftKn T1/Wt2/ffvj3s88+s8j5gAED0QKQATzaHOUVwChDnjt06Hj77Xcg/tiwYUOghTp//jxoPAoGTYFR QK/l5+eHKNGCBQvw70cffYTyDB36IIq3cOFCnD906BDOA3ITXrly5Uo00Ysvvoh+9Kjbn+3/9NOs CAqzbt063nDs2LHhxc6Ej0Ff8DgoKUQIsQ5kHiIER7hz585kqgF3ixuysvv27WMbukMwbGp27po1 a/AZ0p7u46A4FELr/ps3b8ZJCLZ1Q3QK7gO5Qjvc26fP+++/b/0wMCSC+D3zzLOdOnWGkHfu3AUP kqFcv4SztQsKCqChve+999Zbm7AFzEZL0C9bt24dOfLPhmrXrj0Cl4MHD7JJ33nnncBi+5Gy3eLq lcw6uXzM1TJYQpxZtWoVzMtTTz2F6uDmjzwyHGekI9BucDctWrQcMmSoZb5MkQsxSiFVgOuEj+vV qxeqD+oCLfMTEug+pZdpI4hQ8XnGjJlpuRgXEJUqVastX748ciyvS5e7zZMc2fTEuMS8efOsBJZ0 +VicXwP7ZSPAVlg/x+PYxR6zLEO0uCcaENeg+2bOnOVuCJEVExp4E1yG3udlKBVU8ptvvknMx6AO jz02Cq4NcnXffQMgY9auZhs3bkSbTJ8+49KlS/BK8J5oJXT0tGnTrfRUSilkTKQUoUhxSdoq7mBJ acpW9Wt9Yj4GIA6h5FCdt2zZwn9heTy/SouPoXYUPDQI2hwRC1zwhQsX0opDEPwsW7YM/Yvfokbo psLCwkiD5u9Bf2ECo53EEr579+5hwx7BT/DDnj17vvLKq2YmQrpOFpYWd4CAoekgNlAEMw1B+BhO IlJCa3hk9SrmYzfeeJO1kLFmzVomH+vXrz/MOpf2yjVoOPMmaCM4G35Vt971zMe9/voboPCZ87HP P/+cT48MKSxHxd+amYom9u7dywuEKwofg4ZwcAUBSgI+hoAbzow3r1yl6p9DMrXrMHPS4mM0K1xl TkPAER3TqL311ls4effdd7ueBucRRlh+Cz//7/LrkjV15JxmIlMkH4Ol4PIAlIT+FQcUzDQukdi+ fXuDBjfyelSTH7p162ZxXeYJfPXVV1Zsx+vNNeI4CYsjC/n+e+c6dSW4YS9Yx2uvzbEqiAMVYUeg KXDSUnjmoEsfod+h0in5GCg6x4OpHVIAdGWgEsFaye4ypNlu7MgrERrCevrVDYogT2SPoyKIHfEB vw0vdiZ8jNm/EyZMpORIaVEeK4YIVA0zqvjjjz+4qYBlQKi/1apfx82vIqU65HHfffcdL7BcBafi EYjLGfg/9gvbUO4MdmF6ixA+BicnMiDdgbqwjn4JZ2vDjZmr2COfG94vf//736U6lCI0FBe+mwG0 v9hxCGy3uHols06uTrlnYN7xL6pJOyPtU7FiJVCRuXPninGWDS3Mmpoil9IohVThxIkTtJxmYbp2 7erhY99//737XHMOKsTFhIMtZi6nQdTFm7MrYcnjQqLnnnseVyLip1IHTiEG+jUqtTVqKSvWDhw4 4DHLwPHjx7mwHMZTtjBBDG2ONWTFhAbeBLYIUaZ4MVYZYvnyy9P8KdmRxgdRL2UYtYMn5W1btmxl 0lfGuOAD4A98lpStT5++5t3QVohGLClFyMdCmrQ8pFU9Wp8hH5NpXjh6aBY3+QDT8P8kLT4mwmmW X/YUDYlDzpw5065de7mMH2AorInukB70FCYw2kks4YxReVsxMuBIv/zyS7pOVibS2VxMkOYYkBA8 yipEC4bOL6tXNx/zzOmLQ4UOrF27FjR669at3NELPWfOb4wf/xx3TCKJOn36NJkDuidd8uryMTyX s14QSki2Z6/hTZs28bdxCwZQMF6wZcsWi4/h85dffunuEBXCx6AV1BzYApQf7haMhZHNn1GgMRKA YJHplJA/1AuSCmdPt5GXl5eYj0GIFy5cCJKJe6IWYMI4OXz4CA8fKywsxGX8IfsIrUeW9d5773kq izKTn8Md0jTABIMwiL9Ml4+hU9q2bceQAjXiDVFH2hEEH+YcWmRq0KpVq9CD9es3wLPgutD+qALc BpRWJk5xnv4bf8FnUAvcmXIbN/tqTvThmubNWyDAwg/RdMzhwUPNMQK/EsEIohe+/fZbRAwePpZS 3VARlITlQayMyqIizz47nr81+VhgsTPhYxQzFAOlRS/Q/5liFq4aVlRBARBRJxCa4KQMcrtSHfi4 cFcxY8ZMnIEkcxcv9AIcA92b2RohfAzGENeANlOk0SlchIOby/hxnIRLayNiA4/Cb7mSNo6PpeyX n376ibXAHSCQaKg/y9O7N39r8rGQYrsIbLe4eiWzTuF8DMeIESPxLW4Og4mWkUATF0Bmikv2hYIm WiGgK3JxXRZYBco5mPBnn30GEou7LVq0SNiglaxhITJfMdDFBAKelGVGdCgn0TIMJVF4lgE9C8tv mXoA5JOd269ff7J6iASky/+6mkC/xgAdIZo7I2e6oUizjBsyNoXVJU2FueCZRx4Znl0TGngTOndU B2oLI4+Wh6ZQEqAaafGx/fv3M4KfMmUKa4cuI8nH/SUkY4zLofMPPvgAwoaygd/ypDkMwTZEjy9f vhwFg5RChkVKhY8Ftmqc1meFj6EwrDufAp5j7dSdLT6G7oNDgXVFMEnCHBKHCOtGd3BODFaIXY9i SFEDezCuMOHRTjIJP3jwIK3lzJmzYPfQ759//jknosEM03WyZJ440FywgRAwSCYH6EePHpOurJZz PoZWNj0NBItNIPOwMilsbl2IHiL19wf3IXyMvo0hOzfYQbC1YsUK95Viy5Yto8X33J/zObJOzORj AJy07IsazsfoU0FHzXEsSBW8ghkF4gxNmJUTgnaDxqIMko6fLh978803rTwEhhdozLgwgkGVtciV tArV9wzIffjhhxwgt+KPF198MRkfmzx5MumKpbfiy/2hDySN9pQZFALmEYkboGxAeKy9m5lf7udj aBDLKcLU0l6YM1ceJWrUqLGMG8VFioHqxpEkCJKVLDRq1GiLjwUWOxM+ht4xe+2dd96hbKSrGm5U gfriX8SC5g8hJDi5Zs2aOKkOfFy4qwAfRpMuXrzYvIwkeejQB8P5mJg1UUm6WI7zSef6+Vjfvv1S 5kkG9gtlFUbVbKgzZ87ceeddJh8LLLaLwHaLq1cy6xTOx2BazUmqrVu38jKUxzzPIACGVAKgcD4W UgUZPgDZMC+THeHS5WPhLiYQUBl3BJr+Rcb1ydgjPVH37t3lK9RaBuARU3om6wL9Gi5jJs7u3bvl Gk42mqP7kWaZ4wU33dTQ7G7aHNxTouesmNCQm6xfv55W3coEZvgBM+hhsK4RYODu5q6zp2RrFoo3 HmrOnEMyyd5nz37FGruRnF6T+Zt8LLBV47Q+K3ys+PImqDxmzZqd8vpkfEzaJ604BJEnSYU1ZwCn Y3ZiYA/GFSY82kkm4WxhXGaaYp6sUaMmuzXcyZI6mpkFZpzDUb9AWS3/fMzdz4O9JYsW6GNgea3L Hn30USvPITEfo5S8/vrrMrXK0RqE8iYrg1QxovXcn0mJYNiRfOzEiRNkEcJ5QvgYBwbctQHWqhVO 38EVufEEYhRz2Vu6fMz1bVTvJUuWRIYR0BCOVlrjCocOHeINcWcEZwf/F5yiIWV1u5WN36ZN23T5 WI8ePcweMWMIXimuKDL0obmHp7c8FssD02/GYY89Nsp6Ssj6MRpHVNwyjiDt5hRBWkoUx8dSqhvV yiqMxHBQkHSLnQkfs1bLwHNbHjpQNSKjCua9QGtkTI6ezEoOMYPjwMellUrhgjahXbv24XxMAmWL okDL0B0Svvj5mNXaHj6Wsl8oVFZhxGFDktMqdiDcdossbYh1ypCPWbtWwCDXr98A5+fPn2+eP378 uOWMAvlYYBVgn90ZnuIM9vMIdzEhoAmtXbuOycapPkOGDO3Vu/fatWvpfyFXnIWGHTbHiRBDI4BG mA7lZTvD3jJsff75CSlD3pR+ja8klZRF9BdHCsy1x5FmmVHyyy9PizS2stwuKyY05CbTpk2P9Kqw daA35iBUSj5WVFQEnUVIYzaCGVcIpYnbI4EuRgZlKAZgApZQiSuXocbAVo2zZtniYzIZAOoekiKb jI9ZwhkYh/DFfZMm2VsDgOsOHDiI7DG8B+MKEx7tJJPwDRs2cPpaODa1+1QJ0nKycCXQWdTXegE3 fgUSizZhPlGgrF6LfIyDzUKpmeQNczzlf8GU1pTJu4F8TLB9+/Zx48bRfXLZkqRykVLXrlPXc38u G5CNei0+Bixfvpx3ZiCYko/BYnLqdu/evf4okAbFWlJMvPbaHHMuKHM+xtVEYhmtMKKgoIBDm1Mc cP4QdedAjnlw4IcKbKVEJ+ZjEriYii3geOquXbs8oQ+rhg6yKgK5ZSINzQHHTd2Xk4TwMcgVE+Xb tm0Hx2kOxyZWonA+Zqkbh5yt7acj+VhgsbPIx6CJrBQdSbhqRFILxigyqUX1MTMYLakOf1y6fAzC +corr+LRsHVQUvaI+VLgkHxFCiRMTd++/RYuXBhJKnLEx6x+Qa0pGKJZcXwssNhxSNlukaUNsU7Z 5WMS6FtMHg1lpX4E8rHAKkydOjXyPSuJ+Vi4i0kJ2G0YTyhUyNqe4pK0c45Vp5yR4CK9atWvi5se CfdrHJIXQkt+a/nNSLNct2RpE6Td6h3OD8sL/bJiQkNuAuXCBdY+OgQXzLgGP84IIEDilJp75Y4d OziQ7edjzzzzLM4j0uW/zBJ3JcflY4Gtmms+xlQdHiHzAVnhY4FxCEcQ/Amo4T0YV5jwaCeZhIMx MpcbTQeLitjD2p4t3Mlu3ryZU23+JwbKqvKx/45Jxx1mAlVW+Jh4ShSAC0ZBBc2uNWdULICC84Jv v/02jo8B3JsEVv7cuXMp+ZiMPbs50FYU+PCwYXEjlAymW7ZslS0+xndxyACJFUbQb3kO6Ex+fv4j jww3D77ok2Nd7jZcyfiYrE2PXPLHhWqffvqpJ/SRBSFxB8dr44oduL/i119/3alTZ7kn+MnkyZPd baNKgY+xTSAwKflYYLFzx8fCVSOSWhQWFjL7heOyHTp0tHLkLKkOf1w4H0NbyU5FVapWa9iwEcwC BdsU9cD9FcFn5N30zKu05p1Kh4+JDrr747l8LKTYkUPUIe0WWdoQ61TG+VhgFTi4a2UlZcLHwl2M HyDqHAtL6xUXDD3dqXsLqJSbBBvIxyy/BsHmjincBpMJsVaWo2uWJcaIO8zh9qyY0JQ3IZWNnASj SloraT1GgBFLJG8RxT9+/Hh4jMsCyEqeOD4W3qo55WMFBQUkGEwYxpHyhelZ4WOBcQgnEtyVlm4e QUgPxhUmrWgnmYQjNoY/rXt5yxYYeTB2c5VpoJN9++23I2Nd5WMJ+Ri9wosvvvhlFOLGMjPkYzKG x1lpsvMjR47wt3EsH1bbCkQi+Ri+5TTa889PSMnHuNmUlSMRGQUyFz9yapVuXtL0M+djXHwljtkK IziRCCL9ZQw87yrguIg7wJOMj508eTIuNJTxNv/qGooubEFcXWhZ4oqd1hs50CyITfv3v4/59Lin mZ9dOnyM85PussxIPhZS7NzxsXDViKM0XAv+zTffUNRRDFdrRKrDHxfOx4YPH0Gphh2TdB1G2+nO j5kRw7Rp08UFmr6kdPhYUVER07qYRZaSj6UstovAdossbWLrVHb4WGAV4F8iWzIxHwt3MR4UFhbS dM+cOSstK8GXf7orF1xwr4K4Vfjhfq34ch4mwg8EiNWr13BT1FyzLF2GpovsHXeCPXMT6r8Jl9BE DjRQxz2LeSwjwMSWyHFwqgPoB+1eYIzLBd7mhhyRfCy8VXPHx1AvOnpYngsXLpCScWA913wsMA5h R7vvuTUR3oNxhUkQ7SSTcDTy+vXrEbSwT8GEFy1alJaTZT6afwG/8rE0AkTmK6Zru0E57u3Thzvh mti5c6cpYehv2O4aNWpaK55F/Sg9klNBQYwbTKL/MxcwRPIx6X5ELdwmwb9+jGMernexokCIO7c+ d+9APzp16lRzgMQMXNLlY9ydVkYK4/IV01pQSzBjxA09XT7GMb/PP//cw8cA7ppljqwQpGqyoLPY m6/Yq3dvf7G5Da6b2p7sDYkIWWjEzZSA0uFj8IuMP8L5mL/YueNj4aoRR2k4eIY2YS+LgsQFx4GP k1lZayLdchXw4hxqtQbyM+RjVtRuJliWDh8DuBXyunXrwvmYp9ju0Glgu/nzFdO1TmUwX9FfBYq3 S2AS87FwFxMHVIfK/uyz4+OumT9/Pgypm7nKPDEJ3Hfv3o3L3IXBRUVF3IfDHQ5I168VX37lFGLu VatW8YUKIbENx1slTSZDy5/5TTiZLBl9JhjBeyZ5LCOwb98+yp6ss7UC/W7duqUV47733nvuC+iK o/IVA1s1d3yMqbAI27g3IASM06cTJ07KNR8LjEM4hTtv3jzPNeE9GFeYTKKdZBIOQ8fNtG64oT4H 4AKdLOdIateuo3zMtlmWGw4MEMHEaBDdKU5OqkZC0m2tRaIQApxHKC9nuNm9O11uiqP4S84sVat+ HVcBWp6GORjm2qc4PlZ8OaWbh5+PMcPblQmelyiQkmdufkpAXmnIxCJw533ENNYaRy7Jc/mYtdEZ 6k6HJ5bRCiPQU2wKWRgtgGL7l+nTLMJnW6EG93Az+RgTzCZMmBg5RSl8jHzeHX7je8BN+yuhj7lX IerI/Gx3BZopfnPmzIksNpdVeCwU7g8Tgx9aJo+5RuZLBdJSosR8jF158823WN1EVyR8LLzYOeVj gaoRR2lOnDjBbDcmxJsvP4gMjgMfJzNp1igPAk3TVbCPoErWpmfcZjctPgYxQ3cMGDDQOs/EEnld aaSE54KPxSkd92IWGQ4sdqRsh7RbZGkTW6cry8fMLgusAgcf4REsb8VVIgn4WLiLiQQu45uRRowY 6dlil9rkDnp27tzFJBWsHfTXms+kz8X5uK4M92vFxrsK6W7cOYFIs8xXO1jvGuX4r7R5Vkxo4E0o V7fccqsVgnPnT3Ro+P6KoLuc3nRzKLjniuykEhjjUqjQ8lbK0q5duyzJD2nV3PExiAdfXWVq9+zZ rzCFyrMyKit8LDAOYbQMWbWuYa4vpTS8B+MKExjtJJZwiBx+aM3ZynoBWrNAJ3vu3DluvmJdBqPB 6W5aj2uLjzGYthLkAgNEWAqOtkIPzXlh2GU0qLVHqukpufje3KqyoKCAttXcCFs22ECAblK+Y8eO cT7a3PlHJqwhLqbVhk3hOrdWrVqbJs/DxyBe5v68ntaj0YQqmq5RXsll1oVpPB07dhIThhpxMAMq Kq0nSZsLFy6UqlGXzKE+0cabbmooQ9GIvdgs5oCWG0ZQK9Da5sRUYWEhatqzZ09P9jBUl0vSYRSk bOg45haa+91Tq5s3byGVPXr0qLx7RIaTYb/APOFyzEUpGzduhJaiX2TxmDnnZuVAkqYikjAT1aDe NWrUlHkkSClLCAWWYuMp3D7OM10OaWF2zcSJk8S6oZFpMc3F62kpUWI+dubMGdERKY9URJIcAouN jl62bBm6L0d8LFw14igNBxQjfZgr1eGPI6MAIRGl27RpEwdTIbH/N89TYqNA5Gg08JcDRty/O5yP ybS/6fVlm3V88Et41vkYdwOD3pkLEeU9wpLwFl5se34srN3i6pXMOl0RPhbXZYFVuLdPHw54S0h0 5MgR2UHev9/9Qw8/7E6VB7qYSEPHaA+c3D8kx3nOatWv46otcyAVJ8UTofWoZbBs8tZQ1I4TPp4F UeF+jeDAPKcU3H0FIs0yBJspu+ZUGyJI1B3yyXGfQBO6evXqsWPHfvTRR5m4D4TgtLGjRo2W+ATa ar3IPoSPAe+//z5DoPz8fEsg4QRlVCs8xuXGiV27dhWBhCtn55prDUJaNXd8jGwQYZ75ilo0Jtuw bdt2cVKdFT4WGIecOnWKXW9u775jxw7mecl7cQN7MK4wgdFOeGxjgXwPcaA51ELqi8aUdg5xstKz d9zR/NChQ+JBmJkMlb8W58ckQQLiDuVhFwYGiJQ5yjS0Du0I608XhY6H/Y176JQpU/hQ9M3QoQ/2 6NGDQgmPZY0GgdSRQ0NQoHV4BFwaTD9fd2B6BcooNZB71KBH+Y4F3pnv4AvhY8WX80lS8rFi42W+ bdq0hX1k9ZmJZ0aBaA2+zBd+evDgIfCdZImwxVaGEsVRXknOEJzDPxYfgwXETVAF9N2AAQP5UHSH 6HZkGAGdoffFz9HyiMA6deqM9sd9Us5T08Oxfx97bFT37t2h58xQMvkYghiGZbgtqgBdwrPk5etm fefOnUs7jjBi9Ogx6Fzezdp+GsDjuL8QwnQZe4YaM4LBebQA+oKNDHthNgIklk+BmUDj8xo2lz99 GbaAhgy9AOMC58Q9IXEfM8c6LSVKzMeKS3YV4zgxai0VoQKaSechxeaSD3RK3CvUM+Rj4aoRR2lk n093S8/I4DjwcUwJxlGnbj3IEj0HhdN0FdyemJfBknCAhu4Khzj+kHxFqK1oNAoJUaeQ4+nmXESk hGedj8lwidVQlCJzAVJgsS0EtltcvZJZpyvFxyK7LLAKcF6cuUL8BCMJsoHmpbim5GN8FSSux4Nk SVW4i7EAKeJDYXBQVPcwh8M5v8pxblAIWVVovURo+/bt9OnQLBQGXp5hYqNGjT1VC/dr5uACX24e GNsUX96+lUEeehDEmDEGPK8wohATyixNzz5+ge4D4TIHOtFTeXl5kCX+i6b2Z726RgB15Ek8F7KB DmKSEUJhc5A6PMaFlDJwN6WUtsJa+x3SqrngY1wu4U6zUDzoLs230uWCjwXGIcuWLaM8oFPQRPTv 5msbwnvQU5jAaCdQOC2cOHGCmcNoWHgEiAoCD5bETMUMdLLnz5/n1DoaCpz24WHD6C9wvRjea4uP mYNMsgIvPEDkyB+YkryyvWHDRuhdf7pFccmiF5kwYVeNe/rpyF99//33uKG5zRcuRuweuUfTqVOn YJ7E/VMgECK4G6/5+Ri0gtuLp+RjtES0WZT7RYsWMePOjAI5XIQQR67Eo6G6FkvkNNSIESNpR7iJ P0gLTb/Fx2AioTmwktL40Ddrdj4yjEDtcJ6vN6HmQ7XMiQUPVq5cKSwXHheiwvFRM18RgI3j3Cn9 a9euXSWr2AoO4I1QbFoQyo8bfxeXrElg4GgNDKPHEfHQgVGxYcXcaZ/Vq1dLsSE/Y8eO5TtGUy4n hT1FzMEhAMZACOxkOCeBEmXCxzhCIRWBjcZzOaJm7dWesthoEPQ7qu93+ZnwsUDViKM0MNb4LYi9 lcIXJ9WBj0N94Z6lZdCGsOlcgmK6CkTV06fPkMgDjvbll6ft37+f/8p+8YHrx9CALVu2EiGHlOIn FhOOlPBc8LHikp2spaFgRt555x0ul7XmLkKK7RKqkHbzRGYJrNOV4mNxRimwCjCJiDJp6iHnMFzg VDTmfj4GHyFEyJz/CXQxceMFcQdkQy4uKiqC+pBJCl2P3B4QRhiEXBwZrC7Ihj8wCPdrlthbyRQe s0x89dVXuCfLhr9Q/KlTp1qjDClN6LPPjreC6cTuA8EMCAwnEEg+UXL/XhQe4wOPzLet8mjXrr01 hZtWjHvgwAGRUpgC9Cm3ZTeXHgS2atb5GFwDRTHyTQ8iAGj/yCWL2eJj4XEI+K0MbKGJWre+M3IH /JQ96C9MYLQTKJwWYAEQq8j9aQGsWgQ6Wc7UwXLKOBR6c+jQB80Q8ZrjY5yD3rlzp2fRV0rADcPp WssGUgLCBA8NCfAMuJoXo5CR2/G5Hh0lyc/Ph9Qm2LgiAfBEmK3AV/TA+EIt3fwKi7zhmsD2hIZA 8/0uPBLocTwlwTboiBv27t3LcS93Pw8BokDcP6VfYX0hCWgZT3+hmgizEMS4q105RoXgyS9Ihw8f xjUJRALijfri0Z62ylyJwoGKQN2YHsB01n79+qdbbDO7o4yoRqk9Di1zoAR+YYCk4Ro0YIiBChRy KEXcQ/0SnouGEu/LpUGRA8kpi52jdktsnUoT/i4LqQIcQYJqomFBtGD2I7U4xMVkboIgFdY6Zxcw /igkippAElL6tT+HbGrXAef3uBiPWaaT9VNEjwllFuXatWuz4j7kMihOVmQeVd6xY0dIvBQCSinH YrjKsUaNmpF9GtKq5RghcQj6N6SJMuzBwGgnUDhdgI1Dszxz74FO1gxpsuJnr3o+plAkhoePKbIL mFeXojMskJW+CoUfmzdvtlwvIgOmkwUOFSsUZQGctEz53rNcAIy3StVq9epd79lvoxwAfNvaWwWY Pn1G4AuaFYprBMrHFMrHriH8/vvvjRvffOONN61fv54zY4iqJ016gfktca9YVShMcGFPly53y25g R48e5ar91q3vLIV5OYUiK9izZ0+tWrVBitx97UoB8+fPr1Dh/163U14xaNAgmIt33nlHpmE//vhj 5qEtW7ZMhVChUD6mUD52LeK9997jmgoQsBYtWtIv4oy7ubZCEYmioiK+zJDbbDRrdhu33sFnz8bQ CkXZwYIFC2RtnmcvuFIghOW+qbdt28YVkrASzZu3kKWJkW8eVyiUjykUVxKffvpp48Y3R65fUmQd +fn548aNa9++Q40af1KyYcMeuSLDw4qrXWdHjsy7/fY7atWqDVkaP/65a3a9h+KqA/dnhvROnz5D Z3RzjaNHj7744ou9evWqXbvOLbfc2rdvv5AlcwqF8jGFQqFQKBSKcgv/Dv4KhUKhfEyhUCgUCoVC oVAolI8pFAqFQqFQKBQKhUL5mEKhUCgUCoVCoVAoH1MoFAqFQqFQKBQKhfIxhUKhUCgUCoVCoVA+ plAoFAqFQqFQKBQK5WMKhUKhUCgUCoVCoXxMoVAoFAqFQqFQKBTKxxQKhUKhUCgUCoVC+ZhCoVAo FAqFQqFQKB9TKBQKhUKhUCgUCoXyMYVCoVAoFAqFQnFFcOLEie3btxcWFl66dElbQ/lYCvznP//5 618r4vjtt9+0nOUG586dO2ng7Nmz/utPnTqFy86fPx/5Ldoc3+Ia/ou74d8zZ86Y1/BBIb3Du5Xj fmzatBkEdeXKlXEX/OMf/8AFd955lwoq8cADg9EgL730Uoh727dvX04fcUVQVFSUn59/8eJFFQY1 +2UZP//8s/ZIMrzxxhtot3vuuSeL9/zjjz/oeS137OLChQu88vTp09oXpQBwsJ49e1JZcBw7dsy9 5l//+he/1eZSPqZ8rNzihRdeEEPAo26967t27bp48WJQNff6zp274Jrp02e4X82ZMwdfVaxY6fPP P+eZv/3tbzjz8LBhplfgUypUqPjvf//bU7A9e/bwymrVr1M+poKaFlmCmN1wQ31cKaJYbvjYoEGD ULzx459TYVCzr3xM+Vgg/vnPf7I7mjRp6p+BmT9/Pq/s06ev9kWuAVfVsmUrRkQ9evQYPHgIzigf Uz72fzh58mTXEpiWVPlYOeZjNWvWat++A44WLVpWqlyFDYjP33//fSAf+/DDD/mrd999V056+BiO F1980VOwxx9/QvmY8rGUZCnSWF28eBFhR6VKlTds2FDG+Vhk+T3Iy8tD8aZNm67CoGY/ixg+fASE 8Ouvv1Y+lhXMnTsX7Tlv3ryyxsdwrFu3znNl8+YtlI+VGlatWsXWBuPyXKZ87NrlY7/88os7c6p8 rBzzsV69esmZ8+fPb9y48bbbbudc2eHDh1PyMdj3ylWq4vzUqVPN834+1qDBjZFDQcCZM2dAEZWP KR9LSZYijVVxSV7fr7/+mpVHlL6x9ePIkSMqCWr2s4s77miO1vvkk0+Uj2UFHE984sknyyAfGzx4 SNxlmzdvlsuUj5UCZs9+BU3dvn0H/2XKx5SPKR+7FvkYcfr06bvvvts1yi4f27lzZ40aNXES7Mu6 iYePNWzYCH9XrFgRWar33nsP3zZufLPyMeVjyfhYFh9R1viYQs2+8jHlYwn42I033oS/latUPXr0 aORljzwyXDyv8rFSwPjxz6Gphw8foXzs6uZj0KiXX57Wv/99N998C+j1Y4+N+vHHH93Ldu/ePWzY IwjpcFnPnj1feeVVz54NUNqBAwdBD9n3ffv2w7+fffaZ5fC+/PJL3PO2226/6642o0aNjtTt/fv3 Ixxv2bIVLhs8eMiHH37oqcuGDRvwoKFDH7QmTH799Vecx1FYWMgzRUVFsFYPPfwwbtuqVWsETxs3 boxzzCHlhKCj6Vq3vvPWW5vcd9+AWbNmR66bAr744otBgwbhbs2btwDHQKwc2FMXL1786quvJk6c 1K5d+xYtWqI1ItNCzp8//+677/bo0YMdOnr0mG+++ca6BifZGps3bx4xYiRaoE2btk899dSePXvw 7aVLlxYtWoQqI9DHHXA+ZZAXx8eA7du3syXRlXF8DCXhQp1+/fpfuHAhnI9NmvTnc+/t0yeyVCg8 vp08eXJKPrZgwQI0yEcffbRt2zbIT5MmTRcuXGjKD26Cu6FJIcwzZ86K3IkErQe9QCPg57gMveBm 2If0jr8wS5cuhbjiJBztiy++eObMmXA+hvLg5pDPW265tUuXu6dNmw5FsC72q8a+fftQNnzrbgWB bsJXKHO67WaSCtyBHb1kyZL7738AVWM1T5w4UVySlTd79isQEtywa9eu+GyWHzpLNbfKBiHHyXHj xkWSJY+xKi7Jv8K/e/fu5b9oCvw7d+7c06dPo1ToR+j7gAEDoS+BfAyPw/XoPmhcXl6e2VweeMyv p/xi99BKKEnHjp1uv/0O6terr76G8x9//LFpIR988CF8hrlDOOU3d7DDFMLu3bujHdAavKElzGl5 jTig8FAZiAHCO3T6uKeftibbZUAHQUm3bt1wGf5OmTLl999/j2RcuNuQIUPRcbgn5FP2DUpg9hM4 gnSbOi0PKEATQeDR482a3YZfrV69+sCBA3iuuWLwtdfm4Ix7Qxh8nN+yZUu44cLjKGkcU8MF+Dxj xsx0K4K+RovBhKL1EJPgieEMGQYQP0F9cX98iOSEKWWJthc6dfDgwTFjHkdFoDLoIys8CIwiPAqY MvSiOcVXqDvMNa1uWnUx+Rg8OEvi7k6EauL8qlWrwvkYbFev3r3xARbYvQa2ukrValxKEMnHUqoq ewEdik7HTWBk0AJ4otgr1g7X4LfWzREU4Ty6LG55G6wuLmCoI8CD2D5mSSDzc+bMoczDiMEx5efn JzZQIfKZIJxbvHgxis0YoFGjxqyFpbwp+Rg8L1oS8okq4FnonZ9++skdGsCdf/jhByjyE08+2bZt O1QEPhq96T5o69atI0fmIcRFsIoyQ5vWrFmDn7/zzjtpOUQ6XMgAlAX3wQ1Tcs6rmI9t2rSpQYMb 2UPXX38DP0CXrED/rbfeku0TrruuJj9DQ9CLkbeFAFm7O+CA9Tcd3rPPjueHSpUq80P9+g0sm4u+ qVqtOotUq1ZtXgYf6YbsIlW8G/rYPP/+++9zUIeBGkQNkse71at3vZQQ8aLrmEPKiYCPBgjtU7tO XV4Gx+PaPkQt0sjSkpDpkME/6ACvxw+lMM8886zF2RAE8Cu0GBdxVaxYCXbfNE+08oj1eR+5G2QA oSeClf9W+fIaMJAlBsQJ+BgAI4VvTdNp8jH0Gq0JzE3krk0ePgb7gkJG7uqBWJCNsGvXrpR8jI9A yMh4AgdqxK+OHz8OG8rOFWmB7fj555/NO8C8SqNVr16Dn8F5zAA0sHfiCoNrYOtFXPlzWKi6JaVK ycdQC7gBPjEumSSlaqDled6KPCA2bGSJbgPbzQQ6kfWiBJrlhMB8//33LVq0NMXyT5Hr3Vt+/t13 3/GkxcfgxbmOMZIseYwVUPd/K8uWRLTN1RFmSeB+TLsUyccYIbH3aTFwB5z0K77f/IYYW7g0+Ypj VVbxeCXuD4ruN3cQQsTrlhDC1nE1uRkwpes1IoHHIXaXLYJwK5opS/wWLlzIVGeUp3btOjJ5bj0L nETsszgU+AVITgKz7yLEEYQ3dQIPKENg4talNRD44i+In1wG+x+5/hacAeeXLVsWbrigm64Qwtqk VRG4GBbSbBP6jpR8DFxFHCslAQfKbJqCEFmi7e3btx8LKbdCed5+++20TKVfAVOGXpyDMo+aNWul VRdrfgyM0fRrBBggbwLVCOdjsH4rVqzAB9Bml/bMmzeP/gvBt+tiQlSVvQBORVEUYcDxyiuv8hoW AC1mcTnE6zjP8Y5IcOT3q6++sqYleH/JTj958iQne9nyUgCEcAkMVIh8Rg7BpwwYODNmHXFkL5KP oe7oR56vU7fef+1GnboyKEmAMuH8hAkTqRrSKSiVRRH//ve/0wyKg0BH9773XnwA+U/LIUroIn2B SKB88rFz586xZeFfGc4ihGXEBvWQ/ga1ZdPD0Bw7dgx8/fPPP2dADyvjH+325CtCcGfNmg1zACuM kIISb4YvhYWFEGt0DxSYo+Biwt577724h8KS4oLHHhtlngT/NqkLaAMNPZk9ijRx4iQKuszhhJcT P6HrBd+gz/jhhx/oRSBG5vj9Rx99hJMIsqEtaEYoG5SWZjcvL8/fWSRyN93UED/BD6FCOEMPt3Tp UnOsi8/Nz89HD4IMoMwUdCiJxcdwzJkzBzWFRcO3zC5AX6PNwZQgEiwhVfT55yck5mOjRo3GtwgB XT52+vTpdu3a4zMoWdwsnIePwSnSGlpuRpoCsl1QUBDIxxhqwxx8++23HKpEN4FTMYuSnYtm4Rl4 CysOwwHJhFqh2WFHaONGjx6Tbu/EFQYREgVy9uxXwHbwc3hH9ponaVOMGv3EBx98AE8D5ZItMU3P EaIaDMfx13wEPAROyghuYLtF8jE6Aw6OHjp0CNSCNh2S2ahRY7QwzuP+CI948RdffJEJH/MYqzg+ hgPuASdRDGiitKQ51+0+YtWqVeg7xNwIBdD7iERRF1QKbesJhgLNb0pjO27cOBRgy5YtNOyRfCzE 3Mm4A5QXsQuEcO3atSKEwscSe43IPBwEvjCqxSX5z1Qi8DoxraiUbAIE2YBxgF5wLMA0Gmgi/Iqi i9qhHdatW9ejRw+cQajKmdvwdoicyApxBLn2gBB+rtpFpcgDYSsQxfKhyfhYoOEqjslXDKwIDQtC NwSCsKLor0WLFklgB6sVV2WUgZEuZIwvR0HxKH7z589PS5bE9kJB9uzZg8YE1eTkM25ozl+lG0WY ChgYehXH5yuG1MXiYwwh0IkudzKlIoSPwbVBy9iD1ti3yADkhwUw+VigqkovtG/fAeYFurl161Zu CQs1IQHDSdI5c6IVRpXhime6L5CPcccjMM9t27ZBDCDDHAxFV5ozQiEdESifLsL1jsUYMWJkuvmK KHDbtu04egJxpbmgJoI3mjuxkY8xKxLlQfujkTkMZ+bEIiQj4YQGQV/QI2hAzqZafCzEIZqhC2KM r7/+2prYLD98DK0Ay4sgyUwikv3BZchw8eLF7kAIT4JaePi9P0Swhhk4fmAmntHeWeMc9Ctw/3GT 0eQ8iKJk4A1CjFgcJ7dv385hD0RmMBmSg8T4nmNUb731VrrlpMcdO3asNctM3z937lwpBhVp+fLl 5pVoZ8gf5HLHjh1xLQkNYWGs6XLOmIkyrF+/nmpvTUFwBB3WU94EwsBo0qT/4TAIDmSk3+UqqGZi PsY7w2ZZfGzq1KloST7UNeshfAz2grWGVptJqqgp4xuQMSZMhvAxhPvWgPqMGTNJg81xXNgX2mWx Ghx6lEkVM3JFd1C/wnsnsjAQeNq+CRMmmj9HC3AaLSUfw6PNcSzckGMBknMSqBqsPgps6iCoI06u WbMmrXaL42OWMHBoDceSJUvcEbvJkyeXMh+rV+96qxMZNqHp4h4BGeAckTXKzlDPw1EDza/f2Lpp RXF8zG/uUAZODFrT8uhQCqHwscRew4REb+KM2JKMZSWUB+WDI7Ni1tdff50T+3IGAbE1aVNcsjyJ 0QO7ONzsx2UBpHQEufaA3KIW5s6SZCaPJeBj4YYrjo+FVATNQv/45ZdfmpctXbo0JR9DGOqOafKk kIFAWRJnZ3oTGDHaXokm040iLAUMDL3i+FhgXSw+hsJw9gbcT37FCUlLFFPyMTgOfOZCAGtXDzBt ccdkgCYfC1RV9gKiFFOGYWRYa0lp4zjvgAEDzWRFUnpPYnwgH+MYk0l7IAYcY5U5usCOCJFPF2np XWI+xk6E+7Zs8rBhj3AGz/K21pwep0DN4IoSC45nGqgzZ87ceeddpgYFOkQ63EqVq0Cuisswcrif B6IoNMHq1av574YNG9giZhSFtj5VgsTzY1b6AYcQoKsyyEcHb037Hjp0iD8nlXcB2sMfSkj32Wef cfrFX2vKn6TXB5azqKgICgMz56bbMl1HdryhnWrW7DbXj9IvPvfc83FlW7t2LS7o1Kmzdb6wsJCp 0vyXCTDufhiwjOxTCZfJx6y3Kkk4a41AfPrpp4ytE/OxN998k+O1Fh+TxBV+G7fizsPHQLfwLwfY TKJLm8Wpbe71FMLHnn7mGes8rcPLL0+zztMucz4EtgaMGmJgqQNkGF2DDuKoanjvRBZGuIqb75d4 P49HH33UTSFIqRrS4GIiDx48yBEsCWJC2s3Dx6xXiFKVwIKsdaEcxkPxSpmPuS0JTeTPZdNC6xHk ojVr1rKqRnsCVxfX+IHmN93Nk+L4mN/cwcrxMjc9mHMyEogn9hpuyN69e/dIuXVVycQPP/zAokoK NLPL3HEfxIiyfiawHVyEO4Jce0DGeW7j8P5t2rRNl4+FG65IPhZYkSVLlrizN8Vh+3lMmTKFLt7M RkHxIGmSLh4oS3GOYNGiRZHFSxZFBIZecXwssC7ufh58X7CZis+ccFdo/XysTt16tAYV/5w1rGKu e2QL8BGUnJT7ebiqGtcLdB8y6EPPbnpe/CSlZQjkYxxesRgOWASeJWQvsCNC5NNFWnqXmI8xQeCD Dz6wrhRnKg6LfMxKYhSPIDLAPlq8eLF1w9Gjx+A85Dkth3i1bEWWNT4GEVm6dCn0Z/jwEQMGDAT9 5WySBOu4gPsigM6OHJmHiyPXSWfIx/j+BPQl/2WOWdVq1ac44CS1hy7TIUnKIsoc6XUQMUDicRmc MWrdqFHjEEtqlZNzLw0a3OgWY8eOHaQcZraAtSSXeO21OdZQRKRmQsn9Dc5cTXfFJMBcCBmjjeRj sESssrUaFZbLGr5Kl4+x/GbiL/kYFRIqF7ezYko+xglDvkK69733ygWUWA5urVu3LjEfYzgOU2IJ IQd7+PomegURicx7J7IwHPkDJ3F/npiPPfPMs5Fy5VcN6VDZIYOybWYwhrRbOB9joqYbDHHIH2Hl FedjAOdjt27dGvkIxkYgLVaDMICoXKVq3JRRoPnNER+zzB3awbRpHj6W2GuYuP/+B6jXVqNxNQ4i CSuJYOHChZBSyAOElnMyIkuwGJx+8Yeege3gItwR5NoDMo50FyUm5mPhhiuSjwVWZOrUqZFbqIfw MXB+BtkNGzZ69tnxMPjuG1ACZSnOEezcuZO1yEoUERh6xfGxwLq4fIwT1GJIyYHvvvvucJUkH4NS mwIwa9Zs0UGOSnC8Jm4/D7+qenrhrrvamHNWly5dYiQjKYuci7a4VjI+Bhlmnnzbtu3QxeakYrod ESKfmQQMifmYjJVEZqzQo+3atcvDx2DVZeUIb8hGk1/F8bFAh3ht8TEwbFk2WqduPbQ4dJUNaibg njt3btzTT9e9vGgVKgctQhiaOz5GS+E5zIXjFhh/1ytJWUSncq2tuaK6sLCQis3kGag0ak3hg7ak VU7Ow0S+9kE0HNYH/4JOxE2CMSWjZctWcTV68MGHUr74uPjyCmBz1MRSBomYS5mPkRKbvpZ8rHr1 GpQiSUqxEtJS8jEm4Ikb4EwUN/CAPHMcCw2SjI8JPYg7OLPEhUwpvVp470QWhuGUOceYCz4Wohoy HXTTTQ052duhQ0czjSSw3coZH+OcoUSx1iOoAp7Ds31fiPktHT5GPYUTTcnHEnsNE7LMNfIwZ6tm zJjJWLZSpcqwVOgLRmY4OHYuyU7+nTAS87FwR5BrD8jxaSsrPhM+Fm64IvlYYEU4pWBlexYH73d/ 6NAhBMGy2AzGH1bU5N6BshTHBI4cOWLF65lEEeGhVyQfC6yLy8cQPXPNOVNguCLrzTffTJePoZxS CzMtGQyBu6HwW0Q7Lh9LqarhfExcAJekMuGzfv0G/nToQD7GMdBOnTpLw8LPTp482cyEDDdQKeUz k4AhMR+TbXgip+lo0j/99NNwPibN6Lozi48FOsRriI8VFBQgIEYUyyXXlpBZwXpxSfrs+vXroSTs GOiku8tztvgY196gJF/GIHJHUSH9FGUQMw7otm59p3x75swZ+hvE9+aoAOUj3fkxbvITmcdC0b/u uv8uluDqhchI1F32agFeypyOiANXMUX6aYZfkvdcynyMO3aY2WvkY7Lyp/jyWjhYavcF8yn5WPHl F54wTYKrYMUpJuZjIsCQxkgh5OIBhD5xTClZ70QW5osvvoiLCLPFxwJVg+DmHGh/aoqZDxzYbuWM j/FK2JzIRzCuAiGJM2j+NwGkNL+lw8e4pKFhw0YhfCyZ1zDB4B69HNliMkHEXDKEONwnKVKWTpw4 kXIZUiZ8LNwR5NoDmqkBWeFj4YYrko8FVuT55ydEztWn9f4xBPR43PDhI7ipA3wWF42Hy1IcE2An IlhiylmGUUR46BXJxwLrEvn+Men0c+fOoQwgRWm9sdDiYxBprrNiGjDbRPiky8dCVDUtPkabz5RF 7ik17umn/VUI52ME5HPhwoX9+9/HhabQL7kmsCNC5DOTgCExH4Mx9IwG0qPJMGsIH4N2MAP24MGD fj4W6BCvIT7GaMbavMHDx0zCw5UbkKe4VcXFWcpXDFz5bYHSOWrUaG5bbK6m5ezZLbfcapU8GR/b t28fy+lOQNNDd+vWjf9CpbkJrFtaUrWpU6fGVYcLXs11q5HgToORyWDUbdlLtzT5GBe/WXPi7vug oX6kbQjsrBUmIXwMHzg2BhPDQUp5XGI+BtBufvvtt57fcliudu062eqdyMJwgB+Ox5W0bPGxQNUg OCuIQtLrW9Ib0m5Z52My2mf9vBT4GJ7In4sfisxXNHfnT4xI81s6fIwLBeFxXfYYx8fS9RommA5k biAeCQ4NWFPrrixx88PIvKPM+Vi4I8i1B+S7ItytIF0+xpQNS69dPhZuuIq9+Yr+itCeuEtxkr0P Gp1OXipJGYGyFOcIVq9ebY5EZBhFhIdennzFlHWJ5GOsCGwp5c2/RU1KPgbAiXMzPY59N2rUWKag XT4WqKrhfExGez/66CPItskf/PNOVvDj4WNmVgi3oFiwYEFaHREin5kEDMUZrB/jDjRu2gKpmuxG FsjHAOiIOS4Zx8cCHeI1xMfoks39uOnXmdUt8orL4EFNLl5sLOOLfHm0FSKY28QFeiMIAaNqN4EN P/TnnEiIXK/e9ZwKN1efS96qNYjLtPt0+VhRURGHW9wNiLkpnGwTzyK5e1tDMxm8yrbdLriNT/Xq NSxjwa1KmjdvYVYNVbZigq1bt/LR1v6KpcDHYOa4IdugQf+zybXLx2iXKXvWKrsQPgZwCyxmXZt+ PRM+xn1aXccJgRHBkM2LrZ3B0IwcgGR7hvdOZGGgEeQGljc6e/YsJTBzPhaoGgRf+gnjyx26zI1x A9st63wMTcGfWx0xf/78cD5mbbAZycfchD3uWIOIX1ZsW48ANWVavJupzzQ2j5UOMb9pGdvEfAyi S2Gz5rhECCUQT+w1TCDQYb+79M9sNPaR+doPCRxNWeIyFWt7UsTTDONY8sR8LNwR5NoDcjFn06bN LP7DndBMPoamwJkOHTqal8Ga1a/fwORj4YYrko8FVoQLtHA3Sza4+s7Dx3B/uDM0vhVTkn82bnxz WrJE22sFRcJyZXPODKOIwNBL+JhEsWnVJZKPyQskmWTuzqOmy8eOHDmCf3FQv8wsGJePBapqWnyM 5p30JuUq7uLL2fWWHZDNLRliwVxDoqBEVscxq1ZeSRzSEYHyGUenA/UuMR8jpXQ3+OWe2GYCdiAf i7shX6QmkhzoEK8hPsYYGoxf6MqhQ4fIvM0NUrhZAiyFGabPnv0Kf+unRhyKMKeGwx0e1Qy2w5Tj wsJCSH/Pnj1TpvcwOnffHyfKL/7m1KlTzHYzBTq8nHzZNPTN3IyehYf1MeNUvqmwY8dOEjOhFlwb Bhth7i64YcMGlNMceyPNGDx4iFx27NgxDmTOmDFTYgJOlYwaNVp0GHrCPjXn8UuBj6GOH374IU0/ xMCadojkY9K8VlJ7IB9bsGBB5PsQM+FjiBI4/26WB9EnjAssqXQuYyDEItAgCWu405S0SXjvxBWG SnfTTQ0lpRP3kfdFptzvPiUfC1QNAZcfuCFdeLtll48VX148gzKLmmzatIlLJmTYojjmZc2usSqO f/+YuRC0oKCAr+Ixb+g+gou827Vrby4bAHWsUaOmZ2louPkNN7aJ+Vjx5S3FUF/ZhdUUQsmuCSk2 PPHYsWPjNnfhWBVHW0HsTfOIn1SvXkPSomhMOnXqLFuGoL9k71bxbtzRC60N6ypkjGkLuJj3T8zH wh1Brj0gbsuwHgxQPAhElJJs7nfPiBB6analvLnY3Jol0HAVX96135LnwIrw3SfdunWTlkGsL4uL PImm3N4APzSXwXCLV9nkKVCWaHsrVapsxp1oClozsQMZRhGBoZewaGtxcmBdIvlY8eVtaTlpae6y Ax8N+yY7xAbyMZnJYbuZ2/+6fCxQVdPiY0ePHpV3E7uvIXVBTgV3IGEY7iAv12KgAjnndPrEiZNk XANl5piL7F8S2BEh8hk5xBOud4n5GIwwehPibUodO6VChf9bPBbOx2hmcU+TdTNAshbshDjEa4iP wVjIYmtEVCQwVapW42iWjOedOHEC5oDJ0+ASkGbSABzz5s3zP+Kxx0bR2yF04/BYuDeCz+bIImSl R48e6EioMfg0iiHzxR7IGzCtnaZwW1aHu2riMxfRUtNS7krslhM+j8ENmg4FhvJwwBXGzsrXgqXj ZBE8E0wY6Bl5kfUqZBmqMTcIhtow3kI4C7uPB9EG4YNpUvETOmPcMy8vD83Of++//wFzuDRHfAw2 6LbbbsfBSXAe6DV3a+Y4PiajtmhMeSFbIB9DT6EALKq5sWwmfKz48l6CNAqQZwQN9B+gW2IlEVKw RmhtWBkUlUoEOTHfTBLYO3GFgfXn/oQQLXhZUHQ8BRrB8mTOxwJVQ8BErMjN3ALbLet8jNsqcIkC mpf0jFKRko+5xiqOj3FZNjsRvpZJLCieGTK6j0DIxeASjxgwYCB6mdYAMrBly5a4vgs3v+HGNhM+ hq5hQGAK4Z+bXpe0ifCxkGLTsHj2+qd7ZvPC7kFyHnzwIZpBlEECRy6tZL/AU/ACCq2Vd8CoBaXt 1asX2p+xFMRD5pYz4WOBjqAUPCCDeLYSpKJ79+4oEnXZ5GPybjRG/IgXudEC/5pDWoGGq/jy28/w LJRcxiwCKwLHx1QRKB3UqkuXP+2PuBIPH9u1axc7HU3dr19/CAmn+FBrs+VDZIm2F/dBUREpohM5 /2+llmUYRQSGXsVGuibued99A4Rgh9Qljo8xYmaSoTu+5qaMpuRjVGQ3C8blY4GqmhYfE26Dw118 7gIembETJBBiBveEvqaPMPO9Yepp0xCtIeLCI7gVITTUTFMK6YhA+XQRrneJ+VhxyS4sHG6AoR49 ekzPnj0pzNa7qgP5mDBezsZDxlh3tpLJx0Ic4rW1vyIsIDN66ThhGtBhHOIyt19HdAvd4MJNHgg+ Qma6d+/eLZsIkfKm5fBgfWBT+LIFii8kxrNEwc2NgZy5SxWhchBcvhuRioTIkj4s3V2JzckZ7nXL A6Y8ctPVs2fPPvHkkxx6YZtDEAsLC63xHhhrCKU1jQArMGTIUIo1V0hPnDjJnZ9EUIvYl3MCVIOn nnrKerVXjviYHHg6WBkc2OrVqyOXDXj4mGR9QFfpgwP5mFyJZjFPZsjH2AIwrxQY/IXVmDp1qrVy AEWChEv0gMACPMFdKh3SO57CIBqGNZdtmu64ozmcK2OdzPlYoGqY8RwkGb7NyvFLq92yy8cgbK++ +hoDSsohakedTcnHXGNVHL9+DFXj4KX4dTAQD+GRQXQ4JPpUOh70Hd+h50Gg+Q03tpnwMdYChkiE EJoONbS2lwwpNm9u5S+4gHns1bu3PA4kCuGRVc7ly5fLg3AldATdwUlLc1doznWQpVM8EG3LuE+G fCzQEZSOBwTDlAaBfMKkMH3AzFfkMJ+5gxxCLgTcNL/WU0IMFwfF5IbmrE5gReDyQDxoMWBYoB0I atn1/o1YcNnAgYNI53iAV7jDHCllibZ33Lhxr7/+urhpmD5QC8uRZRJFhIde5nSWtVNRyrrE8TGJ rc3ZD3Hi5q59gXwMnUtjuHbtWj8fC1TVdPkYzbJnh2oLIH4ci2GICIGXtcemy4b8QJjFm6DWI0fm SQpMWgYqUD4jfWKI3mXCx0j84KnJylgFd4w1nI8BL788TdQHPhR6wZd3W9KV0iFec+8fKy7J1wSD D3k/DEL2nTt3prUhD7wyhADiHvLKBU8JYb9S5ii6g0BxO/6RGuGe/tn5BOWEd/dsXW2qGZ4e1+Zo tLjKwvbBica9DNRkNXv37sWVaTWawgMKTMpl5WCz+/fv9+9YkGHvQDxQEn+AknlNs6Uage2WRaB5 D5Qg3b0QUhoryz0gkkjXLsnQ4HfffRe4rUW4+c2KsU1LCIWFcvDYTNVLWewZM2a6oyeePoVauS9D t6gOimTOjccB0pis47LuCHLnARkFws5QGNz9PMw5WHRQiD0JMVyQakSoCKrk9b7pVgRuMXHvwLHi 0f53jntkyWICiDJxpceMZGgqA0MvCBI6KHKhaYheRIyj1a4jObrWeF/pmOhwVQ0Bk6Fk4UYg0Lko g9sIkTIPo+oXyMCOCJHPKxXOQZghjShhsl30IiNVoa9M2nz11dey6BDLJx8rl+AAsPuacIVCoUiG q2W4LqdYv369dYa7m1aoUDE8nkOEweyUdDfhVCSDh48p4vhYuQTnzVLOpVwtAO3nhFvgLkGKXGPz 5s0Wb/ztt9+YaeLZte6qhvIxn6dn2HT77Xfo7JBCoVA+li3w3RtPPPmkJKnu2LGD2Ur+TCcL+fn5 lSpVTvmOe4XyMeVjWcSePXtq1apdpWo1d1+7q5SM8c2leXl5Kr1lAdu3b69cpWqXLneLgB09epQL /Fq3vrMUEjeUj5UhPProo9w2oEIFe3GRQqFQKB/LBHCusu6lSZOmsiKoXbv26Sbh7N27NyuJMQrl Y8rHUmLBggWirbJD4NWLCxcutGrVmu9ovuGG+rnL3lekhaKiojFjHqeYoV+aNbuNu6fgs//dj8rH yiG4Frlbt27WOy4UCoUiQ6xYsaJx45utFerXoMedN2/e/fc/cOONN8HL3nPPPW+88YYyqzKOTz/9 FKLbr19/bQoPnn9+AlrJfIlWucGUKVOYNDR9+oxyME0BPlahwp9b8gwePCTlO6AVpW9tRo7Mg7DV qlW7ffsO48c/V5oLyJWPlRXA0FgbnSkUCoVCoVBcy0hrJ7ayj7Nnz5baBiQKhfIxhUKhUCgUCoVC oVA+plAoFAqFQqFQKBQK5WMKhUKhUCgUCoVCoXxMoVAoFAqFQqFQKJSPKRQKhUKhUCgUCoVC+ZhC oVAoFAqFQqFQKB9TKBQKhUKhUCgUCoXyMYVCoVAoFAqFQqFQPqZQKBQKhUKhUCgUCuVjCoVCoVAo FAqFQqF8TKFQKMoXThZd0mIotGdVGhUKhUL5mCICZ8+e3b179759+86fP6+toVBkHct+PPeXd38+ fv7KR5//35Ij03af1h4pT/it6FLHNSdGbP79qiu5SqNCoVCUFT4GDnAyAKdOnfrT8fz2Gz6fPh1t wS9evMiLz507JxenxB9//FH+eqVp02Z//WvFlStX+i9DSz7x5JMVKlTExTg++eQTFehSQ5MmTdHm n332WVkr2K/nL5mHZwwb31gXW0fkT4+dvbTpaNHqn87/eOpi5uU8n+oeZy4U+2tx8NQFFKYwVWFQ Wly27dgfuGFawK/+Mv8//+/9I7+ctR9x5MzFrw6f/+aXorjSuU169oIvLvf0Bb7FQ25beewv8/7z 8q4rFgSzO8zD04Mpa+T+5MKl4r0nL6w6dH7rsT9OX0hOgPnouDvgPO6Pnv23IzaXilMoBY5z8VWG kKRVaBSw6Yr/6VOr0VIqCC+LrOiFywouMn+yyC6/dOi5VA86e/lKynBZkMZMcOLEiX379l1rbuvg wYNH/n/23gPMqirbE6/X7/W8/mbevP97M3490zOv53X3p2JAJJhazBjABCogShJQQcVAVDF0i4oK RVGSJFdBEYpUIkhSgmQESZUlCQVYmaqCyvH/O2fdu9m1T7j7nntvUcBa3/rg1rnnnrPD2mut395r r52Xd/nVa+7cuTDHzz//fMA7q6urk5OT4W1G7hUXhTzX64ot2GWIx0hGA3K3bt1x86hR7+Fz69Zt cnNzrY/66qtp+LZFi+tSU1PxZ9t2t+g8edu2bVcsHnv//Q+oETp1evTNt96idmO6kvEYXCV4SCon ZP8xKe/NH8/llDXSietPV9rcLPE3Jyvk+3/Mr37k+7ON7lmQHZ1S5iFqaf6xCnrC0l8qXW6Dj/iH 5Xm4DeW3fht3pDxqQc6FwizMwWOtt607XXnVsrwLt8VlD9lzXjPUCjAPdYxKzPnlfK3ssi8+Xvk/ 5WfOzWm3umDZLxUK3LVv2MScu9YWrspSK9762wKXvrjmm3xyvv/70lxUAVjiogjYyJ/O2xRvcW77 tYWKtGjWSO7rTw+WoXHke/DY5LNBz7j9XFIbNdf4+Wu7zylfFVXVD959Dg0oXvF/k/IA/8QNv5bV uQ8KcKwFgQA1ofc7YnTEZZ+vCWI8jNhrtOf7+0rdGi0xp8umIoix7ZQK3bMtR5UH4MLHNxQZ3y7K OXbOJ73/H4RnTvaMn8vFbaP2+Tq07/YS96L6njYn+4vkMgEFL640eqaamprbbrsdCnzjxo1Xjs3K yMhAla+/4caioqIrFo8NGjQId44Z89llhsc81+uKLdhliMdWr1791FNPy0zLNR06PChffOeddxrM Ja877vgrvn3ttcGq35OVdcONLeVu69Onj/yE9u3vwrctW7ZSXnfw4MErE4+VlJRQU8+bN+9SrOOu Xbt69OgxfPgIxmORwGO/X553/cp88LXf5MMh8zl283I2Z1dZ8RjdaeUt0s0LgaDiCYPlPLC+sN/2 kjvW+BzHm1YVVAUz+ZVXXidwlDse+9v+UrrNisc+ge9ugitAxOF7z9NUvewsEhmhhn7oOGBHSc+t JeSp37m2QMdrNnz3OdmLjzdCGoBzAoY99F1h720l16GRzSsxqWVWX1n0Bfg/v86jAoCf2FgkL6b4 HPHEHNu+eH5rMd12sLAGtUabX0w8lnBBZlA7UaNHN5ytbwi6RuTZ37a6gDr0T1/noUmf2lQMmEdX FKDrTiiAkEwFj6G12/rRDsqGfrzG33ECkhVW1N+/vtCJCcjJ0GhfQfXrEBJpXkAfj50G2o83AKGL GPxuSa54MlCZsqjogsde2llCPfVTQbW46ILHoByKnScpjKL6Qaw8xC6uNHqmuro6KPAWLa6DGYrc W4YNGw4bt3v37mZiXo8fPw4w1qZtO3hilz0eg4PUwySlsiNHjsSdkyZNbuZ4zKn8jprZa70ibjKa a8EuQzxmpZtuuhmt/8MPP9h+u27dOlrSUeal+r7wAi7ee+99FRX2pnfGjJm4AQDsSugVHTwGIIp7 rrv+hktUtwLJo/yPPNKR8Vgk8Jjin6UW1dy8qoCWMs7690H58FhcdsDHHjpbQ95Yjy3FcrwfnFEC e0Htfun2Q7FwMV3wWDJeGp9ti8fgOMJ9xPUlxy/8POGoueY2P1v4rPiP1lu6/1AsAgVTimrot3FH yt3LmQvcODcHLrvspa7K8jUaXicHH36L62ZpE/1rdE6+cm19w9SMMsIwnx4sUxzxTw4Gjv4CkMOd F2VRgvDY3esK5YtA41+mlZGEjEvxUqOuJBILcjZKlaqs8+FhYOmTpbphptMzy4V0KXjM91Vc9v7C aoHQ+mwzcMt/WZIb8Mnbc6toPU1c+Ty5zPeu+Ozb/SBQH48NNYH9isbritZGg7TPPVIBZIXrt64u kMGbk4x9dKCUaqqsqrnhsTnZUzIce+rjg6XiNmXK4yJKYyhUXV199uzZiL7i4YcfuVj7CJzMK7wF JxfrMsNjBQUF5GoWFhaqE4KeIjabGI+5lN9xorO5RqJeliGylwMea/AvX9599z1iI9mqVasCBh8y HlNo06ZN1IyXaB0ZjzUlHgNll9WRS7fYj2H08RgtONy33sYw4Gn0kGK9CEDCM2Li32npA05ny1XG 2sUzmw1P/T+/bqTQDe9/js2s/F9WGD+Z6ncrj56rpdbYkduoNV7ZZXj5LwQK0HrXdFUXNI6BfHmn 8dvOG20Cfsi1RYHdfWWiseTKJ2R7QC/fnDSQ573rCptewGzxGNFwM/TuD8vzgq3R5uwq224i7Pqn r/P0Af+pUlPIE7JpvXRwYzz2/NZiqxjnV/gCFANuQXxsgxGsO1MCMx/sK4UkT0ovw0OO+IWtVA+P FeC983L+fanqqTg1miHM5iqcDIdsZQxwiy7OO6oOLkc8Zi5F/unrPKfB+Bvzhn8y/1Xw2EWUxmZO zRCPXa4UFB4L1yuaGx5jYjwWNB7Lzc1t3boN7vnkk08bzGVZiuQeNmy4y2ODxWPz5s0bOHDQypUr Dx48+Prrb8B7TkhIuGDbjh595513OnV69MEHH3rttcHffPONjRGqq9uxY8fYseO6dHmqY8dOuM02 8ADDZsKECc880xXQqFevXmPGfPbrr78q93zwwYcoTGZmJl7U94UX7rvvfjnMEnD01VdfQwkx1MeP H19eXu6Ox5KTk/E0vBH33NjyJnwGL1q0SL4H7Q/ci9pBI781ZMjXX3+tPOTHH3/Er/C6/Pz89957 H7dR++/atQvXp079qrKycuLESX369kVpX355YHx8fL2RUMBounHjop999lkU+IV+/datW2ctIZ6J 37744kv33HMvuuzdd0edOnVKfDt79my8AtdR/latbqbynzx5UtyQnp4+ZMjQxx9/Aj/v3bv39Okz dKb08FJIVNeu3dAR3bp1Hz16dE5OjnzDzJmz8CJrX//973/H9X379skXz58/v2bNGrTMQw89TFXI ysqyxWPHjh1D/3bu3AWt/corr2ru4sNtEJXnnnsOpcW/ECG80XobZADN2KHDg3g4PgQ07S54DEQh YR/4N6to4jFjD5X5TDl8UVBVXQMtN63MCtxHJdX1hucXl32gsOa/L3XDYxNSDbjy1KZiWvVS8Fh3 czllzCHVZ/3QjG/s5wdaO8wFjai5OUq2A4p1fOR7t9nxoqp6w7OPyz7bOK3i/Wb2hdd32yxKb/y1 Cg7r1St862nueOyX8z73Xezt0cdjxpPNZck9+dU6dj1EBaWJx1B9EieRGUKzRugv2ipm++2nZmdd 23izmTtkmpJR9oL5TAWP3Wf23aeNy2M0prlWude1MdOLa2gvlrwoKq8VB4vHKBZ3yJ7zmngMNC6l jEIZxRKZVcZWAB2ZC5WfHbJ5ghMeG7jzXNR841e78mwaYbUZ9AtIZoT7WvCYpjS6W+SzZ8/GxMRA 00Ln9+8/AAbImi4YVyZPngKTdO+99/Xr1z8uLg42evDg1/FYygEG2rp1K/6Mjo5Wfrtw4UJcT0xM FFdg73Dl8OHD7gbRV8fqavwWBhqDqEePHqM//th2D7zwcMiowbqR04LPU6ZM1RlrOp6JZ/N65swZ fAYpnQIrc+7cOdS9Z8+eaFu08LfffmtbL1T86aefgU2EU7F9+3Z64EcffeTS72hM3APruXfv3uHD Rzz66GNPPtkZNjcjIwPfwqlYsmQJzD18HpQZ1xX4MXLkSPycbhaE0lK9hNGUwdK2bdvwFSSE8AzE CX+KmVN4kvhTVBCChz9pQw2E5KWXXoZkQk/GxsYKoXLHYzpdFpS74l5+J/lR6iXuPHHiBEr44d/+ 5u6iHDhwYMSIkRB7uLvoMgjM5s2brY5lQC/L1nW3Nvgbb7yJz1u2bBk6dBhK9cQTT44a9R4ertN0 EFfcDCmCzMAFXbp06WWTLOQi4DGSe9xz7bUtUlJS0Pf4fMstt7oHDwSLxzBCcD+8edKJYKGjIb60 V+36G24kZAiGRqitbRQSAwmmr1CjFi2uo8+EIWXpxHigr0QCkjZt2ynLJuS7QwqVNCRQRlBw4mKL 666nOa12t9zqgsc2btxozWuC0iptRRWk7gBjHMqRjUBotM2P5vBEzpXly5dTghDoTUqvIl6BusNo UYvhyeI6bKdcvD179tAuQfCtt94mSiLQLFS5tfyQBPp2wYIFdOWaa64VhYeRgFvp0t3AqKKjb765 NX0AWEWBxT1wAnARVkf5LawLrgN9XXCzysuhleghQkIgMzIcoj6FLaTXiYZCJ8LwuAsnHJHrrr+B bm7Tpi39sH37u5Q6vvnWW6L16H4wDIaL9nHHY3euNVy9Yf6lBk08Noum2xc6qt3FxysnppXpYIOB 5uLSu/uMArjgMUAUA+PNz84uq7PFY1SRuUfU336VYRT1Af8CiIEVzSXBtacaWVbaNTQh1Q0nrDBn /YFglesUY/a7JbkB09+74zED75nfitg5fTwmlvjkPBBOVj8UBRUUHvvBv8wlAvY0a0SLM07BcgCu kC6XUDpJDo0ua/utsTPQFo8BoliXVWl5J2pBjns2R3rg3/c7NniweOxqcy13oyXMz6XRAP8oJlb8 SpExI6LSIZGJOx4btOvc62ZoaJ9tJU4o9+ODpRRprOAxTWl0schFRUWwRKTzbzFtHxj+luzqQTfC C6SvWrZsRQYIzjFdEX45mY9nn31WeTvlvoK7L66QkRUGwskgkpmGn00X8Svatg3TJhuXRhL7yy9W Awf4FHCs6XgmoZjXn3/+mf5UOgU+MRlB2dxPnz5DmUD861/vlB0VtAPAMD7gty79DtCIe2B86eHi FSg8wDA9QTwTfNtttxcXX9hZSpP1O3bsUNQa3SycRhksATlbW2DmzFl056uvvoY/v/zyS/ozOzub jDvFbaFS8EvpJ/ABZIRgi8c0ncmg3BX38jvJj1IvcecXX4ylgskuyk8//SSXJykpSXh01BFwS2gP EQZOUF6WlWwbHO08adJk3xv9Bbv99jvcd98AIZPEUgFEmYHKaLWA8ZgXPIa2g8YkP5sadMWKFQFB tgc8Bn7ssccxkPbv309zSFlZWVAEkDn4xNXV1bKCW7x4sfK6O+9sD1GD+4thiSs08FatWkX3lJWV de7chVQthIzsCjQ+beuCUlYGBjnTEH2MYdI4wAAkmtOmTcdvKyoqMLTuvvseunn9+vUuFXSKV1y5 ciVNjAE8VFVVofCoAmnSkSNHKniM1OLEiZOgzWkKivAYKSPgCjQRFDElxqSR0737swCENTU1qMLb b79NA1KoRQwYGvxoh9OnT9NiF9qH8IY8ZmwDKk6ePEmDExivsLAQ5ce7SKFDAbm0BgkSlDs1O1q4 T58+pNzFPKsmHkOLoZtwpUePHrQmBjNG5hyyfeLECaVPhw0bDj2Ft2zYsAE4NmBIw759++iHULvQ PmhJdDq5IzClsookLY8WgGCUlJTgfmqcuLg4D3gsxx+vKGCMJh6jiXzNBQoX2mL66/++NI9WFVzw GNx9fDX7sOE12uIxype4+pS692zpL5XKZjOa0ccDBUjw+d9zs4+eczOZ41NLZex6YTYUbneCL0vH qqxKl+zm7nhMNL5YbwkKj9H6Ifxjl3tCV1BB4TFKFfg7aSOWTo3QgLSeo7O+6rYMWFFnrNLEZ6cV 1TQ44DFjjSu+ET4vqa6nfV8v7XQLXjWSLsYbMpNbXhcuPEZSZL3ZvdEoq6c49UuWMVTcyAVqBtM6 iaUTHuu7vSS1qIYWk5XA41OUySMuG43Q2dwqZsVjOtLoZJGhOWFTcB03kDcGw0FXgBOUn7dp2w6u BZxdGBroW+EBhwuPWQ0iaMyYz3D9mWe6kvLHsKKnweiQC+FEtvGKTmNNxzMJ0bw64THyrLZu3Yq+ OHDgACET+LuiVfFkPIoeCGOH9of2+PTTMfRbHTwGnjVrFrQQnolak5MDc4b6Tp48BXUhR4XmjD7/ /ItQ8JgA8LbxfrbwgFwmuHZ0IBPcUWB+kkkXPKbpTHpzV5zK7yQ/TngsoIvy66+/0mwvnoAhic41 ytO3L/1WxmM6xdbEY+T3fvXVNLwR5YdvQwBPLr+VpkyZSq+Dy4QGhyxh2FLh5aVvxmPB4TFjCvzY MYFuAcQDPtYbHrvrrruVNQcSIFotFTR9+gzCNqTR4LVQwSDE1hUzIcoxMTFkXZT1iiFDhtJoUQZG //4D5DvxLhobX3wxVpldo0kID3gMjju1qhJGiNa+9toWGABiGYrMD1QJNIh8J+ExqEU5HgODjcwA HiIHFmIkU0Pt3LmTrkBvQjvDmsrjk9LsglEMd4OxbNkyXLzvvvtl00IX0SZO60LQ5vR8MlFEsJ00 0SWiQTTxGJqdrLISJNmxYydZX1CfKqtVixYtIoDq0nGAmnijvJ4Jio+PJ0UjrgwfPkKB0OJiv379 g8VjGcUX8nkIACAgwZzD5VYWGeFpx9RjG0La+46Xkisp9v074TEji72Z/9C3lmiHxyg+ar0lAzgt asm5GSrrGp7bUkzre/etL/Tl01uUszuvWmcp70u7s5XWod1EysrEnNd3n9uaY7NY5oLHTpbW/t7M 4y/vZSJHHC6vtS9+sESKEvK8caUbSA5RQenjsdr6BiAEglVTM8qCqlGOP7+8WCf0Rr22Nlq/ssVj IPQU7cK69pt8I3zR/DxgR4DjD6jW/Vw3HAaFx4xUMWaeEutX7niMwmXf/um8ImPG2iClo5ybc9Z5 5dYJj3U3odStZjzz5MZHPI82U4N02WRsmHzI3JVnxWM60uhkkcnHuvPO9vKSAmWrgsE6fvw4aXia tt+8ebP82+3bt4cXj1kNopg+k42XMIjubrcLHrOONR3PJETz6oTHAJlkpx9tTrcJ00lPg2uhRJTR RK0OHhs3rlEEKR1uBB4xYqRVSHr06NH0eEyJCKAqw9cX0d3WV+h0mWd3xR2PWeXHCY8FdFE++OBD XOncuYtc4PLy8scff0LGY5rF1sdjcOnl2yga6IV+/VxkadCgQRA2OITKRVqAZTzmHY81+HMq6hy0 5RmPffzJJ43mYuvqCOooC6xnzpyhktAs8tatW/G5a9duyjOzsrIGDhwkJu169eplu7IHtUhPEwlL bHM/CPm2BuB6zucBW0JBF1ZdQGjks88+l80PhpxyG+ExDE7bn1sXqQhSBpycgLnFbSizu8HYtWsX GUUywwK4lprk6Ov7UagyUKFT8Cth5jXx2Nix46z2A7RhwwZUH4bEpU8FQNWMhJb1Gv0QZfZNOU+Y gD8hCfIUbE1NDWrksptO4LGrV+TfsaYAfPuaAjojiKLv5KQF7uePHS7xtRtt7xFpKrwR5caQPVpb PGYkHVlgLESIt7vgse/OqHiM1r5+1zhXngGf4hpVDXUJePot7TVy2t5WWFFvZL1feCHLOaoT3zhh o/CVn99ajOoTv/XjeSP6a262NW2gy2ldPbaojQ886R5EGrqCckEmUfOzSbrARq7/+ZT9P3t6ZrkV WrjX6JR/d2J6cY1n6VprbnD6w/I80a1OeAxgSRyNIPK8b891yw1obHo0K5haVBMuPEY7G//TLn+G Ox572kxvI+p14Yy7+Rdq1H9HSbB4jPLTLDBPBZSzeohMHjT3cddaezymI422FtlQL+Y+mYkTJ6kD 0IyzpZ3PNCVntWvCcAvrECIesxpEcq979uypXKfYEHn9JCg8pow1Tc8kRPPqhMesnUKNL/b8UGWt h9NQJjZUMyAeU/JpCxWkbAxbu3YtgfOmx2NKpBx6hBbxVq5cafsKz12m6a644zGrrnbCYwFdFOpr pTAN5sY/XAdaC6rY+nhMaXAKCHLH9rZE4Z1dujzFeMw7HhMzW+COHTu5r/uHC49lZmZSrPAEC9E2 Hpobo8BW6CCX54vRKCMHQbT2mpaW5jIwdu/eTRvnrD/3jMeold586y3r/TNnzpInxYPFYxTm9O67 o5TrFHcKK9jIE62uhqaOjo4eNmz4yy8PxEtvbHmTopRtDQZ+SBuRIUUjRozEQ2yzXFgJHU3zqf37 D0hISLBVhZp4rHfv3vgT2sH9jbZ9itKSSFtTJihUVFSEco4Z8xlKhfahmTbZRYZckSlq3/6uTz8d g/ECMKazDOXkAT+3pVjZISPw2OfJZVYWs+yUc/zxDd6PEN1fWG0gokWNZu5t8dhTm4qoPOKKBzz2 3yQ8Fp1irNv80+JcPAf+9KZfq2i5rOWq/NOu+fT+m5n+0TaFiYy48EYjV/s8HzCT0zM4ngdtrkn2 2VZyonEOd3LEgQOtfWE9alkcW+y0shO6gnLDY1aOzz5YWGMLLdxrBGRLTzhQ6BGPna+pp7x/cnpG Wzz2y/laytY4YEfJ1pyq5LM1sw+XGycixGdPy3Q8/ICyaDywPkCWs6Dw2DxTqm1TmLjjMUJEo/ad t8rYH5PyJqb58u8nHK0ICo89/N1ZWkymKYaduT5z/K2ZDRW/oirR6W1WPBZQGl1cf8JFcP4Ui0zT 83RsEU1OwbFTftsEeOyVV16lEB6leLSBp1evXmHBY5qeSYjmVR+PPfHEk7IRBBzFn7Nnzw4XHgOO opIoaVGAu5Q4kYuFx0AUCCpmYJVXBNVlHtyVCOExxUWBmaCVZ2ELnPCYZrE947ENGzZQbFTAB8Ki TZ8+A2MZYxPCT7JqdVkZj+niMUBqCkXt3v1ZwtzuYaPhwmNic5QT04TQG2+8aeu4NzLt/j27tosV Dz74EL5au3aty8Cg+YBHH30sjHiM9vKKRTCr6uzU6dFI47HNmzeLjb9t292Cunfo8CCNeQw5d4PR YIbIj/7443b+Xd0QDwy5gBkyGswkGbQLi/iZZ7oqEzmaeOz22++wGoDw4rEpU6aSBW3R4jrYGxRb bKSUlwEpe5UI60VjQqrdnyzw2NcnKuAkEdNOfeXY2Qbt/WOxppN3ndf9YwCBFCWoHDVmxWPLTxhO 6l9W5MtOnS0eo9DHFRaUQnFToqgAPJRT/lRj6EVH5TrlPPBpRtPFF8cEu9O56nojtWPjvHbCV4Zv jWoSrz5VmVZUU243mRjU/jG8kR6O/o2QgnLBY7euLhDSleo/zy3xWIW3GtHazqqsSm8CRuKt9KYt HqOjxoY2Tmlo4Ki5Rvlt94YZKWES7YNjQ8FjlCPn1tUFwYrBfzGnCSZb9o9hRGSbkuA7Bnpeju1q nhMeEwGodGhBb39Wj0fNTB5j/QDs+pX5tngsoDQ6WWQRJOLEFC5F6zPWPH5NgMfE9idbdp/O18dj mp5JiObVMx4jdSF2zl8heIyiMYXMKK/Q7zJv7krT4DHRktaIHise0yl2RPFYVVWVyKwDv6h9+7tQ GJKQJ5/szHjMIx6jDbK4E/qUwsevu/6GI0eORBqPkZKCgtjiQKQdoPdx2+jRo12eX1JS4hKZRrpe xNTaDgw0kZP8ecZjKLOyBVMQaROx9ShCeCwzM7Nly1bXXONLyOGilN0PSKmtrd25cye6j5oO9mbJ kiU6/Y4CTJo0WWTikhc5NfEYJZZ037wXCh5DRciUUsIVxS8R62OC4GrgzmHDhtNeZ2ifQ4cOBcRj 8p4lI9WBmTxAPjpJH4+tzKpwD0ZacrwSDqJTuvAYc68/3nLX2kKZKWYPQAufAWbO19ST43vVsjz5 NsBI8i/pT4pjpFWCWT+raxooBq539Ceypz97bVXDt3y5yxe7HQFMZwPMPxZEkon395XS0WqKr2yb zyNEPHaMvP+5OfURU1AueEzZP0YV/92SXCUKVLNG15pw3SW/IvrRaf1qT341NfJNqwoaSZcpS+hi fKatj/X+ZdXj51U0TGfcWcUJFG/uZvzPrwOfZxoUHqOzAYCOghID4xh0E/OL3XdCxsTEATQATX/8 7+V51pOpA+IxjC+Sq6Kqel8mj/jsPD9SdcJjAaXRySILpxMqztYiUz76zz773LqZtmnwGGEqWA3b 4rmsgQSFxzQ9kxDNq2c81qNHD9vNcpc3HqM7hcOgvEKzyzy7K02Dx6qrq2kDmJwXwAWPBSx2RPEY vCCCXhh3InTZyWVlPKaFx5KTk0kCKE0cBIL2IHXr1t0lZ2V44xXdt61TcoWXXx7o/grKNmtduiFP CPBdeNu2A4N2zeI2axyaZzyWkJBAOYWt9xNUi42NjSgeg/KybtL1gMcEoafo1dDLQaU0peeDxQkz tHg4Zsxn7niMtofOmTMnQniMUoehnW3nia14TBC+omDO114bHBQea/Af4gR/VHbRNPGYOClr0682 uKLSf/7YmlP2CwiU4dCd4TEf87uz7kxZH2ihw5pfm9DCAP/+GTr/VyQ/sE7nn3IOWaRXjEtp1B1o VTpu+JxdXJaRK0JKmRhRPLbL3LEjH74cdgWlj8eMHVZmYozxqaUeatTXXMu6fY39gRYfHyyl+FLb b+ccLg8sNvMNCReHg1dYFieH7LFP14E+pumAuCPl4cVjvpXbeTlBicHbP/nObhYvsJUxo6bz7bcd BsRjDf7sppPSyz4yM3nIWROd8JiONDq5/jTNtH//fpffzp8/3zZvrRWP0WYSq/0KMV5ROdNFkzzE K7p7JiGaV894bOjQYbZTmU2Ax2gxUPl50+AxOvNGoFCneMWwHH5ldVeaBo+B2re/C39u375dH4+5 FDtyeKyyspLWgeWEIozHQsJjwB60/gDPUsgxdDGd6QGJjygeg/9BGycUb7jBPGFQbEmklEotW7ZS jkSDZMs6jjS1nJOXiHIHyUW1HRgoDJkEZatSRUUFzQl5wGOUaglwV9k0AleezJ7olwjhMRp7GMnK JChFVFsNhqLK8XPUXTn5ROxAlU+9lGnmzFn4lRU/00bVpUuX0p9ffDEWfz799DPKIKcARYHHYHqt tzX4g6eFevKMx6jTldiPbdu2yXgMsgEzhkopzjTFuFoPOQiIx0r9q09/kw5Q0sRjAlPdv77Q6mku POZLH1/mcH4TABu+svLvzMgr/ByfcQ9+bHsbRXbBLaY/6R0zzYu/t/h/FMe4wL+oRa487Y1RYZXp Dbs4zvRb5bje/Io6Spi+yG7djEIrAXqbYH2MMkl2dD3SOkQFpY/HGvwZz6MWZBdW1Adbo8ySGlr2 sebVqKpr+KOJiD5wONsKQmcrNpRu8eWd5+hPupOWZK0H5RECGWuBGavM3VPo0EoNjysoPGZk+TcF yQrsnRrtx/xqKr+c89NJxpLM0F+wkmFFB4+JQyMoZFfO7emEx3Sk0cn1p8zaVowBcyw8tkOHDpFd owNIlDlNGY9t2bKF4imU/E+03csDHiNz0KHDg9aM3kVFReHCY5qeSYjm1TMeIygCk6SkbZg9e3ak 8RgMsTUHtUgpqYPHlHyeTvBAiSM4cuSIcjKq8grNLvPsrjiVP+x4zMlM0Kk/wuHRLHbk8BhJL5CC kgAvOjqa8ZhHPEbRiS1aXKfk1aGcm61a3ezkyIYFj4Hi4uIoi4bs6ULLQ+H27t1b6Nz+/QfQQoQ4 o72wsJAWUlAFYQyg92Ek5AhaOjEZQiP2ZrgMoWnTplM2IYiawKs0DDyfP0ZLus8801UMY1SKdsRB tYnqRAiP0diADIg5jDNnzhACVzLziOVBkVEQNGvWLDqLUFbT1Ep4ppOOS01NpefLUnfgwAG6iA8y mEF/CdlDa4tzFYXVhCEnPCxOYARBKdMxF8DqIeKxbt26U/ZOkapEnLItz/3QZuLnnntO3v9Duchc zodwOX9sWmY5gRCxx0MfjxlLZPG+GfequsbAxlwYGX2gNFhF4XL+mBXkKAFjxsG4ZuIB+UxnXzID yXs2gtlMR3/J8QtrdwUVdTeabuVTm9zcKco1Z83y/8aP52hPmpJjI6WohhCv2HsTUTxGIYJv/ui2 BS50BaWPx9DmlFRDRrD6NaIzFQDntkptBaxCuT3RsDllwU1C2+4fo91Q7VYXyGd5+1B0nE1CEYpZ BTLXeWOw54/9+9I82yz/SqPVm9GARtJ5U5KVOREXGRtm7gQDhNtXUB0UHjOe6T/OQVnycsJjOtLo ZJGhvSleZv78+fKkJOwgrJs4JY9SSvTq1UuoTfhzFC8g57sXgQYJCQkinoJyWYHlU0Y08VhZWRkt IAAxCuvZYCb9atmylbxly0qUwltZVnIaazqeSYjm1TMew0PonO7Ro0eLaXQ0He1t1sl37xmP0dbB Rx7pKPwZACdxspZYO7I9rJnW1pRYRyd40KNHD2FqS0pKKERTfqD1FZrOpDd3xan8YcdjdLYELIU8 R0z+trz5Rb/YEVwfM89fHf3xxxRThn/nzZtHT3OZpGY8Zo/HoCNoACuzHaRb6Ry9AQNejCgeg09P efZhA6DcIW3wjOFqw0FB18pFpcGAbh46dBh+QqKAD3LGv9mzZ5MtAf557733MQhpRVU5sddpCEHX UxapG25siXEOEHjzza1RGPLOveGxvLw8OroRagJ4EvCMFOIDD3SQF74jhMcw2EQqDsA/ikRFp9NM knzOI4g2hqJ4KCel9ykuLqYHojvQpNDFhIEDBhDS0XA0kYmux2+pIwYNGiSsMvSjSJuBtwDqUFIN +leexVyzZg0J6pNPdkaVyTiBYQ6DVXZWon2D1CyQQBIzQoDywEGD0FeQDQwKIGpax8OvXGJ7XPAY 3CxyAUVclj4ea6BMa+Zps4Ai8N6e2lT8lxX59K6O35+tqw9aUYSCx8QSGRj+60s7S9qZrjPqQqdI XxAM8zBryp0waNc5Y6eQCSDh4ueVu7n4RvxknLElRtmEgz8ojov2/8DF7/pD8U2rCkSOO5FiLqJ4 rOUqo/GTTgRovRAVlD4eM/yVIxWUaFEctK1fI0AvSq1JGwjRTfeu8x0Ohi7YnF0VrHTZ4jHjNAVC Ggtzuv1QPHDnOZGR/1NLIXfmVtPb8yu0oGCweIyiND/cX2orBigh2sE49zyhUSJ7JdjSRcbwFaVD xEAT+FMHjwl8ZT1/zwmP6Uijk0Vu8Cc0JnsEfftCv35kAYcMGSqC+ZOTk+ninXe2h0WGYm/b7hYS ZhmPNfiP1yNb8OKLLxGQoON9PeAxWnMjrwbWFg+HKibNDCAEa+tS5W+++YY8XbgNIsmW01jT8UxC NK+e8ViDeeQABTHBhuKB5GNQs0QUjx07doxcLzQFehMdhPah3gyIxyBLuAixgbSIVSwneAA7Sy4T uph80VatbpaP1bK+QtOZ9OauOJU/7HhMgF5yePAcEm/qXDkZgWaxI4THGvxnEdH2+z59+pDYC99J nnpgPBYAj6HDaMoBLW6b8ouOnrBN4xNGPEYlwdCiIztInUGwlKACUhmDB79O1SG9BmmwLtFAoUMv k9ND2cmtUZcu7g4gGfS7yKH38MOPQAXQIPeGx2hyESOnTdt24hz0l18eqER6RC6/YkZGBm2RolfD bMAM0EyhfAQtlUFUXEwCVVdXo9fo6A8x+ANmn28wdw7APomOaNOmLVSAImmA2WITKhj9sm3bNhJL RQBQC6FuUIvHHntcKUMo+RXXrVsnKogWgAAAiJINkHMKw9gPHDiIAk2Je/bsKRbogsVjDWbiDQIt lHstKDxmtN75WkAvn5fsd50XHquo96QoQsRjoNWnKglhihRzq+32sOEVFMfo47lGGJs7GPOtZP5Q 7BSauOZUpbHYknihKeDof3aoTA4/ixweO1tl5HX4/fI8nZYPUUHp4zFg8v80s8l39e84Cgph0gqn ESYnDotLyO65tSSr1Mv2DKfzx3LK6oyv5l4AOX9YnmdN1AnqvNHAh4D6mm8MFo9RUhmMIHs8Jm1+ +9PXeYCOPxXY5MtxlzEjIYe5jEzHi+njMd+WUcvR0rZ4TFMaXSwyOeKQUvL48S/c/djYWMXJO3r0 aJcuT4l7nnvuuZ07d1rT0sLPGz58BN1mGIK27aBUaeeVNzxGix59+vYV1gqDCJjQuuPIOssszI1I MeIy1nQ8k1DMayh4jDxmYbaAXuASLF26lM4rihweoxlMWqIk5AN7LZLHuuOx9PR0kYtSrFI6wQNA VphXoSchjUoMl+0rNJ1Jb+6KbfkjgccM3TtxkvAYMTQWLVqkpJfUL3bk8Bjc78mTpwifHEgVxYZa ED3IeOwSpqKiIgw5p2VlMd7gxAc8aQESCWk4ffq0t82dACEoSUlJSXgriPLgsZpHeIW9bdEgAV8N O5qamormtc6vQGXjK2Uza0CijoCucekIgB88Wae1IRtowIB21xuh1nh4wJP3qB8zMzNdTsRuYgIw Sz5rn7S96QkQaH9h9bnqAE5wSXX9voJqOJr66PFgYY1tyKLi8uLtRVX1TVnlz5ONyMz4I+XBjgvP CqopqazW6KlfyyJYTkBHyLCO2ESUCPJZQxYvLfIgjS5SGlDfwqbAT6V9ttZ8HsqjlK0mIRLcQTh/ QT0Tdg1YDto7qMn7gJ5J6ObVMwFBoRFoYpoCQZ1imsJLsOloEzlkVNOzAgoFfnM6vVOBB3i+N09M x5n04K4ELH8YiXxdjCn6k3ZMzJgx05uXFTlCU6CcaJMwSjXjMSYmJqZmTY98fzYqLjulqKb5FMk4 GGBBzm8W51bXc/9c2kTJ+uUEhpccXVxpdMFjTOGlY8eOWYFonz59rHGSlxa55Fe8cmjv3r0KkkRr 0AKy+8lVTIzHmJiYmJqCducZGUFuXV3QfLAP5WmYnlnOvXOZAP452d+dqbxEy39xpZHxWBOh7vPn 7777nr/+9c6dO3fSyhjc93Hj1OQijMcuRTp06NB119/QvfuzIil3fn4+ZQ577LHHm2BdjonxGBMT E1Ng+tJM26i/jyiiRDkkn99azP1yeVBBRZ2xkXJBTvLZS8/vuejSyHisyWjx4sW0Gw0ArGPHTpQE C1es2d4Zj11aVF1dTafz0c69Dh0epAQq+Jyens6Sz3iMiYmJqbkQJWn85fxF3jBXD329IKfLpqKK Wu6Ty4cyS2r+57I8cUzCpULNQRpzcnLuvvseMG0nY4ooJScnjx49+qmnnm7VyoBkQ4YMVY45vRQp Ly+PROiibLNvPrR27doRI0Y+9NDDrVu3QRePGfPZlRzAyXiMiYmJqZnSrrxqLgZThKikuj61qIYH BRMTExPjMSYmJiYmJiYmJiYmJibGY0xMTExMTExMTExMTIzHmJiYmJiYmJiYmJiYmBiPMTExMTEx MTExMTExMR5jYmJiYmJiYmJiYmJiYjzGxMTExMTExMTExMTEeIyJiYmJiYmJiYmJiYmJ8RgTExMT ExMTExMTExPjMSYmJiYmJiYmJiYmJibGY0xMTExMTExMTExMTIzHmJiYmJiYmJiYmJiYGI9xEzAx WSk7O/vgwYP5+fncFExMTExMTExMTM0Xj1VVVZVoUGlpKW4+d+4cPpeVldk+qq6ujm6urKwUNwek mpqapm+1+vr6M2fO7N69+8SJE7Y3oFTWotbW1urffNHrGGl65513rr762tEff3wRy5CWllZeXq5c 3Llz5/33P4CygR95pKOHSn38ySesWZiukHGanZ1NgwUau5mUmcbv999/700DeKCTJ0/m5eWxtISL iouLjxw50hxsUNOU5JKmn3/+mTQANwUT08XEY3PnzqWh6M7dunXHzaNGvYfPrVu3yc3NtT7qq6+m 4dsWLa5LTU3Fn23b3aLz5G3btjVle1VUVKCcbdq2EwVod8ut/fsPOHz4sHwbSmUtaovrru/Q4cHB g1/XuVnmDRs2MB4LO8XHx6MAnTt3kS+eOnXqhhtb4vqNLW8aNGjQ2LHjGI8xMR67LPGYrQbwQBkZ GXjO9TfcWFRUxAITOtXU1Nx22+1o0o0bN15c2W6ykjAeY2JiChWPrV69+qmnnpb5mmuMkQngIV+E 4mswl7zuuOOv+Pa11wYrz8nKyiI/eMyYz+hKnz595Ce0b38Xvm3ZspXyuoMHDzZZY1VVVT3zTFdS PVDTbw0Z8vrrb9x33/0EMnfv3m2FWHJR0SbXXtuCMOeMGTPdb5Z5z549jMfCTsuWLUMBevfuLV/8 5JNPcRF9ev78efefDxs2vEePHnKnMx67AmnXrl0Qg+HDRzSHwsyePRuFmTNnzqWOx2wHl/6dmnjM VgN4oOPHjwOMtWnbrvkg0oiKRKSprq4OPQgricF1cW1Qk5WE8RgTE1P494/ddNPNGJk//PCD7bfr 1q2joatMOPV94QVcvPfe+yoqKmx/CABDiOUiNhawIiExgMD6+nq6WFtb++WXX+L6ddffcObMGRli tbjueuUJMNgf/u1v+ArATKAsp5svb2oO8Yr5+fmiH4le6NcPpfr88y8C/vbhhx/BnatXr2Y8diUT BMBDXGuE6IMPPkRhoGEudTxmO7j079SPV7RqAG+EujtZrstPJJqAqqurz5492xxsUNOUhPEYExNT U+Mx0KBBg3DD3XffIzaSrVq1KmDwYXPAYw899DDKMHfuXOtX3bp1x1cLFizQgVj9+w/Aty+99DLj sYuLx6zUpctTKNXSpUsZjzExHrvs8dhlT5coHruSbRDjMSYmxmNNhMdyc3Nbt26Dez755FP8WVJS QiHaw4YNd3msNzxWUFAwYcKEZ57pCvjXq1evMWM++/XXX+Ubzp49O3DgIHB1dfWXX36JOwG6nBJv XH/DjSjD+vXrrV9NnfoVXvH++x/oQKzly5cTIg0Rj/34448o+fjx4/Pz89977304hXIbokaJiYnP P/88XtSjRw9YHdtte3CncNvgwa/fd9/9uDkmJoaSryiEDgWQfvDBh/CWt4YM+frrr4MqzMGDB0eO HImLnTt3GTXqvdOnT2vaQtQCAPjNt97Cqx999LFXX30NL7LeVlVVNWvWLHTxPffc+/jjT6CEycnJ 7k/evHkzCoz60p+QDfzZpk1blOrJJzuTVFhdTLQhfdWq1c0kkPg8ZcpUBY/hh9HR0WjPe++9r0/f vt9++61t1Zw6qLCwkN5i3UoOGcN12y2Fs2fPxlfKuw4fPoyLkyZNVprrlVdexXUMEHksoDVQI7Rh //4DINK4TfHt8JPMzMxvvvmm7wsvQGDkaOGjR4+i+p06PYqeeu21wbhHR4bPnz+/Zs0aCAzGHV79 7rujsrKyPA/kN954E5+3bNkydOgwFOOJJ56EsNkmyczIyJg+fUafPn3gu6Oy6AjrOom77FFro8zo cQgD9dfJkyf1B+C8efPwk++++w7SgoHTs2dPF2lBLSZOnPTiiy+hd6ihTp06JXuWeBS+oigDfEax NYVNJg/jVMZj0Gx4NZoUdYEsKakyZs6chW+tgvH3v/8d1/ft2+c+uPSHocBjx44dg9CiLuhBCDzt THbSAJ41yZkzZ/AckHIdPYv+6tDhQbwdHwLCS1KhkydPgSgmJCS8/PJAdGX37s9i8KL7gtXJAUXC KoorV66EALz++htoQBRAXzMQrVixAmMEv4WAYYRCHlByPPbQoUN0w9atW/EnFKPyw4ULF+I65FNc ge3AFbHROiyWzpsNsi2Jfh9ZVQqkFGoHyhMigYqLVyi2RlMbnzhxAooXeNtJyEPX7e6ah/EYE9Ml jMdI/1LMXkpKCtQrPt9yy63uUQEe8Bj0CG3uAovsIG3atpPnTYUzAWUk8mc45TOEysO3UHkBX+0O sWCnactZiHgMBpi26tEkscib0mBmgIRPLDKO0Ka+W2+9TQEzx48fF7lJCCSD//rXO+HHWBuf9qxT /1I7yCbEpTAw8wRlKarT6IU2beHgBrSF8LnFhj1IiOggmBP5NkB68dKbb24tbpM36VmJUtHAisud qzBwkfKrX375xXobbJWMxwYMeBGmkTYKinvg/cvPCdhB1D6K7wJDSD9Bx1lrtGDBAnwFh16+CCeG AINsgPEWeUYAVFRUhL7DRZRENDVwaU5OjrLsII8UsaAN4037P9HRQpCGDBnqNLVBBH+dFiRl8cNz FM9VfyCj8HCMfOlz/I1/++13KL4OLWrRoGvZshV9hlMlh5wFlD14wFZJgELTH4AkLYCOtPDuIi17 9uyhnbf0EDEYxb4pjFmlJBgI+sIWyjgVKhQKQbQqfQAelrMOwtHHRQik8gSqPmC5++DSH4YkqHAc SRuIhkXB9u7d66QBPGsSW38U4Ed0EzUmxUTU1dW563PYOHj5ZB9FAfr1629rEF10srtI2K4U9e7d m/CtrHl0NAMqRXacWpuaDu47NIycj4oU1LPPPmudY8J1wHJxpZ35IiGfoVs6zzbItiSafaQQWhJ1 V7QTCk/jRZ420tfGX3wxljSnLOQ//fST8l7Puj2g5mE8xsR0aeMx6FBSTPfeex+N5BUrVrg/Nlg8 VlZWRh42jDQ8BtJK0PikjmHOFWcCqmr06NGwHPv27XPaUQCPQWjejIwMz3gMpo78v7DgMVKUEydO gooUpaKtbnAoKSM/WoNsHhpcTOMVFBRQ+6NZiouLUevt27f36tULV2CohPsOS0YOPbxYXITphXEi Yz9y5MiAhUELkyF84403T58+DQf90KFDtF3QsIWjR7tUsE+fPrinR48eNOeHR40dO46s4NGjR8Vt KAbFjAEVoHhZWVkwsdSntpOFTt5Ygz9ecdmyZQEb3yVekQR169ataK4DBw5QgC58FDlHSMAOIoGH HZWfP2fOHHJznebpKTOkDL3I51CGJO14FMu5uB/SiCsoP/lz6Cm6ArSg2GxyK5OSktDaEJsGMxkP Oh0CnJCQQIUXVnzx4sVODYiewnOof2lNDHadGgE6RJwk4WEgf/XVNABXlC0xMZFcQ9RXvBceOQQS jLJVVlYCg0F0Ce/BpwxW9pziFXUGoKa0oJDkcqHW6BdcSU9PR2vgSvv2d8nKyik4TacwnsepaHkS gNzcXFRky5Yt5L3J6xgB8Zj74NIfhkJQ8fbk5GSUB4q9U6dHlfFu1QDeNInVH8XoILd148aNEDDA PIgiecxxcXE6+hwGEb9CAchYyJBAXyc3aMcrClF87LHH0Sz79++nNRBNzYDSUivNnDmrvLwc5UlJ SaEGDyMe82zpQrFBLiVx7yMrUV9gLK9btw5SAfsLFSRQosBjwWpjdyEPRbdrah7GY0xMlzAeAx07 dkxoImjGgI8NFo/FxMSQdVHmI4cMGSrv3RLOxLRp03Uei2KIYkP3TZo02XalwgViwVWllQQx0U43 w89bakcuif7INuAtSgJGQEoqobzMBb1MulW4yLBD1unnnJwcmj4k0wKzQfWFCVG6DwWGARYLAk6F IdcZ9lJ2HPFYgAp3WwhT17FjJ/hb8vEANTU15OeJrXogmoWFFRFXYHHJw1bWGZoGj91zz73ywhok hLpDRIDodBAkk+Z6YQLFPc8995z7bD3ZYzF5CV8Bf9511934d9So98RtqLWcU2fKlKn4884728vL WSgt+VhCwslm9+8/QBlTBF0oVlAQWp6W4JxmN9avX09ujZIIAZ0uI6hgB7LSOLRM8UK/fgpAheNo XTGDqBOU1Zc9WzymOQA1pWXHjh1ALHChZJhNOdaVV9g635qF8TxORcvPnz9fvk5rsAAh5Mk1PR5T FqMWLVpEsxUuGsCbJrH6o8OHj7BCI7rosopCKhRCKK9voDsIaAkLpa+Tg8VjUBRyALOmZkAjUzjA Z599Lv8Wj6Lw73DhMc+WzrNsO5UkYB9Z6ddffyXDqoSaE7SW8VhQ2jigkIei2zU1D+MxJqZLG481 +HMqgr/77ruw4zFa57Euu0GJ0Espm4iHzehHjhyB60mYihheshIhQBAL+m7cuGjBMI3kT5NtEPrR /fwxpyOnhW14/PEnlOvkCvfs2VO5/vbbb9M8Gf1J4VjWHCoAimKHEuwfrdJYvWryroQNdioMbWCw bhrxvJeaHHFxLgKoR48euKLkHIcJKS0ttd3nEGk8Zs3nQS6d2Bek2UG9e/dWAocoPEbZOiXT559/ Ibu8s2fPJv8SjtEdd/yVOhFtQgtEYnsPfETcNnHiJNtii30ptmkSYL8pxkmZG6bFOjAtalmJlpsw LpTrEDyI31dfTQvLQKaVCngV9CeqjDZE3ZVNkqjF0KHD8F5la0RA2bPFY5r9qyktTgQfC7dt2rTJ 3fnWLIznceqiQglaL1++/KLgMUVQMWoUx9eqAbxpEqs/OmHCBPz5wAMd5D1FwPN4jksaRicVSj0l VrP1dXKweMwqijqaAXjbaaRT/EW48JhnSxeKDdIsidJHViJFhAZReg3SSK0nkHAo2tgq5KE8TVPz MB5jYrq08dj27dsF5IDZDrgXNig8JnxE28UrCmFKS0trCCE5GO5PTEyEs0gu8nXX3yD7Ey4Qq3Xr NpMmTRa5JWXwNm3adCuXlJQEa79pIwfg7oTGRNHhKDM5BzTJ6uLci2a33Qg+c+YseYHCtjB4C0Xp KEdgB4XHdu3ahRZ7991RKD9eR6s9ik9MIfidO3fBnfKCkgs1JR6jiVgx767TQQ3+85FEyCKlgbF6 M9ZFia5duwn/EpIJWQXYwPUDBw7g4u7du5UlI/I53nvvfaU86E1cF7lAbG12ZmYmbfqaYCGaHXc6 PY/QprwWEYmBDF+QDpSjP/fu3Sv/GRbZs+Ixzf7VlBYiaMhVq1YBnA8bNvzllweiMDe2vEk5OMTW +dbUBp7HqYsKHTz4ddkXvLh47Pz581ROofGsGsCbJrH6oxBXSlLVvv1dn346BsbOaU+yjj6nQxHh 8Qerk0PHYzqaAWOE9m5ZHxtpPBZp2dYvidJHVsIoULrGCY+Foo2tQh7K0zQ1D+MxJqZLGI+Vl5eT pu7e/VlCBfIGj9DxmNjtbTsZScEVa9eubQhHsubTp0/TfmIAM7FKJkIQ10m0c+dOCl5XnhDi/jGn JSknprUCERblnnGBkhYogShEdEpBp06PuhRGTNfRRqNgbWFWVhb5prRZAvUCOCEvHF6OfCcwBkCI qOMDD3SIiYlxmdK+uHhMp4PIuNIyLG2WoJ1FSlSYQnA+APjhf+C3Z8+ehQRSeg9KITN27Dh8jo2N lY9tENPbTiwmfW1tNqFEF3Za57n99jvw7Y4dOyI6kBU8RpmE3DFtULJni8c0+1cfj23evFmkZ2jb 7hZ0BApDyEEOf7J1vnUKE8o4dVGhH330EeXVuFTwmDdNYuuPUtJFEdyOXkNLuk9+afr6+jo5RDym qRlo5efRRx9rejwWadkOIx6jfCfyDlVbPBaiNlaEPMSnaWoexmNMTJcwHqM9uLgTRovim6+7/gZr am/PeKykpERZtbdqWNqeEZbDc+rr6ynQRdjIoCBW2PEY+Sjwe7bYEa1XwDhRxV3W3xr8e8xswzDI mxHbIWwLAzda8YH0bSFAOzlq8D/k5ZERI0YqaxSCcnNzExISXnzxJYrUh7S4JO28iHhMp4MUF7ay srJly1YAWtaUjwrR7ACMJS2vEX5DR+Dn5KCQrIrM7PADqI9QF9vyiHllW5tNgASO0RYHss093eDf x2V7ekQYB7KCx+g8elvf0Zvs2eIxzf7VlJbMzEz03TXXGDtO5d4nZzTg+phOYUIZpy4qlMI7hVa8 JPCYB03i4o+WlpaibMOGDae8oLfddrtI/u4Zj+nr5BDxmKZmgMtOkXhNj8ciLdthxGO0D1ZOoWGL x0LUxoqQh/g0Tc3DeIyJ6VLFY8nJyRTjR5mmqqurKQlBt27dnbb+NwS/f4x23svZjWUPT2zc18dj X301rVWrm+HL2n5LWbZFEt6Li8coikNJCm8lynTvHpMDp4TyIDtBtdjYWPfC0DKINfFUQFtIEa3W gHsXPCYvbpAczps3rxniMc0OAm3atIlCFglXyEGGTkQwDA1LGZlFUuNXX32Nltog/A8++JD8E3IW 9+/f7/5k93hFl0TetkTLfXPmzInoQFbwGG1Gb9OmrftL9WXPJV4xYP9qSgudWIBX2y4OaMYrBiyM 53HqokIpia5Y0aWFHevIbYZ4LChNouOPlpWV0VF1r702OEQ8pq+TG0KOV9TRDEePHqUZVWtMpoLH EhMTKRY0XHgs0rIdRjy2ePFiOamyEx4LURtbhTyUp2lqHsZjTEyXJB6DyqZ5cRgn4cBBWVAqORFD FToeI01tnY4CrJKfo4/HyLGD1RHpwqya/fXX32gOeAz2iZx4a5hNUVGR+Exp8b74Yqx8AxzQJ5/s LFwc8l+Bn5UNPHAvSNGLjnYqDKXHtRoquu5iC8lbUpBDbW0tLe8Irw7Cc9tttz/wQAelB2mDtcsh 4xcRj2l2EI0XOjHm6aefCbjbSjbwePiNLW+Sx8s333xDiM4a7dmnb19bu4vWllvV1majChTFJ9I2 CMJvXaJhqRFQL+U6Wg/X4UeGZSAreExkcN6yZYt8W25uLi0/0mqepuwJPAZh8DAANaWFgLQS6SSS 11nxmGi6oArjeZyKlpcPB28wz8ojrS58Qagaa4+jR8hdvuh4zLMmUfxRtDMcVjxKmUSguD750D9v eExfJzuJhD4e09EMqC9N7SnaSWQdFHgMg44snZJNh7Z7ecBjkZbtMOIx6jWMCCVBV1pamoLHQtHG ViEP5WmamofxGBPTJYnHKDoRfo9yfheZjVatbnaKsA8Wj8FWQe/DaMm+NbQqvDHoRNpzEhQeA3ok Pwl4Uik8PAnaMSxc0ouLx2CY27e/i7Qw3B1xfdKkyXA6hXWkpLdo8127dgkLSpOvaCXxQzgilBBS GAwYvzfeeJNcK3GbU2EOHDhAOFb2mSgvlnuuYZETRThqsOKUl0LOgQbEQt7A2LHjBMKHWaL99CJN X9jxGCVSV4KvND1szQ4iomTNtAblcviBtRbKzDEkXJxLq+zaSk1NpSVreXNaRUXFSy+9DPdRnPHl tMcgLi6ODk2WHdCsrCz4Sb1793bae4PepD6SU8+npKRQIfft2xeWgazgMaFJ4MefOXNGQAKKrOvT p09Qstfg34cpJ6vU719NaaHTjaBXxUwQSi6OlZObhbJdK/FgmoXxPE5Fy995Z3tRQggqTffICwIE SNCVQn9i8IojaOX32g4u/WHoDY951iRWf5Qc/eeee07e90iZ7lwOd9H39TV1spNI6OMxTc1AySog ZvLRfOKEaCFjYjsTrIxYeaYcJMoiniYKirRshxGPCQHo0aOH2CMgn3QvQrJD0cZWIQ/laZqaxxaP wamAFnWJeGJiYrqYeAy+C+1vVtZkyFmkA2QHDHgxLHiswUz2TZoIdgu2Aa4h7UOVT+QMav8Y7hHe Q+fOXQYPfv2VV16lYBvFS7u4eIxmIqkjoHPha8JU01QllGleXp64jTbyAUzCeYJJJtsGSyafQID7 H3mkIzncr702GK4AhSs88EAHOabcpTDisNEnn+z86quvUUkoDs3FFtbW1lK8ExjWAp+p+8g9kiUB rya5QgnhNMPsUVI+mLrI7R+j5SYUCQ6W2CGjn6FBs4MEbAaj6TQFg9Jtg5U9meQQoHGs6Uwp4JZ6 8N13R73Qrx+tI6FsIgzJCY+hp+jsCgy3Xr16vf/+B127doP3A7zkEuVFExnUcRAMvFTkzxAp/kMf yFY8Bs+1W7fuFLWI4fzWkCG0vod7xIk6+rIHAuykHXQYHZTsUbN/NaUFVSOnkLxtiu5Gu1GxP//8 C/HDnJwcccA0/C3hDGkKm7dxSi2PDkILoMfx6pdfHki/wksFrqaWpwA2QgiAK5Sojf6VfWXbwaU/ DD3HK3rTJFZ/FGJArXfDjS1h0dDgtAaIh7tEjun7+po62UUkNPGYpmbAoKPyoLnQ+zCFVB6appQn mGjigxa1gFpp8R8Wxxsei7RshxePZWRkEODHM1H37t0NrUKFV7bIetbGViEP5Wmamscq/+KMMvcD spmYmC4OHhNJL2DbbLOlrV27lsbwqlWrwoLHaB4depmcOZrAU0Iig83ngVrEx8fDhJNGI8YrUGZ5 /8xFx2O0QNGnb1+R4At1h4dhrSbcIDFFB+8BTpJ8nKiYToOxJFtCQRcwuni+fmFgEsTPYQWXLFlC 8WbuthC+BUw7RT2RxV2/fj3N+KL95Tvh9gEDkGNHjTlixEixABIJPIaWFHnYxPRzUBnMNTtIGEux FhSQCMKJRPmCaP/GoEGDbH+1Y8cOSDK1Nv6FgxUbGys7cC45kXEb2pPOpSGbDeykE28Gy407Ce3g pY899rhtTKbngWzFY7QSMn78ePLGKG/Y66+/oTiy+rInnHhl4TFg/+pLC1oJ3psYffCN4APR0pCS QVuspoJljaQpbB7GKbU8/DYgFniZ4hXoL+ve1OPHj8vZCyFR0H5kF2RpsR1c+sMwlP1jHjSJ7foA wADQPgUQEvfs2VNGp6HgMU2d7C4SmnhMRzNQRwAZit7HiEPPKvvH6DZ5WKH8s2fPpn1K3vBYRGU7 vHiM5B8+DFXfSH7bp8+hQ4eoSArg96aNbfFYKLpdR/NY5R/YEu3Wpk1bsf7GxMR0EfBYMySYrrS0 tNOnTwebcsAdmEG3Hj16VA6TaIZUW1uLQoqkDi5uDTSve1rnBjPgBLdpRs3ZtpjT6cDu3YeXKqtG TpU9fPgwbEDAioRLBuAKZGZmyrFqYe8gY3tGm7ZyBGmkBwta23O60aKiIh1BstZR56VhH8i5ublo fJegGk3ZKy0tTU1NhWxbH6U5ADXbFtUPOPrgDKEwykZE/cJ4HqdE1dXVGBHuWVuLi4tRQvd79AdX WIZh5DQJxBVlU3ZMhZF0dLKLSIRXM6D3cY+Y2rDiMflRYRkUTSnb4SJ0FqpPs9IpKSm0rmirhULU xuF6mqbmUSShaawwExPjMSYmpqYgmsWXo2GZmJiYmj854bErk4DJlZw3oMmTp3gI/GFiYmI8xsTE 1HSUkZHRunWb62+4UcmlxsTExMR47BKiQYMGXXf9DYsWLRILud9++y1FxsrJRZmYmBiPMTExNRea N2+e2I7lktuNiYmJifFY86eDBw9SHpEWLa575JGOYjOb7dHeTExMjMeYmJguPlGOxIceenjy5CnW g1aZmJiYmjk9++yzd999z/bt27kpiPLz88ePH9+nT582bdoCrPbvP2Dr1q3cLExMTIzHmJiaLykZ /5iYmJiYmJiYmBiPMTExMTExMTExMTExMTEeY2JiYmJiYmJiYmJiYjzGxMTExMTExMTExMTExHiM iYmJiYmJiYmJiYmJ8RgTExMTExMTExMTExMT4zEmJiYmJiYmJiYmJibGY0xMTExMTExMTExMTEyM x5iYmJiYmJiYmJiYmBiPMTExMTExMTExMTExMR5jYmJiYmJiYmJiYmJiYjzGxMTExMTExMTExMTE eIyJiYmJiYmJiYmJiYmJ8RgTExMTExMTExMTExPjMSYmJiYmJiYmJiYmJibGY0xMTExMTExMTExM TIzHmJiYmJiYmJiYmJiYmBiPMTExMTExMTExMTExMR5jYmJiYmJiYmJiYmJiYjzGxMTExMTExMTE xMTEeIyJiYmJiYmJiYmJiYnxGBMTExMTExMTExMTExPjMSYmJiYmJiYmJiYmJsZjTExMTExMTExM TExMTIzHmJiYmJiYmJiYmJiYGI8xMTExMTExMTExMTExMR5jYmJiYmJiYmJiYmJiPMbExMTExMTE xMTExMTUdHjsl7J6ZmZmZmZmZmZmZmbmK4oZjzEzMzMzMzMzMzMzMzMeY2ZmZmZmZmZmZmZmZjzG eIyZmZmZmZmZmZmZmZnxGDMzMzMzMzMzMzMzM+MxxmPMzMzMzMzMzMzMzMyMx5iZmZmZmZmZmZmZ mRmPMR5jZmZmZmZmZmZmZmZmPMbMzMzMzMzMzMzMzMx4jPEYMzMzMzMzMzMzMzMz4zFmZmZmZmZm ZmZmZmbGY4zHmJmZmZmZmZmZmZmZGY8xMzMzMzMzMzMzMzMzHmM8xszMzMzMzMzMzMzMeIzxGDMz MzMzMzMzMzMzM+MxZmZmZmZmZmZmZmZmxmOMx5iZmZmZmZmZmZmZmRmPMTMzMzMzMzMzMzMzMx5j PMbMzMzMzMzMzMzMzMx4jJmZmZmZmZmZmZmZmfEY4zFmZmZmZmZmZmZmZmbGY2Hkb05VgVlcmJmZ mZmZmZmZmZkZjzU1P7GpGMziwszMzMzMzMzMzMzMeKxJ+afC2qj4bDA+NM0bv85sYGZmZmZmZmZm ZmYWzHjsysVjw34qjZqTDcYHxmPMzMzMzMzMzMzMjMcYjzURHymtj0rMITyGD/iT8RgzMzMzMzMz MzMz4zHGY03BUzIrfGDMZPzJeIyZmZmZmZmZmZmZ8RjjsabgG1cVyHgMfzIe88bvbTn/xznHBm8o drmn39pC3PPJzvLmUOC7E0+jMPNT6q4oTdd/3VnU+uMd5az0mZmZI81jdpZD4fRdU8hNERR/tL0M 7Rb1ZXrUlJ8T03gONwhemFKHprsz8VSEnr84tS4pMk9elt6wmPua8diVicfWnK6WwRgxLjYBHrsr 8VRUbDr41oVZiiw+ujyHvmpuNgzK4jdTf0bBpu+vtn47cH1R1LiUrivzXJ7w8PJs3DNs07nmUJ3/ OuMwCjP3UK3+T66d+wuqP2FPlfUrIBx81W7+SXz+bFcF9aALf7it9PlvCwLelphaJ94r82+nH7kp 4eT7W0qDrXXHZc2oC5iZmS9vfueH81A4HZac4aYICsSi0cDQ89fPO8ENEhTPT6lF0/3TtMORePhX +6qjYlL/HHc87E8GxvvHrw7DuC+4wuaIGY8xHjP4mR9KrHgMF5sAj7Wef5IULhiuuSyLDyw5Q9d7 rMrXl2CAN+hu8JsbSiJqWcFPr8jVwWMwJFfNOpp0GeGxP8w+ip9E/1hp/erv28vwVYu5v+DzxL1V NyacEAzDgK+gauWL436sHLqxRL4SNTEDt+EV8kWaLaP3/nHOMbqIhqWbwbcsyLpi8dioLechYAO/ KwrxnubG1oHD3GQMDYbGtx3jnnn2gRo884FLCpOEqx0Yj3ngm6Dhx6U8/20BN4WHwRVRPDZzfw2M L028hjJSbA0TDP1vpv68OJXxGOOxKwyP7SmojZqbbcVjUXNz8FVT4jGMwCXp9SHisc5f59KvIreq ZmAGvMKIoMhcnhEYj0VNzsQV+c4rBI8p3PPbgoArh+AW8b/gNttgTut7l2U0fLC11JhOG5cyYN3Z KxOPvfJdkdPsQFD3NDe2DhzmJuPbF2Wh8UdvLwvznPq4lP+Yc+wKbAfGYx6YpvBmH6zlpvAwuCKK x2ghK/SRcikaJsZjjMe887oz1XOPVcamlb+/v3TgrvNPby65a93Zv6zIj1qcGzUvxwaJyYwbFufi ZvwEP8TP8RA8Cg/EY8OLxxRn3QWPLU6rH7OzfPJPVcvSG2TXPO5g7UOmnw3utjIPfypRyMB7xg/3 VS2zOHmxe6pGbj4XMGo5/mBtVHTKn+OPP56Ug7f8bVupCx6LP1SLMkRNyiCjgs9JFjw2P7n2E6qL g9+5IKXukx3lVpu03KzvvORG15ek1eOidTPYzP01eAjdnGjeI2oq4zHc9vGOcvx7qeCxC0GSGn7e rAM1eCw1ghMeW5pe/8Wuiin7qlxgAEnRDIdWgkxO+qnqo+1lU/Y59qkvvj+1Dh2x1JyDgO30IAbU lb3XGA3baVk2PltjPJzugSjic4LZGgmmEKI8OkIVVLFth6rMeNToHWXKDU4DR3YFIAYT9zo+1tpl 1sZB4ZVpiMVmTRda2nDavmpIhft8LbXnfLPp0Dgxe6rG76mUi4cyfL6rAtedlIxtU6AwRpEav5q6 Kd51DsXomh0+KSXdaJUN22acb76RNPPwzeesWtQ6ZFDTz3ZVKGLTaFCYBUAb4plXzToqyxg+xJlS TaKCQSouJlnaR/QXdSiFMS8xxyzK4LS/CM2Fb8FOPYjmxavH/1iZKN2g0w7ugkFdQGHt7njMdjDq vwjNhfLjhgRl5JqtRL9CYT7dUQ6v3aUrv9xrCK08KxrskHcqicz46lO/MXKW3roLGuBAjdHXZuNT SaCR0KcT9lTF7q3yUAV8QBWU4UO2j8RPB4pM3VeN0Wq1AkGpRx0NQMrfqHXjSiWYYwRPdhpcMh5D c2GYo2tc+sW96ZQ2p5cm+F4UYKTYqggX4zX3kE8nLLOzR1Q1KlKwchVUB2n2sjdx0rEpjMcuQzwW d6wyKiE7AO4KlhOy8diw47Go8anCYNjiMTg0/y/uGG7z3T8hrffqAhpLU835IYWFww0l8pf441Ex /h/Gpr0iLZHDKaHrdwXa/NprtaE+Bm8ohvLCh3aWMDkZj4loOsGkLAiPoQA3J1yo/r/OOKpsSIMt NxBItO+Gf5z689jdFRfiEw4a2vZ/zDzSCA5tM+DQXxedkvXCv804Kt6CBn/u23x8EPGchMegK387 /Yi47ZYFWVa93GzxGHxWWrF0ieVAQ8mNYGxcbIzH5hysNQIgY9KEhFiTskDnGiE0E9LEiu643Y0K 897W0qgpP8tLvh9sLXXfRjhqy3l5FPxbMGLw0rqzioA9uFR1+JzuIWv9bzOPdFuZR9ff23JeR6g0 iw1Q+meMODFUp2TiJ/INoyEqUlvhBtFWTgOHLLSBpcUNE9Jed82dI08eK7sdjNn36BTZQXl6hbG6 /sb3Fx446LsimqQnht+w1GFcoIS4AdppABo85oKCGrKpBD8x5E00xcQMZcejS1OQH4/HyvfjW1y8 Jv4XJwx8x8JT4mkY1yM3n8OHexJPywDJqRnbKTrZ9LGcNvQ3qte4lDsTTyXaeRjweJRn/tY/bU/6 Z8QP56jRHl2eg4vGBt1xKbKzAg+VWob+fNtsFvRX95X5UdEXGhay2mgyIrXu1oVZxl5TfzWh/eSp Fgjt/5lz7ELBJqT19EfHubeDu2BAeWK8iG//efqR502t64THbAejzoug+u5MvPAiyPM9i0+LCQVq pa7f5MmFQdtObAxj0LbQCReEYbzxFtnZ1Rny7iUhhpX5D7S2X5VdHX883mHtSxZgYrLXVJL+686S hKAMmlUwvjWtntzdKAxKaOxSm5IpLrZdcNLdS+67phDWQX7IVAnlaqpHhV00ABgtiYuK0iBriMc6 DS6BxwyrJIZAdCp8GA+9r7T5lH1VQi+5jBQXFeFivKgwBOSMkk9IU7wRGEFIkZid0Zcr/Q5y7+VQ xEnfpjAeuzzjFb89XRW1KCdsYGxRDh4Y3nhF4S4LJ8OKxwwIJNSKxASiXPCYEes8KcP6be81BcqW MGC2wBEUMak0efkvADDjU+c3no+R8RjeDp+eyjz4+2J8JrVCGgHPgZ1G7WCqfzvNqL68ZdmsbBo0 ERwOmFXYVMNfGZ8yekeZPh6DIqCgr2vn/gJ7hkeRD2rFY3g47oEr2Wm5z0vr4xzw2dzwGHU9KmL7 wMS0etKPLeRGaAzX0aH/MsPoggeWnhmx+dwL0MWmdey2Ml/2Pg0pHZ/yRFIO7I1hhMYbMwjT/Gp6 /J5KwzWMTe/8dS6efHfiacMOjU+NsUt8ckEMJqR5FgMYRQgVYcsbE07g8xe7KpS3ON1D1toQhvGG IXl4WXbs3ip9POZebGMZGW0endplRS7a0xjLALHRKZ/4E1r6RtzkTMgD6nUvHA7UKyaVbJ7TwBGG EEYOXWDIqnnPWxsDbxY1glrHp4qJW/InwDKc+w/TuAozj2LQRAnuga4gdwS+kQseM9pzYgYEAEbX gPfRhgN01awjUV+mo4UHrD0LX8FE++kCB7o3hc8jiU6RPYz7l5ymWSGXXTcQcrgU8KKAQmnIy3jM pRnRR3gyjTWIOj47LQX/m6m0ocOHbCzBkPkXc0LHtn0WpNThOaQB4EvhM2rdSP9EG6DFGH0/nNPH Y4ZQTcwAhINv52vYiRniV8Cc1801lAkgGboSzUvKUBgUwy6g4jGpDy3LRnmeAho3zUTAdggoGGTX MC6oC/5CZQuEx5TBqP8i1B2aDRr7n80uELt6fK0UbQgDao17WpgNApUiLyMYmsp8yJsbijHcjBnP cUYMSFCayr0kvhGH1p6YgTZBdciRxai0XZqAUys0wKumBqDh4CtJtDFeoJEEeA5YBRJ4/BAiAWmB XiINb8hwTKoxjbL2rPFwUwCgZp3UyGNmXAxGNLoVNvR6c6wB/wgAo9NW9jvSHTRAQDzmNLh8QjXe eBTaCv1ihBSasx6yDdXt/cZtLuMxl5HioiJcjJfAY+AOph8oz+VNNKfCW/gdxaDkSrODAvayZ3EK yqYwHrts94/tzK+5anle6GAMD8Gjwr5/DOL7v2b5lnFGmJMrCh5bnuHbTwKG9E/6qcqYUvXDsw+2 luIG2BjfYDN/hT9p/JCrTcht7O4KYwKbZj78ZglDF1oGb8RjXVw6CgkQqSNgdWjeyNv+MQxdEWAz 56DPHlOgQhJ+ZUIIWW9SsinoDlI0Oq5zb3M1D42cJHmNtNtKwWPyusrQjSXu4X+keeHePb0iV2Fj Nrpp8RjakF76wFJ7X4e6Cb2WJAU2UCMIPEbTsTIEhVNuKNPxqcK0kFGUN5fTDJ9obQph7S3NPpJa pyl/J8MQohh43j/ms9bjUoZKYEYfj7kUG0x+8AhpPYF8jv/jFyojVWZ0iryaca/ZvPJiuHXgvGVK 5rWSdNHcMKxawIigTmaEqtje8LwpjVExaTf5zbCB2w3sdFTEkxiuTGy6qKahgiAS0SlT7YK+fHgs JnW81Fli5hhYXVwkRTfS3zgBm+IB0/aL7ZFJ5K+MT7XNP0ZL/f8w5WfxLYoN3CXjMZ1mDLgbxFCG 0Y20xKwDNdQCTn1hu3+M9I8yeHXxWGw6vLFGkHvchRkr0n6yZjOmCdCn0anUp8aaVXTKU9KgGGK2 zNWSM2pth4CCYczLmI0pYg6T/JLgpKNsB2PAF+H5BEHFDfHQWqbDTb1PrQQwJsA/SnKTGZQhak2a oWXCCTHQ0NTXmuNXFCbgkA9YEt+axrgUOcSD2mTw947r26T9lllMJ9xZOTZVpwrkQMvxLGJZSXbE /7atlNYznVaeKa+vjGapXp/7sYSOerTJV+yqAdzxmPv+MSUMhNyqZ/wIQb/3lTaX8ZjTSNFREbbG S8Zj5HTBQMuJQ3BliL94wcpVwA7S6WVv4hSsTWE8djnn80gurmu3ujAUMIaf4yGRyOcB1zZmT5Vv xXly5sKUOgWPUXygonG6+qM7RJyhNZ9H3MFaEQMgtAC5OLJXpMOkJUUgQZy5l+xf/SETIebz+NcZ F9TrJHNs32SZUaN5mk/NRQYd15k8P9kX/JoOErDgMTn6eQGF//ldHydc5MIRxWNovV6rC8Bwp4zc KhQbNjlzvkPg+O/NRlB2Gij7xwwDMDFDiUen0PZu/gIb/Tg+VdbRhgs+3vBC6E+KNZL9PziUE/dW OQWRh0UMQsRjym5vfTzmUmwDMExIgz+qxOIDEqO/nPIlwttQQm2tA4dM/nuN4x5pzlX2y22ZatHF 3wKQJVTTwOET0mjR7CNzaVd0N7WYgqUJ1GGMO+Gx3zb25GhqQ4k27LbSCF1TooZcmuIz0yMRDyEH BV61S0IjsfLvC6Pdcl7GYzrN6G13PoU5OIVmueAxZfeFJh5T4E0nUzJf9fthNExmNx59sCbXxP8y 2UFaFhOumJzp4mUGFAzqgn5rC/XzedgOxoAvWpJeb66Wp8oaBo0PnUPryW/bvZRk8rfTfIJKWD22 8Ro+Qco/+eN7Aw75gCWhrv+3xraS2sQlNa4THlNKolMFcqBp9VUB8LKtgQkwKjIhTV/maRpOeP8B 20qHFQ0QCh5ThGqUqQrEkz33vg4e01ERAfGYTxvEpi2Rd7zHpJFy8CBX3jpI6WVv4hSsTWE8dpnn Vzx8vv6pzSXewBh+iJ9HKL/iS+bsr1jdeiwpR8FjJMqKQ//pDt/5JBgJTnhMxCLiHug1YlqUB/fU zqVrTJ+b4TGyebjGBA/ySVye8difzZgWWqCDS2EuxaiJTNAUuD7IjKTXcZ1JrynTcrZ4TElsQGFX 7njsw22lcw7WKjxkU0mk8ZjKX6Y/tCzbJbeBuZiQkuScXxFa2HY3zuem40sn41FrR03KQN/JbKTZ hONomgrjOWZfAwajpybuDYAQwiIGzQSPycWevM8eRlrzQLy1seThZdm48y/xx2mXozwPah04NEmJ 7pa7gFa/rZl11JQehmlMu2rWEd86ialYyGGlYJinzM1jYimSJl9uTjgpv4vW/aBkNPHY6B1lVs9g wNqzykpgwKb4hynGfgkSclJxTnu62i3IkteIbPGYTjNqeldT91XT9iQMHyMqz4w7mLYvaDw21xMe U5AGAV2xkGgM/Nj0gIr94x3lcLbQblfHH/cFFrrisYCCQT7umMYazAMe05FAElo0+12Jp0ZsPqfs VLFtJd9Crt9HNDBPTKo1k4ExkT8pQ3PIBywJLTxeNeuoXBcy8f9r1tEQ8ZhOFWwdaIpPVqZyDJU+ PsUt10hyLbyL+5ecRl9AYP7BDFQT29F12ipYZRhGPEbhFRDREHtfH4+5qwgdPEbT7u+Z8+BUTdEy HuRKs4Pce9mbOAVrUxiPXRH57ofsPR8sGMNPIprvnvCYsTJD+0qjU8RGSXJcaH5CmXecTys5Ui4H Kx7rbhppJ+60PFsTj725oZi0GwyPYGNvxrgUqNHw4rEnzMpaExUM/O7Cw7Xw2HibLBfhwmMXa/8Y jD08fjAU38JAR5QY8QDjbOoi4zHKjnCnJZULbUsjk0OBB04sMlLCYzaa178z29hL3XgVIijDoCMG zRCPUXs6xcSLuXMaFyjATQlGehWa2nDBY8YcvHMXvKmR1aNlgrGhC0qDGhCAmSZZ7jaBiiFdEzOS GkcV2vLdiafDiMd0muKZb/KEkjR2P/rX9KxMGkmZC5DxmGYz6uAxnws+IQ3+Cu43toKY2rs54DGj Z82gQfesm3/x7zqDVwQJ92WkcMVjAQXjj3ZumQc8pimBcAoNnUlJTWJSUQWhFd92eCnJG5posdlK 0Fc2WMjc+kKjT9OFdSlJlxW5TnVx6SMdPKZZhXDhMWN9ycznBHXRzswLRQIcCh4LqAEihMdC6X1N PBZQRejgMaoaGSDyIsS0kQe50umggL3sTZyCtSmMx66U88diUsuj4vTAWFw2bo70+WMv+Sc1aYFF ZnJc+vuz8cgpEL/y5/AQHqQVjw02FxlodyY8IYXH2Pn9tiyW1Gw4Nl0spocFj5HHZl27o4ki+qEW HjNyKqQo2zkudTwW7ImTtA3MZX1M2R98IbGhabrIm4k177kx4YTmS2P3VBneobm/0SkmNixi0Azx GIUWt3RtKwoilXdpU7ig+/qYGdafFlTvW3EsPGPIp7DWRo7TiRlGis7xjXQLbbNxysUSRjym0xQ0 NfCnuOPkBslRnQoTolCGj7I+ptOMAfHYh+YMBYok59CjSbTmsj4WqJpkLPDvhc0zNH3jiscCCgZt Z/2scWYdD3gsKAlckFIH75D8+H+ZcSQAHotJFS1j+IuW8DyjHaIvlCcojGFbkn5rCz0cCqq7PqZR hbDgMWOMw02flCHv9iHIEQoeC6gBIrg+5rX3dfCYjorQwWO+ysamLU2vv2rWUTlGyYNcBewgnV72 Jk7B2hTGY1cKHjtWWq+bBD8hGzc3GR4TY0PBY6ShaKu6uJNGo6y5BB4T2zPG+XPZR8U0Sio1+Sf1 IKAk9+l8M8EOHFaFbzEDhMTwDgseIzfOmpHpT+bkN2WYEFuoXVxnul/JyU67LK4cPEZaUlGCMh4z ItnMbWCKPNB+MMpi55tKnKTuMVPcfbAsRYPNNdXW8096Mww6YhBePKYjVAGLTUsTGKfKGW6wms+Z sZd0PoGIMZbf4o7HSAACBoK6HHtAC6HA548n5cjJLbqaC1ByAhKaee2vfci4Nzym2RRgI0ljdApN prgcokBCq2D4UY3xmE4zBsRjFLAwtHFmS3py6HiMtnNMlvxXD3iM3FxlT4iRpHRlHp3jR1tZ5MSV vre44rGAgkGLmYqP6AGPBXwRdBpkSd4eDD+VoCx1rm0r0fSTQEqkHsc3Vqq0EUCEDAQc8gFLQnbB SROGiMd0qhAWPEbbuh5o3J4h4jEdDUAm+6XGkhAWPOa593XwmI6K0MRjA8zpeHKuOkrhSB7kKmAH 6fSyN3EK1qYwHrtS8Nia09X6wYq4uSnxmLH/JDpVwWNQyv/sPyDr3sWnP9lRbgxO/0lQIrsOecC0 GoZxBW0Ff07sO8ITXlhTCCfJ2IEzwUitRt5eQnIt5aR2SpxNBxNZd/IIoCiSlVnxGG2Ulzc4BdQI KBVt55D3gVAYmJz6iTYviUwVcCZoVlK4zm+Ya4NAOGILGZx4UnZXDh4jkQCqsTaC6AI6RlzOS2vk wkbzxqSJWEQ6w0fOxpZkhhSKzN3Ug3K3kq/vGY9pisE7drkNbFMqy/fYWmsdodJxOMg2yxmu3jOL TYtmBrg1M/cIq7wgpY6cY+Eo2A4c2lCHd8nIecimEggVDWQ4f9AMic6Y2ZB289Vi+cKIkY5OpVME 5IyFRr4sXJ+YIacoQLPclXhqvl1iQ294TLMpLsw9RRsRyC6nYBszR2ZmagEzlqTV09q+wGMBm1Hs MrcemK44KHKUL1QKqVmndYD5ybXyvLuL/iG7IIem+8LOg8Fj5OqhhElyfsWYNNGApE/kYwPoIAFZ 9VnbIaBgGJ4xdcEhtQvc8ysqLRPwRSLVapKEgugwDxmP/ePUn0Xzon+pbQViN9IUmyklxUwTpIJC LoW7GXDIByzJkvR6gmfyPk/UGr3jsqtKE4/pVCEseIxgkjzTJM7gEVIXLB7T0QCkMeQUPsZ5ZaaP JPCYdXDp4DHPvW/FY9aRoqMibI2XFY8lGLVLpb1nsgPgQa4CdpBOL3sTp2BtCuOxKwWPjT5Ypo/H cHNT4rELYceNzx8zVElMqjVcUJ4vMbwr6fBByjPmO6HC8kPYDzKZb/hjGn9vtwfU2INkGoaZdufw +BLxR/sSeVnxGNUFTi3g3HzpPGh3le2rbHTqw8uyB35XZIz/8cb6jFwG35662PROy7M7+Xfky64z LBm5O1fNOgqHxjjKw38O25WDx5b5Uc3vzTQbvkYwjZnoAsOYmV18c8JJiKIBvycaWWg/lLS8kcHZ tBMoITzFbivzKBxc1MiAHOONZEq3LsyC4jZ2FZtS57SaES4xWEgyH5sOSXv7B/vtatZ7nPBYQKHS KbbvZCdzFxna04jgmpCGK+P8fUerymhP1Mg4AMffI2La3nbgJPn3R2Hk4mLfNYUUAYIeIWhBKfUm O3t4vvXziRnyshvld1ayIAr/HsXusiL35fVnjXLGpsFO26bh8hyvqNMUvgMYTL/NHXhfOBtnSiYq i5KLaSyBxwI2o3BK6NwqJUGrcCNI06Lr8RYDb5iHrVFEqLvqQBXEJLGt/qFJBzwNkoPxdbWImAgG j6GLaYnsGnPAGv6iqf0G+ie5SVdDMtstyHp0eY5xDJH/SFnhHtm2Q0DB8HXBZKkLzJYJCo8FfBEq SC7gv844ilZCV5In/X/mHEuSTwUw99JgNBmH0fkTlsghZDRqgAFgLnutLqDFSXniSWfmyL0kFyBE tDGdipZHgxs5EmJSXRZ7NfGYThXCgscWp9aR949hjp41DvoDvDd7VjghHuIVA2oAw/SYU88YZZBD I2FMjG8mWtZFyuDSwWOee9+Kx6wjRUdF2BovKx7z7f61LCR6kKuAHaTTy57FKSibwnjsSsFjHTcW 6eMx3NzEeEyc4askIoOsm6M6VZjnNyynTEDKhQvygj9oBBrNmLP3r6fBIGEkCJsUf7DWGIExqfit E8awumuKk0fltOKxqfuqyfsR2lNTZeOzoWGjfVvUoEOVpO2JqXW0aEMMeEC5jOXtJXAsjKTw41Po aEh4MJTrXxzfcdnjMULpLUUjmMe/PvdtvtIFsF4+2GA21F/ij1uxDXxuw3b6JwV+O+2wIjBf7Kow ToT0yyeMx9s/eM/noSkGvtO0TBvmsrNIucfJBQwoVJrFnn2gxjxXJ5XaE8NHDsdfmFpHJ4HSmg8E JnZPFfVOkvPAofU6Y/ucmF6ZnAmkutR/WjQ57i7JNskduafx5ulB5kKKbQL6EZvP/YM/OwsMJ3yX uIO14d0/ptMU8tAQ5xw4cRJpJL/Hhq6hN94rZVhxb0Za0jEOAzDdqVcdTvIxUJNonC/TB39fTG6K bRyBiPjyncbuR1a2+geM7rgw+zYl0wgiwtgMBo/R9DnqJdQ+7IKSX8dQSv5vgccwfn9rFk8cTevU Du6CkUSzCfTk6BQoE1ofDhaPBXzRUqrgxAy//KTes/i0CMunVoJ0GWPWP00Jr3F2YxkGmjKa7kuf MECDPde4B3WGvHtJxK5aYw4r2meM8Pkzy/n13vBYwCqEK58Hbv4Pf6YxyGen5dm05iPS83rAYzoa wEgo5Z9LhVxBmVNePtmPVwaXJh7z1vtWPGY7UnRUhNV42eIxDARc7L4y33a3tr5c6XRQwF4ORZz0 bQrjsSsFj0Ul5tqm7rBP8pGYGyE85o3hTEzeV2W7wivH7cyzHEiVZMaqzXGQ/sVp3osUkGcdqHFx E10YpYJjutz5uNvFqXXQI4mumQaBb6EmKErnKnPO2N0QXpbsa4SMAPkY0drukkD3LHAWP1gm9Mi8 5NowFj6gGMAfQu2WpNe7p5gPeI++UOmw+xsTzYZa7PoWp4EDvDfbMpBhyP/RNaWeN4Zng8ZPirBw BmwKIwv25Mwk7WVhtDz1ICXqlCe23JtRjjCEwlyeEUCzzdhfE1Rl3YePrOdRhdDHUZJpDtCJTm9B edzf4tQO7oJBXbA45EGkI4EwarhhaeOBJqPWZabWWhhorIXe2rYlUVQZzPeSyFjbsFQhICck104O ZEoioQFm7jfGWlI4BleEms52pARUEfqGyd1EhleuItHLQdkUxmNXBB7bkV9jBV1Xf5P/7ekqMD5Y v8VPmg8eY9bnF9YUyjbYl5EyOnV+Sh03DvPlxLQVwXYC9TJgWmCxPaZG4WGbzsnnHSf51xlcAsOY L0t+2zWJCDMzc3NmxmNXBB77Mr28EdxakPN5Svlx/7f4gD9xUb5nYno547FLjsfvqYwab4TVDVh7 lo49pZx13QIFDTIzX3I8cvO51vNPLs+43OoVs6fqpXVnjZE7KSPgNMri1Drjzti0HqvyR28v67Om kNKi/Dn+OEsI4zFmZmbGY4zHmhEee37bOQG0uv5QcuBsrfUeXMRX4jb8hPHYpchGvLh/Jx5FV3db me+Sn42ZmblZMc2hRMWkuuTJUEIQL2x+MPnWhVlNEMTFzHiMmZmZ8RjjsSD4fy/PA8T6v0n5SSer 3O/EDbgNN+MnjMcuXZ65vwbOHLCZ0yYKZmbm5slvbSx5c0PJwiADjOcn1364rfTv28tmH6jhNrwy ee6h2o+2l03eV8VNwczMeIzxWLPDY8nFdVELsj86WKZ5yjNuw834CX7IeIyZmZmZmZmZmZmZ8Rjj Me+8t6B2T0Gth1/tDf5XzMzMzMzMzMzMzMzMjMeYmZmZmZmZmZmZmZkZjzEzMzMzMzMzMzMzMzMe YzzGzMzMzMzMzMzMzMzMeIyZmZmZmZmZmZmZmZnxGOMxZmZmZmZmZmZmZmZmxmPMzMzMzMzMzMzM zMyMxxiPMTMzMzMzMzMzMzMzMx5jZmZmZmZmZmZmZmZmPMZ4jJmZmZmZmZmZmZmZmfHYpcdfZzYw MzMzM+szGw5mZmZmZsZjjMcYjzEzMzMzHmNmZmZmZmY8xniMmZmZmfEYMzMzMzMz4zHGY4zHmJmZ mRmPMTMzMzMzMx5jPNZMeWFK3R/nHLsz8RT7lOHiexJPo0nnp9Recl0wL7l2QUpduAq8OLUuKcgC LEtvWJwW5jE4Zmc5Stt3TSFLJuMxZmZmZmZmxmOMx5qOn/+2ICo23Z0TU+sAG6LGpfzTtMPsU4aL /2XGETTp3EO6eCwSXRCw659ekStujjtY++DSM1GxaSiGwRMz8KcLntQp8Ff7qqNiUv8cd1y/zABv //jVYZRNBxPq89s/nEdpOyw5w5LJeIyZmZmZmZnxGOOxpuOhG0tuTDghGE42vNI/zD4qX1ycVs94 rInx2OwDNVfNOvqABA8i0QVyL//HnGMGyopNly8O/r7Yt9iVWvdfZxzGDfgXoKXd/JNRE9IIlQGn ecZjM/fX4Al4mrgyast5VHzgd0Uuv4J8/mbqz4tTveOxrivz8JboHysZjzEeY2ZmZmZmZjzGeKwZ cYv4X+CVfrKzvAkWZxiPueAxY+FoXAowUpN1wbjdlXj+/4s7ZhsfeI0pGN1W5ouLiWn1jyfl4CK+ CmVBTwlWfOW7IvxKXpeLBN++KAtvGb29jPEY4zFmZmZmZmbGY5c2HoOrOumnqo+2l03ZV7Usw94L WZJeP2Zn+Yz9NeoGm9S6uIO1S9Lql2c0TNhTFbu3Cj4uriy0TPzHH6q1rkJM21f9xa4KZZUgyYwr S0g2bsa/QFYLg1lG0MFjKO3EvVWoEb1F8IIUszrpjcAq7sFFpWUSU+vG76n8eEf5TEubKPuU8Nvl GY2AAa4kNt47NNeucfDeT3eUz0uuDbgVKt7/WxTGvUgBn+l+A7oG7YYuSzR7xAmPoa1QHdyGb6+a dRSf6YE6XSC/K/rHStyDFgsdj721sQRfXR1/3FrUqMmZ+Mq20eQCQ8hRnvE/VirlocpSLUj4e68p wK86LcvGZ6eIRLnHSeDnm08I2CxmqQwpbT3/JN4yfPM5fKataDIewxW0P0Q00WGXmtOIDjjAg+qj 6furR+8oww+VYtBj6VezD9RgtMY7R70uTTfqAu20PMO78DuVJFh5Y8PBzMzMzMx4jPFYmPHYe1tL o6b87NtOMy7lN1N//mBrqYKjbpp3whfZZd4Ar1d8+/DybFzsv+4srv//7b0HlJzVma7bYOPrtXw8 a3RmvOw1w/UcPD7G9rHnYAbG14wPNlynweNhQIaxuYAN2HBxwJfBOA4Y2YyxrU5qBVCWEMoBFFEO KGehqurc1UEtde6W1K3QCpz77v1V7d7156oOaknvt56lVar+6w87fu8O348Pfz6pGg6r2/Gdekj5 tf/HxCrzzf+7tgturrkunNeFaRUkTvCfT666b1mr/PXXW7oHUI+pRy4uTV06P/7gyva+ABXzG/Hl f2zpcSwtw5fw56wda20mQcB/m56csP+c5838X3OO4IDfWzfzzMaT+OZri5rsWRrcxjXjK8w3L+08 o5be5afOj8ScccjXW5U1eOP29yJ5zS3dMrvBoSpDzxl6AHSarAXV6Ra7f1mbXNGtx8bt6zV3Ilyn JU2ULBCFg/Tpu1ZR4sfrj/dTj0lBdZRt4etLmlEFfrG5O0CPPbG2K68gnrqfwsS/bzhhjoFOMBf9 /upOx4N/aaH3bJU8nX0VJD4KXkCyGP5eKzEbqDKjx+5cePS+ZW15BTGzR+4Faw4ttEZ7pptdwSPm EQpkavmoUJx4yHocOS3qwn+d3FdoPzaz1rGXb9qhC5/ArRYmzEl+lHmVKIU/+E6yLW/sOAghhFCP UY8NpB4r2HMWbh9cwLtfb4Fv9L/mNSqnsyBeuKfXBI5TDlNB7BtLmuHzKUcQfl5B/JW0/BC/Sjnx 48o/N/fI/7NCOTpKaOXH7AH+R7WfKn81muTPJlXD73loVbu4etBCtnuqzlmgnNSvLGpyjMr3R4+p ByyM41afXNulVnwVKifbbMKJosfkWfCMcJfhHcrl8AhzvGZCnt6opmW+uazVfANnUd2Gpb5+u+0U vvlyWqEp/x5OeUnZd1Z1IH3+SruS73q50m/qUlxSOJFwZx9b3flPi1Oe5cNWnL3Qc4YegCIhLj4E Bg5QGiatHNx6bHbsIlIG2a1OMqECn0XtRMkCoEJujI7dPLseRU49jr7Q/2dJoBz0mGTi1IPns1qc lrphrcGgc/AgqAgizEwhsfUYPuOYz89TIlxtXVt//I87z0TUY0p1FCUcyYIa6v7ti9tP48zyRLgf fJZpLtFj6oclZXctboY4hKgWSWamoENrtKcec1Tw0DyaE78oozxfmN8I7YrmRZ4Xt+Q47UdmJB97 sxOl7rpXqmTbpz2HJhOwSPlnN5387qoOOae94jS08IfeSbbljR0HIYQQ6jHqsYHUY7J5xh4t/rr+ Bs6crU8eWNF3gMwAwDOz/SooK3sV0LdXtOHLJ614BvBW8c0U7Q3D81MebXGp+cnisv+dN7YMzpnM Mhkn+N8juOBZ6zE9Km++vHOBcsVGLm2NrsdkRN/WD3+uv/GcxHvt8AU8l9lDtbD0HRXcT09NFKdF 771vtNhTN+/S6vRPu8445kNMXApPPWbPw/y7Xptnb9wKPWfoAWqaYnTs8TWdGeJHa4YZWe4fC84C WVgI99ox2wbF66dIQ/WYKmC41fzY4rL/nZseszP3F1r2/OWUarcei75/zEOPBSZL9P1jqFm4pb6s f1kVj99uPxWxRnvqMUcFD80jNdE3OvZx6wA1I2pNr8lp/352wxJLfcnC0Re2nrLnlu1hBSh/1VAU xM0yy9DCH3on2ZY3dhyEEEKox6jHBlKPyYJA25uZH79Ysrd3SnoaQXlIBXF7NxE+qwH1kjLHuiNn xDkrRsKrWpMYh1W8VSP5hH9apM7zxJqu/kd9yCqex6+2dNvOaBQ99t+mqzmHZzedtN1EJNprPht+ 1M8LYrLh6gU9FfbImx16mD/laqvJqMK4bAESDWOcRVsA3DK7IUCP2aJoduyinoIrt3VRwDlDD1Ar KvU0y8LMNZADEs/DkQUiMxzi9r/o1Wi2zMhKjy0ofUdmUbItS35FUZbaygawgdJjwckSXY/dmblC 8p90Df1BWleH1mhPPeao4KF5pJa26jiWtgBGHRmXzkHP04oENc2RSqKSsgWZ271kb56pO6GFP/RO si1v7DgIIYRQj1GPDaQeg8aQMekPTqn+1vK2ksxlgbLpK29sGZwnm7wxaj2P6AdPvyo1IVYQE4ki 7qmZLvuC1jz/c1a9fc6Pz1Qi6u7XW4ZYj/1+x2lZqhRdj8F1U/N7+WpB2uNrOgN2dglIWDP99X/D 4yxKQB7AQfwzrX9k85gZv39aj9b/5ZRqO3HET/3glOoAPeYQRWqBWdrDDj1n6AFj9YyB+xVbA6LH HFkgM3VfXpRR5ORCv9nak/v8WIHakbVkgPQY7hbfy1rEQdJjjmTJOb6i2ks2OvaYXp4XpUZH0WOh ebSoNDUlfs34iq8vaUZldMxMep722c1qGfMnXq1LNU1ecS//oIPE3DqnIWLhD72TbMsbOw5CCCHU Y9RjAxzPY8bbF+5a3GxCeqhYC+mhYrgjjrABNhLHzE+PiUsqq92UQCqIv5beXgUX3++c/2te4/DX Y7Lv7nNzj5gNVHD4AqZuivb0ynwgxABc4Zv0i6q+qWcmkYYvbD1l72b5V7120ZNrJ1TkpsdCzxl6 wO/0JIN7gm7A9VhqIsuHn4RF9QjYPyZ7FGdEfnV1sB67Y4EqJ7Ip7jLSY1FqdKgei5hHEEIPrWzv C9dRUvbtFW1LAvWYaLC/nKKi/jynVxXeNs85PThBFyqT2qGFP/hOcihv7DgIIYRQj1GPDbAeMxTv 6VWum9YYP9OL8Yr39kpYggC30k+PqVVDBXFII/UhP36T9bbcT89ScwsmZEjOL326hHrMbAb77fZT dy48qvy/4kRA6HDIMEiX0TrypMQJGKPT9pE3O+7RWsi4wrKU8TvWnplQQl3S0HOGHiBO8EdmDMX8 mCqBxYncsj5Aj31MT8BCWLr/9ODK9htmJM22pShF8VOz1G46CUt4GemxKDU6SgXPKo+mHDz/RDqY qgkr6nnaP+06Y26vRN/qja75sRd1sphnjKLHgu8k2/LGjoMQQgj1GPXYQOoxeCfAXsT1o/XH4ayI fJovu4bGOrdwRNFjqTVd+XGJRmgHE5fZmEet+GbDR4/JZpvvZ96brcdmvH3hsTc7f5W52+Q2HU8v 4Ilun9coEd7UGs50RO9rJ1TcMD2Jk1/3St9rAGSDmS1f+6/HQs8ZesACtagy5t7MMxh6TFK7JJuI mlH0mESt8HxGmTpz621zw+96udK5+lGv8pVdWJeRHotSo6NU8NA8+vVbPagm9lJeVRhQhMaULvE/ rbQVopRUkdO72hyrKGXLq4l6H1r4Q+8k2/LGjoMQQgj1GPXYQOqxG3Q4bNsrkmhjxm1Vq/JGx+6x PEs4Md9Y0mz0VYAe+/UWifaWyCsutf0/Fb4sX4XknmIFHy/e2/v5eUdkTaOnezo/fnFR2aDrMbhu +O+nZ9VnBKPPjxt/XXm0RYm8grh98zKrht/63VIq8F1+xhSTjpyuYvr/85JmezGYyAN77wruHJJv 7L7e3PRY6DmjXFQ0px2XT0Wu0y8r81sEKLEl7QSPkgU/WKdGBFAybUf86Y0nvrmsdXFZ7npsUanW Xfkx+9VSKMwPrVTxIf7PaTXB8RXtYKEit0xWuvXYL7ziagy4HpMQOHbVC9VjUWp0FD0WmkdyUftO 1FpEXevt06KdMXmKRJBCaF6G9mX9gN+0IkyqQEFjSvMKE5Mz4ysGFP7QO4lS3uzGhx0HIYQQ6jHq sYHUYyr0c0EcAuPWOQ3w2FQIB71e0cReh6stjiNEziNvdty3rFV2f5kXagXoMXjAEifgzgVOx1Sc JFzrX99oeXxNp3rvWXHimvEVonnc7qmKQ1CYeNeEiijxyvujx9Tz6mD0cK+/tbxNTfGl30Vr5k9k hWHe+HL4i0iTv5/dIP5fwLut5uhFmw7NJquz1K1mLqJLKcB8NZ/2xJquuxY3I2XyCuOe7zKOuGQr 9JyhB6hZheKE+NBQZeotaiqCfDx4U5ZMPkCZyORhlCyAPLhBR7C87pWqB1a0fWdVhyxwRbbOD5vV CdBjqQvpAnnjzNr7l7WpUievAB5TOsUn71J6DEUiP/4/ZtXhfkTP4L9/SL9YzK3H5ujFuijeKCo/ 99E5/ddjsvMQv0JBldeURdFjoTU6ih4LzaNJEE76DRb/fUYt/nr36y0Sdv9f0zow9f4xPX0KSYyT SFyNT1lrKZWeH18usX++v7pTvRaiRJ3zeWvUILTwh95J6LM4Gh92HIQQQqjHqMcGeP/YH3eeUa/P 0o61LM1yeJCvHr6Qcr71Ade9Umm/hCpAj5kXrf5+h8emnWc3nbwmHUQEjv4nXq2bnl5T5K3HihP4 ZrD1WCrmwdiy1I0VJaA9JPajvZ7tibVdMpYvfGRGsnhPyHonmYq0/f4lEny8OAHh6t7Lp7xkPfsE zx6fX/J5rXD0LTSh5ww9YOy+3tTrd7WWfnJtl7yULECP/ceWHtmuI/HHI2YBEkTFO0mHS0EqfWVR kyPUfg56TBWkg+fVPRcnTP7ePr8xIEKm3PDHZtaqKS9TKsZX2BLarccAio3IHr+A9f3XYwsS76g3 dOmXU0s4+yh6LLRGR1yQHJpHqM6q4hQlTIGBbjT1V04L8fPfdW2VInf7vEbHQkqkzK1zGlInKYij ojlapyiFP/hOQp/F0fiw4yCEEEI9Rj02KPE84AbB2371sK9jCl9kwv5zs9MxEgcK+Fs4bZQo5LjD bF/m2x8mHzg/6cD54BtDaiDR5MVig8H8xDvj9vdG3+ozIOcMPQCFJCByiV84kNxKDuTT1EMXBjxh l+jpvhzOPO3QhWmRfwWHHlJtQek7g1pQX9PZkUPVGKgaHZxHS3Tu45gl/jJvni5yAXpbbnV+/yqC 351EeRa78WHHQQghhHqMemyw4isSQsjQEDyvPpxhx0EIIYR6jHqMeowQQj1GPUYIIYRQj1GPEUII 9RghhBBCPUY9Rj1GCLlcGL+/d9S2UwGRYKjHCCGEEOox6jFCCCHUY4QQQqjHqMcIIYQQQgghhHqM EEIIIYQQQqjHqMcIIYQQQgghhHqMEEIIIYQQQqjHqMcIIYQQQgghhHqMEEIIIYQQQqjHqMcIIYQQ Qggh1GPUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQQgghhBBC PUYIIYQQQggh1GPUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQ QgghhBDqMeoxQgghhBBCCKEeI4QQQgghhBDqMeoxQgghhBBCCKEeI4QQQgghhBDqMeoxQgghhBBC CLnS9BiNRqPRaDQajUaj0ajHaDQajUaj0Wg0Go16jEaj0Wg0Go1Go9Fo1GM0Go1Go9FoNBqNRj1G o9FoNBqNRqPRaDTqMRqNRqPRaDQajUajHqPRaDQajUaj0Wg06jEajUaj0Wg0Go1Go1GP0Wg0Go1G o9FoNBr1GI1Go9FoNBqNRqPRqMdoNBqNRqPRaDQajXqMRqPRaDQajUaj0WjUYzQajUaj0Wg0Go1G PUaj0Wg0Go1Go9FoNOoxGo1Go9FoNBqNRqMeo9FoNBqNRqPRaDQa9RiNRqPRaDQajUajUY/RaDQa jUaj0Wg0GvUYjUaj0Wg0Go1Go9Gox2g0Go1Go9FoNBqNeoxGo9FoNBqNRqPRaNRjNBqNRqPRaDQa jUY9RqPRaDQajUaj0Wg06jEajUaj0Wg0Go1Gu5r1WO2pdwghhBBCCCHkqoJ6jBBCCCGEEEKoxwgh hBBCCCGEeox6jBBCCCGEEEKoxwghhBBCCCGEeox6jBBCCCGEEEKoxwghhBBCCCGEeox6jBBCCCGE EEKoxwghhBBCCCGEeox6jBBCCCGEEEKoxwghhBBCCCGEeox6jBBCCCGEEEKoxwghhBBCCCGEeox6 jBBCCCGEEEI9Rj1GCCGEEEIIIdRjhBBCCCGEEEI9Rj1GCCGEEEIIIdRjhBBCCCGEEEI9Rj1GCCGE EEIIIdRjhBBCCCGEEEI9Rj1GCCGEEEIIIdRjA8jSI72AxYUQQgghhBBCPTbUfGPjccDiQgghhBBC CKEeG1L2dVzIm9EE8IElhhBCCCGEEEI9NnQ8s68nb1oTwAeWGEIIIYQQQgj12BBR1fNO3rxm0WP4 gP+y0BBCCCGEEEKox4aC8eVnUmJMg/+y0BBCCCGEEEKox4aC/7G83dZj+C8LTQDJU+/sbjtX7TOL WNX9TtmJi8PqhuNdFz49u+ae5Y1X4dUdlB6/kLwMixzScPBO/vRbrciglfWnB/ZyOST1MKw75Ooh cVy1VHcva2RSBDNqdwcSak5lFlsbRu1qx0/mVnI3RB93Lq7/uzk1w/wm97efrzg5rNvkkSuOomi9 3XmBzgP12GWvx1Y1nrPFmIAvh+DS9y5vzCspBV9f2uD406PrmuVPz+0cRuJwwuHjH59VnTcmkTc6 llcQ+9C0yqKDXclMqTZiSkXe2NLDncMoLMqhzvO44b+YWnEVXt1m87GzeUXxm+cmL6/2q+hAFxIQ qmmQzn/XGw04v3GV7l95FGV7Tv88pxySuv91B3IOLca1L5f7yU78FX4hPv98e5s0LwHAO799YV3w MTdpd0qum8H4so/OrEb7traBaw0uG+DSDZOWapjz3bVNSKhxb2cRjfk72f/kigetBNIkYJjMr9n5 8PQqj2PGlqLofnFRHbwUtEiOs31ufi2OeWarRyeysKobf/rq6/X2l+sbz3x5SX3K1SmMf+zV6h9u aqnsHo7C7K+nVeIm97Wdo/NAPXbZ67GRm0+49Ri+HIJLqwqP2q6ZUX7S/tO3Vh2T73+6NQs39Pmd 7dBISiYd6BrwObFvv6lvqSSOJg9y8YYZVXKHI1cctY+8cVb1eyaVlx6/ZHpsZ0svfEEk4IArosmJ Ezjz7/d2ZnXM8NFj25t788aVOTqe4c/E+An0iyIkhkCPPbGhBd3zkpqegU3qKIWnn3VH6SJUyeKE 519/sLEFf/3l9jZ8LjnU9YVFdQbcKv708VnV9pdlJy7iJxmH5av6bn/z6Lqmvuvm9/3ps/Nq0XnL l6N2d7APph7Llp9saUF9WVZ76nLUY7cvrMPNJ6nH+qHHpL36wNQKu8ER/m3VUfcxn19Yh6IrbRQ8 K8f6HTWOrAaR42saTjsuNKeyB3+6bUGt+QaNPzQYvrxuYjmuBYdHWrPPzE0Oq4HmodRjl6nzQD12 OemxPe0X8mY2ufVY3sxm/Gko9dh7J5WXW9PiuemxJze0yK+eH+hZtbFvH8dpR0yt2HLsrPlyK6ro 2FJ8P+ZQ1/DJUzWQMzr2yddqBlwRvbSvE+f50aaWrI4ZPnpMdPVlukR28E7u0GMDdblk9oWnn0TX Yx6Dx5kp4O0/aack4nVjXRf+tL9T/aQgbq8FJdRjUfjnZapWvlbRfTnqsWtfVkqjpod6rL96zLO9 CjgGZVja83uXNybdemx0DDq5pidEj71nUjm+mXD4uL1U76E1Kge//eaxq1OPXb7OA/XYMNJjq4+e m1lztjhx+j8O9Dyxs/veTSc+v7rzI2+05c1vyXu12UOJ2eCA+S04GD/BD/FznASnwglx2oHVY+An W1qi6LGyExcXVnWvO3LGnpSv7lF7uqTJUIu7trTgv469KNB7+OH6xjPurV+r6k6/HDvut3cFx79/ smqhFlU7PbZfbG/D95+d19eWoV3YnW4a5HPStQoZXzq26ODeFlR1Q+A5zn+g/fye1nNmhAZN53bX MY5EWFzTI80uPu9vP+9QRGiL1zScxrUOdpz3PAn8SPx1ed2phDVNgZTB2X61Qz3sI2ub8Nk9TuZ3 TFZXR1otqz2FYxwrLnBXOGHFyYs4A7zbNzMdXL9feaaP+9JIJRQMpJvfXdn7Bg/pY3AbaxvOBDyI qnr1p5GM5ZEX37/VdHZ2RTeezlEOJWFNgdmtC5Ubd+ndcuzskpqe0Okmhx5Dj46zmaUpkvLyX3zA YXsze75tuljuaOn1S+oohcddd7JN7eGmx4SnNrfiTz/e7D2oZGo3HnbT0bN4QLvS4alRztHmHMqy soSWKHPba4+cgce/watJNIUNZ3A0to7VyPMqe6Thkkx3Z27E6umoaNJ2OZpN+z5rfKpzxGJvGl4c jHTGvQXoMTwUHnNX67kodx690O5s6cUBjq0vUgG/pDvH8YePe1ZtuXP8SQqMPAVaG78uzK9/iZ5H qOCoIJIpAXpsr67CeRPUMCWSy3R/th5D+uBUKFR+pQ4pNj99rVAkndF6y7NL6tX0RD1nVj2sZ9GS TJdcPqgfLWZ17mg5kS+oxe5LD4Yesz0r+/uUHhun1h+iKQ7QY8homRlzF6G8gti7XinzK2CmNOLx 0Z+iQctoKDrO40JoampyzXTk74Iqj7bI1mPBORiQF6HFIFvnof8JQj12Beqx6TVn82Y1heiubJnV hNMOuB7LK4xvTs8+eeoxVKS/m1MjM+niAKHFkTZ949GzGafSmA4D3e0tc5OpFUR6zeEf9vUtIkI/ lFp56BNzAj/HX6+fVunZRqB1s5ck2Y2s2n/iUnFqf87oGOSf6cDuWFSHZ5F7eM+k8jeSpxxtDTTk X02tNM8FB9rTy0dT5UiBD2jfwiiiqaUnZUJPli442nF4b594rabv52MSv0gf8OLuDseZH1jtHCfz Oybi1ZGPqpvXqSdXzz/Q6RheRTrL0N3fpBfQB//KAdo+HGNvoYbIuWd5Y98958fuW3nUL5qFPMin ZtcEPwh6iwdXH+u7pQIlQoK3RCN/cdq+2yjJOOd/7uk0oxXo+93lXHhxT18hfGlvp1q7kv4TbiBg 6b9Djzn+q55ldKzoQJddNnC3ca3br5tYZr78yuv1xlOxkzpK4XHXnYipPcz12JTECfwJvrXnCT+o KzW8kGtfLjcl8OE1ag3kC7vaUQzMUzs2foQW++ASBZCqcLnMAe+bXD69LGPFOHSafQAyelrmAWj6 vrH0iDngQ9Mq0abhwzet9dtZVc/MCZZypLZda2S5+MT4CfsOHY12VsU+lcimNxlbKhs1HXoMMkz5 svmpc75/cvnryZ7gvbJRCi0qhX2r/zCv1oxEfPX1ekd9GX/YQ/m8Ej8hE85qE1FB+inGlc0q73YI pID+JUoeQTR+JL04X9bC3avbTE89Jkt/bcT3lQYc3e6di/ue7sPTq9Dp2D9HX/lJtDPp1L51bnJP oAZWWsLceb7aZHuHPv9Oa3go+JwRe9iAoiWZfsOMqqe3pJbnoNbLCIJKKFPARsfQ19gDLoOnx6T5 RaV26LHRBzrV/RT1OVpuPabktHbGdrb0ulcJvbSv01PzTzis6v4TG1rEvRGufbls7ZEzkOVmdk4y fePR7DIdJ/kM/Ld0SkITTk6ccOQgTvKhab45GJoXocUgW+ehPwlCPXYlr1dc0dibN7d5wMTY3Gac cGDXK5rm3kw0ufXYaoiiklK3G3qv7o8D9Ni25l4ZrnNgRokm6o4N3OKzWXOSPuCflzVkuwhhnF7l KJtMzGCeOqCkVFwNNBPq2Qtij69vRqereuIC1RSaVZHSTKCPhMv4u90dOJV0eL/e0e45iIsGV6bs 4Dfg8yTtvkiHIQ3x3csa0aSqxTDauTT7E9TyaCRvUfyhNU1IENXQ60QrOtgljRHONlK3Pl9YVIfP 7v1FfsdEuTp4QPv98OmRDuoxS/qubrpzNHlo0f5lWaMRisG/CtVjMgiNDgCOApJU2mK/NeKpB4Fn U5xwPMjyur4HGbniqJyz8EDnn/Z3qhEEvfLer8DEui6I44uGu+RQl9q+pYvQi2mRb+sxgBphY1LG uFlS6tDKw69CIRcFi66iP3oM5//HBbW4JRQMuVu1f7Iojqf77e4OdQ+6tDyVngiykzpK4fHTY6Gp Pcz12O/3qrxD+gToMVSNf1t1FCUQSkY0mJK+hXGUQ/z860sbxJmebS1dCy72oSUKCag8+LGlT25o gY+lSiyqZ2F8RXraWVo8iCKUOvj9yqUoUvXX9huUl6/Vy3M720ft7rgZDpP2qGw9llX1tEGC2Dmi hiF0AbvXUl+QImpVVXpgK9ti/1sZJigphRv9x/2d96ZdK1uP6U4njuYXjj7SQc12qgWoGXmRQxNR sL9TmmjcA1JGqgYadpEuUICoIzdqjw39Aj57zmuJHlMRF8aXPbquGZmLNkd9M77MDIuE9i+heQTn G+6v+Ot4HKSDkSWeegzFSTn9Woui9cNn8WhTzVRRHG0sWq2fbWuVwn/7wrqM9nmsioXz/M52ZKIM AI2YUuE3jaYGUnWRg1bH8SoGGH6uvzFaIvScUXrY4KKVyvR8NfQGKf7wmiZZviE7zNHFFB/s+s3O 9uv1hewCOXh6DLxb55pZtiAC4PVkzzNbW6VlTvqvV/zbmVWSNQeiTVEa+YFEwGMic5F6H51ZLW0I 7gQJjuui8EgP++nZNdEzHdpMjfoVxPGwuIryDFHm82Pz0o1DKgeL4gE5GJoXocUgW+ch5wShHrvy 94/taDv/l4tb+y/GcBKcasD3j6Fb+tirqQEDWbXs0GOQMbIkHaBarj1yBt2wGYCcVnYSB6AzSzX6 o2Mo6yZO6/XpURP0uGiPUNlSA88lcWluUPPh3+OKOK3nfcLhwPHwXbLVY+jMcBX0Z0lrtFX8JPnv fXrs5OdWeyqTCSbmsjQT9nwCHCwZgs12/xgYa/WgksJmJRWaDLQdP7S296DlkuZmQPaPBV+9SF8L TaFjrg89n7TLkrPoEe3BudBfBesxuK3ivphz7m07J86T54K6KA+Cphn//eKiOrMIAc66uPslPpsM 1VD6aKV2HN+YOUCHHnOs1blpjnLCjECFp6V867Gl5qHUEMAE5aZs8hmEi6LHvvZGg3sa1valZpar e0bv4td7RSk8HnosMLW9dVFBHFdxIx7JUOoxFKc/m1LheAS3HrMnNs1cou1MyLZYmTeLUuxDS9T3 4LlmJsVj+ht4tH0Jkh+zZ1pklNeMjsmaAqg+U1NQzL6iJ3aMHsu2erqHwExpQbud0h7jEua3aky9 IFVVsy32qmVGYcuP2eENRKGNSOsxNNoiRexhowVValIOGef5CFEKrUqEghh8MnsZqnjJdhCm0P1j KT1WUoq6Zr4cocubkYuh/UtoHqEcykRB0lpXNiKwVAfsH4NbbDJod+s5cVjN8jPZFGBPP8pUIXSd 51VQwtWiCSvQkSonupIaPRZ6ztAeNrRomUy3W3i1ayA/o5uWdYC4PVNyouixm+cmHe3Ys9tao+ix m/Q44OL0yJfRY0ht8YhMs+PWY3iu1MKHMQmUQ7QeoSHvRX6guTOLb5PpB4SwMUmn+lw9l2sKf2gG SS7bm9lkAP0TaQ8nNAej5EXoSbJ1HnJOEOqxqyKex+HjF/9+ZUd/xBh+jpMMRjwPdBIr6k/LyBaa 8njXBYceW61XDDp0yE/SywPMoKk7nkdq8l3PcZu6l4qUaC0aDA11JRrPXsGIS9j4DXp9U8+WmAkB 6ZbM0I7qtwrj9mpmSEQ1hDm+zG4m7B07h/UmB79l3NHjeUzWK6n+xf9lO6XH1YXebV1oAON5OK4u zseUREZUT+k2xNuQdHN4AKG/CtZjakF8kZoWsPc+vdV0dm3DGc/loFEeRFzSVXUZ29vUdMToGIST Z4rN190hMtp2X3AP69OPEKDHZHsSeqxkZvobx1p4RKcezpOzHpuQWVPEIbMFTIUkZlqTDJQey6rQ pnRRIIOox/SyNAGZZZZ32rrIU4/ZGw/2iJNanLDX0ogGMA5TaLEPLVGysOpBy/lAZccBO1p8Fz6I ojN+vLS0jo0osjjT6LFsq6cNHh8V88ZZ1X1+Z0FMtiDO19mkBFVB3NSpbIv9DD18cMfi+oB4Hmu1 MrljUZ3jt5/Xq9Dne5WWKIX2d1oR/SYz4lRKHxbEjTiJqMcc8RXUuP7o2B/Tvmxo/xKaRzJO6tiv O1DxPD48Xc1abNFLFqXbMkMGtiy/640Gb0WtN0Q5pMLf6HOKHotyztAeNrRoSaaPiBAGRtYBmSWa UfSYB+MSUfSYzN6YsNVGj6kFU+JrjUlIfXfrMamAqo6b1acl8cfXNwe840vkx0NrMhYCiBfn6Lk+ o2dxl+oxjtAMUhpmTMJeeClf4q9fWFSXzNVHcudF6EmydR5ySxDqsasovmJl9zv3bDqRmxjDDyu7 B/h+bD3Wt6RhdOyxdc0OPSZtoqMoi9shs9t+esysRcQx9608KsgSMntWIRiZH3vCmh9zb4lJ+uix ufomH0u35jJbLQfv0r7XNRNK8eA2sulWRlA8YwepxnR8f/WYOHlfyVybh6b5e+uav/ZGw61zk7fo ZsJ+m9MA6jHH1WWQDI2XnQ7iFszUPYpndx76q9D1ij/US57Q2Yxc3ogGNDgGQJQHUQPqRXH3Xnk0 3MhoPxUhBfK6ieUoJygwjg2+fnpM9s/girZDL/MYdy6ut9NEhhj9Jnhz0GOyN8nhVatyWxAbVD3m WWjd81S7W8+5eVgH+xlEPebiuollaDoCArq49Vhqf2Bm7UYfb6+mDi32oSUKHrDsWIO3/czWVs+X pFV2Xyw62IVEgyDBpcXN/cbSI/LXr+lC4li259Bj2VZPB7fqBZASGgHFAPcAXYFvZPm3FH6Tm9kW exFFjnf6OfTYH/Wqwp9tc07G/lTPZb3k9eaGKIUWwsweoct43tF9s3kR9dgDmXpM7SUbHfud7k+j 9C+heaRVYiw5OPEVxROVZSmyHOOjM6vtOxE3AKXUc8+t5zoRW49FOWdoDxtatAICCG88evapza13 L2v87Lxa1Z/qhTlmsWgUPfbjza2OdszeWxU6P2b2rtt6zPxQ5kU99Zhp2aaWnjRLplEw/MIYesqP H+vhQseAiHh9cmOhGSS57B4TCY2v6PaRgvMi9CTZOg+5JQj12FUX7/7pvd3ZijH8ZDDuxKHH1ICE zOfmx8zosugxWWADXrAWJ0j3aY8YufWY9E9+2Du7AkBVcSzZOtRxHk6MIF6anx6TRS/wzPD5jeQp 2z+QJV5+SHifIdNj8BpvSW8/QGeDZkv2qg6BHlNDTf7pUKg3l7u78yi/CtVjqt2MHVfuuGyIL4rj qWOB8TwCHkSGbN2RqWrTu1/8Iimh20Of2rdpflzZs9tak4F6TK32GadcpcWZjp1Z9+vG8aK8K1iP XZr9Y0VxeA8CuvkocTVz0GMRi31wiZLVNY+uazYRO5DO9iQJBJvsP8H3dyxW8RvUG9UsPXazbisc 7zKy9VgO1dPB83oUDOeUvcG/1X0EvMz3TCo3ubkuvcI822L/lJdj5NBjj69XnY47AInsCfScr45S aGUbiXtL2F1LM+pd//VYaP8SmkdqYd5oj75mMPSY73SQXjzpvsRCnaruSDm2HotyztAeNrRo+emx 1NWLE6i5yE21S1BPN2Wlx3LePyZLbU0xc+gxZP0IvQ8QuRygx+wogrdpCWovbe2//AjNoGllJ4N3 gUb0kULzIgc9Fuw8UI9Rj0WlMH46b3o0MTa9CQcP0m049BgYo9fs2ogeG5Wej7L3c4vwkHAgfnrs T/tTE2t/O7MKPboDtOlR7lOvjVHbrz1fQCFDR0n/TbrSFkCMSQdvRqMlbOMXBmLsp/967AmddPjX dKLVujMemvkxtRWwJB5wWs/uPPRXUfSYWZyAtlWcTs9AmlEfZFzCrQdUSuZHeq/RjpZeeHvSU343 HQTCrcdwQpkAcYd1kfBiK7J54RX12ODF8xhwPZZtsfcsUbWZr/pQTrzei2vWb4sPagcxk/koo8dk sMaRYo75sWyrp3tuQe75lzpAkXjYo3Ypkba6/jT8S3vgI9tiL5rKEbXSocdkO5l7DYUsX/dUI1EK rfR6jiCHQGq0WTHVfz0WpX8JzSM1kFQYH4L5sRd0zj4X+cWh6uWfXo25rceinDO0hw0tWp6ZLgti b5qTtKP1yijzEOgx8QHsjesOPWZGmVEA5N2qRo8trT0FLeEOrpgKmZYZ9bSfeiw0g2Sjyhf75yNF yYvc9FiA80A9Rj0WFTXuNStqaPvBez2CW4+ZNtqhx8QbcEw+SN9sewlGj5kWamk6lj28JXsZ/boj ZxxhW5MRVn5P8Io7HKrHZB/C99Y1v29yue3rp1bATygN2Cw7ZHpMHtBeCyFe5tDoMQkm5hhuD9Vj ob8K1mPoYuFy2XHPoHMkdpbnOaM8iAgVRwBAWVh7j8/bFKaWnsRt2CmvcjBfzfomffSYrJTw9LSk h7ZfwEA9doXpsdBiH1qioEaA3eKpmHjp2Ya43qpuFoELs8oz9JjsQHNolcmZeizb6unmvZPKkURw Jc2I2069EV+18wUZ+9+yLfazdYfiqEEOPSbH2EFr0ivBkp4TXBELrfhkjpEUta2/JC7LKAZKj0Xp X0LzSGr6isHZP2brsVfLuwPeDOFGDXIVZITZsPekiZyIcs7QHja0aHlmuqzoccRwElE0BHpMNo89 ZcU9cusxk48SusPoMXGr3O99ld0W+NNuryWLucmP0AwyS04cXigknIlrEpqDUfIiWz0W6jxQj1GP RWVV47noixVx8FDqMbViuCDu0GMo6+a9EPevPDqvskc5qWNS71QxrYx4FTIbBqfkraazqMbmVQ84 w292tqOXVRsAihN3pIPgwR9SAV7HJQICMS+p0YGbJpQ6tl2i7sndJgOD2KpBO71e2dF0yl4CtKq2 Q/b4+mbzmp0c9NihDrXLwt5eHMVLMO8nqc0MOW1faJLXDnLPwGj2MVGuLls10D3bneuYQ10QITU9 vt156K+C9ZgJlZa0mlSZSfDcURPlQSboVzDdOjdpfCDc26e1TzPBJ3iMuFC2X7Wl6awqVOmUd+gx WYaEThT3U+v5Djr9W3uf8Zv1p0cub/TbjT00eixK4aEei6LHQot9aIkSP9iuTRJn78tL0studWgl 46wc7rwg4zUm5dUJ9csnjOpDgZcZHqPHQu8TRRQt+W7/F0zZ8XLNl2q9n84I+31o2RZ71PT3aufJ doNkOM+0nLhJ2Ullb5ObXpYRRzSHJkLFdtNdif12aVk68bDlvT3iFcEoKz0WpX8JzSPpUj+/sM4E GlETU7qeBtzb9a7oCKF6rPzkxffpzWz23kKk5z3LG/3iHst7AuyyoaLOWPHuo5wztIcNLVqemS6t jT0GJ2+3M887SHoMVVUy/c7F9XYIUE89Vnr8glmxbBYibtcTj2jMV2eKcOl3/IJk5CY/omSQDEzY MTYltpCZNIuoqIPzIls9Fuo85KzHUO8S0d5lTz12heix3x46FV2P4eCh1GOOVcVmnEatFy+Ku9cZ 24tw1A4065V/Ev4r9YIL1w9Rl6TDKEivafTcN+xs64viuO2fbWt9anOr2tSu3zpi72rzbGRlLwTY lel8qBip+ni0hqN2tT+9pUVWChnnOwc9Zhpf+L4yqhfFSxCnHz4lHurRdc3KU0y/n9E4NGrgXEf+ /eEm9VYiz0u7j4ly9WR6Rwqui7RFcskqESSLOAqe3Xnor4L1GBo+0RUfnl6FBMcZRDh94rWaZK7O Vm36JeDwX1H80FPKeO0P/eeF4N9co6Mn/8O82ud2tj+xoUWCpBsvytZjKu6c3o4PyYdssnlpX2fG nsmxpTjDi3s6Ruq3WqHf3dJ09hLqsSiFh3osih4LLfahJUo1ZYXqtVp3LW2A76420OsW0rwSWsoA bgO5r8oPzqZHnezpfXlvFfwznB9nNuNlRo+F3qfES3zRf+bB7ICyx0d+rpcvIi8cdTzbYi8vlcJ5 8CDw6VU4Df2M9khWqtMpiEMp/X5vp3rkAjXjtL25t7YfTYQEkcd50Ikg/b+o3+R205ykPZElE5K4 GfSAni/ci6LHQvuX0DyqTotSCf2Cy5nCEKDHpK6h+OGcEsg7VI+lVsHgzPlqyBWNXmp/Y1Hc8aby jFlfPSYL7YFSoQpt2kMwy+1Czxmlhw0uWp6ZrhaLalcEz4hfqaEK5SrE7XeaR9FjfzuzCpdzYN6L YB8DGaYyV6/WQfY5JkU99Zi98sjeGFYIEV6UqguPrWsGqZcG5fcFbBwQPRYlg5Q+1K3TfSuPoq1I BRcZ2zcyHpqDUfIiWz0W6jzknCDKYSiKh0agpR67cvTY1zZ0RddjOHiI9Rh6gtTrLzLnzVFGVdSg 9OwZjilwvZkEzaXxDExMYXRLapQlPZ927ctlaL/MYuI9refUIE1R3H4RkJ8ky9jdO74MTpIjoIJn I6vCWOerd4m4z3mg/bzdkXxgaoV9G7npMdynvLVTRrMiegnqRdLpJEL3vKSm5wP6JHYoMOUM6QcM CJTvOCbi1eHUqo0ZaeV87cvl8IEquy8GDK+G/ip0/xiOVGH3xqej+hbE0ej7vQQz4oOgpVb997hU St4wo+rZba3B5Wp32zkVsCud+HgcFHszxWfrMfP+Bjd2h4rOwAx8wnWARNzddu7SrleMUniox6Lo sSjFPrhE1ep38qh3pKbb0hFTKmyRHOu6MDL9fmS0NrctqF1Vd1rUS9K6VTWhVJy6BHwd2XB1v7X5 Pvg+JVBhgFuvAk4UO6Ndb9L7WDzDD2RV7FOz2em6D8mqFkGMSTgCl0MtqEV9+alkRNl7M8utRJ6F dlL8hKxukuVY337zmOOdh/Cnv7H0iPiRf/R6AVcUPRbav0QpS7gxpRgLYlIA4GKiQQvOuI1Hz96c 3ncgoiWKHpPdjKqHldQujONz8DquNQ2nTXefV1KKRxPlYE+6Bp8zYg8bULT84nlMKzvZ95NxiT/t 75QhDBOxM8d49/opPI+5ZkIpkhQXcgcT8tNjJoCkI1DHyvrTamDR9IzaewnYb9+f5XmhmQ513Rc2 ozAOJ9B+MX2UHAzNixz2jwU7DzkniFqJMCax0edlodRjV6Aey5vX4hm6wzvIx7yWYZWd6D/WN54J eBVGrX4RxH6XV53UI8d+y2M8Z1Q8gbMCD+nggL6/D64S/IzDnQM5T70x+xMibfErP0FimiG0TcHh 46Ic4wca312t54bmV3a4QqS/n5DLjR0tvcEp6S6fuAc8SHKAbgCOAk6YHE6Vtz8Fg2Rb7ENLFJx+ eMN+pRRNIv4a/BKI6h7lqcgCG1l094zXzhPP+xTlv7t1gNfDZ1vs0SmE1lMkBRrGAd9KjVvd1twb dEDHedxe/68bpX8JLktIAWR0dU92DeDetlwyF9dCF18RuZVA9smLpN6WBTKFcfd9ZnvOgWpRkQhb A7N4+Lcwm48NcM+YW6b3v+8YpLwYWOchqcehuF7xatFj29vOu0XXR5e2rWjsBfjg/it+QteHEEKI We+33pogTaZDbE8rOxnRickrinsuGSAkCpCXL+xqt9XRH/Z1yPusmDiEUI9dBnpsTOnpDLk1u/kP sdP2KhT8F1/ax5SUnmYxIoQQIpEAVLC1kvgzW1tfq+j+9Y52WSf2mcj6au2RM383p2ZP6zkmJskN iQT4ufm1RQe6ppWdvHtZo6yenVfZw8QhhHrsMtBjD2w9aYTWNzefOOi1hgFf4k/mMPyExYgQQohZ yCTbCA1fX9qwv50rKcjQ8bvdHX2bJHWIFM930hBCqMeGox770OJWSKy/XtK2pD5kKS0OwGE4GD9h MSKEEJKxo6bj/Izyk6+Wd7tfIEvIEFDTo6J6TIgdX153KvomcEII9dilXnJ9/GLe7KZRh05F3CKM w3AwfoIfsiQRQgghhBBCqMdyZ2/7hT3tF3L41d72CyxJhBBCCCGEEOoxQgghhBBCCKEeox4jhBBC CCGEEOoxQgghhBBCCKEeox4jhBBCCCGEEOoxQgghhBBCCKEeY04QQgghhBBCqMeoxwghhBBCCCGE eowQQgghhBBCqMeoxwghhBBCCCGEeowQQgghhBBCqMeoxwghhBBCCCGEeowQQgghhBBCqMeoxwgh Vzt7Ws/9ZEsL04E8v7N9bcMZpgMhhBDqsSuQeNeFT8+uuWd54zC8tymJE7i30Qc6r9SUH4zTxrou fHdt059NqcgbW/rL7W1XTDpXnLy4v/38Jb+N0uMXkkMoxt79StlfTK3I+QyJ46p2373sEtfuOxfX /92cGvPfqu53yk5cZGuZFV97oyGvOLG87tSwKqJkmLQhI1ccRcl8u/MCk3c4sLCqG9nx3M72y/Hm Hc31YPP0W61Iq5X1pwOOOdB+/oHVx9AV5o0vu3Vu8kebWna3nRtYT3LU7g4cM6eyZ4gdNuqxq4Kf b2/LKykNBu7aoc7zeaNj/fH5Bo//3NOJe7si5wfuX3k0ryAWUPlzBq0VEi2vKH7bgtqiA139T2d4 zwFFaOzbx93HXDOh9GOvVj+5oWVL01nH2eZW9uCA6yaWH/ASV59fWIe/2k4nzvzi7o73Ty7Py4/h Jq99uQy9xaLqnkuSa5uPnUXC3jw3OQTXqul556Mzq699uXx7c2/OJ4F/NhxqNzpR3IZ8hic6Qg8W HL4MfcdL2Fri0u+dVI7yfyBwVGIoiygZPm3IX0+rRMncl42TSgaPifETyI4H3jx2Od683VwPAXe9 0YDLzfX3hcpOXHwfHAB4NfkxVc7HJPA5q24xiif53bVNOGac9mfcwJXCXyEdqceox3Kh5FDXFxbV GfLGqTr28VnV9pco6NRjl4QnNrRAeCypGWBdsarutGq2xpXFshnLCddjuim0S45BJKXjmJvm1MDh Vt8UJxzaaVZ5t/p+dOzrSxvc1/r07Br8aWntKeO734Gii+ML47fMTT68Rs/76f9OOHx8sPNocuIE FNHv9/YNqqEPQNp+9fX6ISghELp40gmxfj3mMNRj4MZZ1e+ZVF56/MKgZtblrsduX1iHJ7InUlbX n0YV+8HGoPZwKIvoFczOll4k/rdWDbw/PSAZ5C4b1GNu0KMhlZbVnroy9Jg7068SPTZqdwcOgFMh C2SQAuuOnBlwTzJYj6kMHZMYtaudeox6bAD43Pxaz0JPPXapSA6aE3/fyqMDmM4prVWcCDiD5zFT S0/mjUvklcTtpQhGj4EpiRPBeqzwgLqxj71anbB8d5xNxN7uQXY+Xtqnrv6jTS2DnWt+A95/O7Oq nycZnnpsyDLrstZj176sEq2mx9WMl8SDpxa5WHFgZrFGxz75Ws3wbPndZYN6zM0/L1OO/msV3VeG HvNsEK4GPQZ/Bgf0Zz9F//XYZdSuUo9dIXoMVX1Nw+kFVd0HO877lchltadwDPzviNeF6zCvsmdX 6zn3qeBPH9IXwnXXNpxxX9euRfgTji8/edExka1O0ulxtzgSfxI/PtZ1YWFV96ajGWvncOk5lT0b Gs/4NXC44vzKnoA9Szj/7IrudUfOOFLDvjQ+L6npWV53yrFhBo4yjqnsvmiWR+9JJ9H25l7cmN90 vJxwdf3pan3b6IDlDvFfnPC5ne1IMbQs+Cx9c43+3rHGqULfodlsMEh6DLxZr+frxpcZQZXSY+MS svjQ4Vk69NjIFaohLtjvbIh/vLkV3/9xf0gDjeRdXOOdxUiQven0QQ6ieNiST8rVr3a04SqP6MSU +5RE9qwdfuU8SmFwo6Ts6JjfbM+WY2dxHr/5JbkKUh6Z4tBj0W8Gx+BPAeXQb5X/XK+fODp4lExP LY1bQiOw1fXz4Nrhl1kBZXXtkTPw0lAwqjMLBqoSfp50VXPj5tqtJSoRGkOkUg7VP/iR9+r0yZug Bh1QouxbGn9YDbg8u8132YxfEX2r6Swaq5X1pyPu3MMVNx5VP9kaVgDQuuKKkgg7W3pRAPb6q4Lg NlN2aOBW0fAmMy+BVEIyJjLLfP8beXf6SwKi3UA6f3Rm9e50AxuxoErBRiLjZna09IZmULbtg1/Z sPVYcA8SpWuL8jh+iWCWW6NPX1TdIys1UHHsYhxa0aI3dzgV7g35ZZd56V6/tKQeaYIqg8/BxR49 BZIdd+tOk+hdM54RXcBbeol+RD0WcN2IDUIkL0s7SMgvdKwr6sOdNz895pnj0pgnXTskTXUOLTAB ekzOI77r5MQJU1OkOBn3KfQSfh7ODt1eSeIH6zHpZcwT5datU4+RqHpMuYCyxgwUxB2hINCLqPKq K6piTCI/bLgCDcTHZ1XLth/w/snlryd7HNf91OyagOvatUhqi6NGfX99s593MkE7Lk9saLlfD64I EABwxdBsqRtLf/nh6VUbM3txtI+ffK3G3Pmtc5N7Mls6OHPXTSw3Z7huYtm0spPmr6/otvhHm1qe fqsVT5Q6bFwZpIhfGyS96frGM381tdKcFsc49KeSW+aEY0tlAuq9k8ql0zI/TD+s+h4Pi88fmVHl XjT4L+kwD4Onx8wgpdnJJpdGacTV8eH+zKk8hx77t1Uq7x5Y7ezVkF8v7esM2EW2u/Xc7QvrcD+p 1CiJO0bXVIIXxZGPso5XFluitIjf9qJeIGEj9wDHDp8de52Dy3mUwuDmFr0J0N2/vrS3U+1pTt8V 5IejT3phV3teYV8JkVXvRo9FvJmfbWuVNfrCTXOSjgriUd1ix1GPzE+QIHYwQEcH7+7v4XCohanp /HrPpPI3kqccY/9+tcMvs/yErl1z3ze5fLpVc2WXgu35ScF+1ytljtYSUrkvnYsTJYe6ss3xgEfu K5NpjLsGEahay/Flfg/oLqJIt0/pamXqQmiYH9XOlMTNT9AYBhSA7+iWeezbx9HImJ+ggjuGyaK0 mQ+uPnbbglo5wGizT7xm3fyYxC+sm+9PI++X/tCKjsT/gDUdGqWgoi6gbcGHR9c1h2ZQtu2DX9mQ S6NJ/NC0oB4ktGtz70lzP05wIkhey4ibgAySBs0MC4ZWtCjNHUrIPcsb+5IiXy0MkWLz1dfrHak0 3md9O+7hXpyksK+045y27I/SNePz3cv67gRHqiY0UI+FXjdKpkf0slAZMzyHMYng1f5Ztc+qn9UF z7k9fnTs5fRi++ACE6DHfqPHl23ES5FdDPZFgy/h9nB2tvTa7dWXl9Tfq8uSnx5znCG3bp16jETS Y6pdKIqjTYGbqxxo3f7aC6/h4uCbr7xej3bt0XVNKmwDnOyDvuEi1FYH9OhjEiivKLtPbW5V5yyI zU4vHkhdF/WnOOG4rgnnYNcBfOnoGoHsJnqr6ayfHkM7df001Tj+ekf7R2dWi0p59ytlI6ZUPLO1 FfcmjSxkQEZ/qT2e53e2Q3OKN4DjzVD6JF0VcR7cGB5NNT1FKvVMfy91VXm048vQh8FfTMXYGF9m eiBPPYafIJt+t7tDpbBugnHbzrapJI7r/nF/p+qKdCssegz9ECSHTCh9fmEdPksPdMn12J/2q5Pj xhx67GDHeXnG2dZ6Eocek2kiFE73ysbgAfvrdXp++81jKAZIN3EE7c24qQQviI1c3og7xLNLkZbN OSgDKjF1A/2FRSoxZaef29kNLedRCoNnB+xeFDdOL0aFZ4li+asdbehyHGtTfyvKpKT0aV1C7k07 Kw49FnwzslgfP4HXjgeXdgNlLCC6FHwC1YCML0OvX3xQbVtVJXNCqRntDtZjuLTqGgtij69vRqFV vlSByvQtx85GqR1+meVGtSHoO8eWPrmhBfpBVRbcdmF8RXo9bUQ9JkUdpQvXwj2LU4WyGj2Rgx8Z 94YzyygVCic+286fuLZ+c1COIoq6IIUfzRREo9q2qhMfd+WXm4+tU4NcfzuzCiUBev7z2t9Cw1tx 8mKAHkOO48ZQAtFsflA3qnATzTFR28x8lW7w8B5e04RHVlutUCuL4g+taZoYP4G6KVMEpt/JuZEP SP/DnaohheoT7xafcfPZFdR85ZGrxsdr86enHovePviVjdSli+IBPUho1+apxxyPE5oI0APSMeEe 4JEjCyTXstVjoc2dTH8huf6wrwOPKbksG/PQIiFlbtSCHPeJz37zeDdopxynQsOFnkI6DvsqUbrm L+s7QbFHwqLWSA0N1mOh142S6VG9rHw1Nve9dc1ISdyS3NvM8pMR9Vhwjks2IVnsqVF1hpJSaTFC C0yAHlt7RLXtf6NH+n64qQWfZe+DQ4+FXsLh4ZSduIiShm9uW1ALzxOpZ2R/Vnos226deoxE02N6 gNN8+a1VqtL+eHPKf0X/Jz60OUAGEdFEejblyVPvSHG3Fd2Cqm5ps+QnUa7rqAMjdJ1Zm97KKffw sVervQfsdVcNwWZW5SXTDQ3aUzOzDH9FhjcOpVc7vF93FfYgkwy2/Sm9Ok6lZH7MHgiR0aCfbm3N qKslpej/zDEjtHQ0DaWnHrPH9eE8yfyhaXGkG7D3YonrLHpM+KMWPz+0dtEMmB4riP9oU4sD4/gG 6DHlrI+O/cO8WoceM3kEf9E0YQ49BpQTpsuJuFxbms6GFvVvLD3i6C/3yWKPwrjplSXBf2d5palQ KGMSZt2Le0uSw5eKUs6jFAYHUD6O6paa/yxUWsIUXdXt4aHyY7JGC9+r4p0fW9Nw2qHQRjj0WODN yKih/UTiOvhJ4spuPWNTFLeX8chstimHwXpMtgf83Jr3kCkvE6Y/tHZE3D/2Pa007Nkh0R5m4D+6 HrNTQ8QGlED0RA595IDtIqI8F/toTkcRlRGNf1xQ61gKCxfHb1mOys2xpfYCKmkS/aajRY997Y2G pDUg8m5dL0wjGbnNjNuJpiYZ8jNas2LdE92aDk6YcyMfmv6e+8ciFtRvB65S89Zj2bQPAfvHgutI aNfmqcccjxOaCJ+dV+sQ/FDdMt0aXY+FNncx3Ugir80Be9HI6/Fcs1w5dP+YWpWan5FEO1p6RdYa xyY0YWWkGE9kYmgl0wnrVxKiXDc007PwsoridpcqA7v2cEmwHgvOcdVilMRxJ8nMHt+sfAktMKH7 x+5YXO9ofxx6LPQSDg8HvoFMciatFbxS6cZmpceyrLbUYySXeB6TEydsf13aNYdDJiM6dnG0RzXw J9QZx/cy1Dpf30OU6zrqgBpps/4rSwJe8Il4I131Q2ua7C9F7zmEx2f0wIY0WNINO5wV8bdQe4N3 +5jKL3XV0RarcTVry5OnHrPHvA/rnT+mf5pZflImvtyO+xDpMS9GpTvdAD0GeWDLZluPmTHOR9Y2 +emxWh0i/6Y5SXstXPCqANWdjC9zDOfL/qKn08/ouf1d2lOzliNUj0Up51EKg4OVetOdYyWn3Ixj BdQj2hVG9uHzDF1C0HUFxPOIcjOS1PaCFqTS2oYz4svubj0H3WVAry/uiGNkd1tzLxR4RD2m/IzC uC0A4LepAc70qrzQ2uHOrMTxC/Z9isZG7suiOHvoF49mNsZEX6/oyDIZKpLNNlESOfSRA/TYU3rz pN+rLBxFdL72jZCA9nnwyOsbswhQJjrWz2v/jte+C2lpHwxcOBraZnqu8sJh705nR26NfJT099Rj ORTUiHosq/YhQI8F1JEcujbPxwlOBMkgiGHHOmpZRRldj4U2d+UnLyr1VRi3d7W91XQWZdtMJucW z0MGpMyim9CEVXPOLj8kh3gejuuGZnrOXpbaipY5XRmsx0KL/Tf1qhwzOCsNwry0bxP68/7rsdBL ODwceCP475uZbzwL3j/mqceyrbbUYyQXPSajLF9Jx+SVcTV0e6hpBtFjnrPeogp+5trW9VMtqF7S UQqiXNdRB7Y298rYT1+lyo/5LX/37KolDoQ06I7FBlK3Zfz1ozOr7SeVDt6eiENnU3Sw6+E1TWgX bpmblPn0byw9YtdVR1us1hlbEzKeeswhD9Qyg3SD8uKeDnvm8BLoseIEfHEHpkMNnR+7JT2k7dBj yD5ZhiHj/Z56zLj4z25rNYv4HZnYN4/UpNyOz86rdXyP/LWD7HsmOEoLvoRyi6jHopTzKIXBvRfL rJx0zCfcubjeLpn/qDfbPLlBHfk7PSLoeEGKpx4LvpkpiRNqZFq/ugClzlG/7C1AYMuxs1IyfxP4 5tMAPSbl85oJpfZzqR5d7z+Rwe/Q2uHOrHwdmdMgdRNl49qXy6UuP7O11d7h1k899hU9HC4eSWgi R3nkAD2GcmWPLAS7+7h/fJZZ6MfWNaPBiRKfDdr7uZ3t/7bqKAoYaq5k+h/2dUTXY1KG7fGjHNpM YU5lDwTh195ouHVuUlaCyc7YnBv5KOnv1mM5F9Qoeiyr9iF6fEW7jkTs2moDY+iHJgLqFD58xvV2 tWz1WGhzB9DNyZzqyOWNKAnudWIR9djGo2ef2tx697JG9BqqgOmpPMca1ICElbq/sKo7Wz0WfN3Q TM/ZyzLZ4fdy+Wzb57m6i38sLZ5ltXAy8s/7qceiXMLh4agHLIgls4mv6KnHsq221GOkv3pMDUT5 TI+AQq+oHo/rMBvugB+/39tXpnPQY0A2pq87ckbGeALeqplbV21Wx7l5T1r2wKuT1Ti4ebQU9y5v lBUag6rH5OejMqv6EOux3PaPyS3ds7zRU4+BAn3AX+gNKgF6LGMStSDmWHhjmF520r5cxpoZyw3y THDZ6vb99c0R9ViUcp5Dwy19ub0i3wzpeSJ7857yKts56DFZgaOirZSUpuN51JhpcCQRpJfhcOcF iakTsJU0WI/JxK8fsgYyBz2GJsK+TzNstLft3KPrmo2qRMrY0/456zEJPCMbjUITOcojB+gxkZpP bW6NGM8Dj/DL7W19m9fHlT27rTUZXL/0tvgbZ1V/9fV6OLuS/lnpsbf0sIh5YUNubSa6nlvSuzLg i8NzlfgN/dRjUdLfrcdyLqjDRI9F6dpC9VhoIszRrrl7wi1bPRba3BnZrxwbCahQFEfxsF+8GUWP pZKlOIGShuPVYmC9LyC6HpM+y7FQKFSPhV43NNNz9rKARB+xA+r4NddRir2snLxuokqQN5KnbM0c 5ef91GNRLmF7OGrh6+iYOyQS9Rj12OUxP6ZmMEri0a8lu1Z+4Yri9RO9XkhKfG567PfpsWH5U8DU cG5dtQpPNzr2XOBgv3QVky03ToWTGmQ9NvqAh2S6LPSYxFGEu+ynx0zhxG3begy9NTLxVa+lidLR OuaCzFos9/nNGJ7JFM8E/7nexG9yP1SPRSnnOTTc8pIAh08jfdKKzCUW7m74ma2t/ddjZkJjdkX3 t988psphSdxvQ/woXWWez3V+TB72C65VN8F+YageC2VV3Wn14Hpu1sQBy1mPfVH7BxLRKzSRozxy gB77pS6lBT5Nn2cIULNHBYVEllZ+d22TX4hzJcYmlNrRCGUiIis9poI6WM+YW5spK8FM1FMJ89t/ PRYl/d16LOeCOkz0WJSuLfRxQhNBhr1u6ff8WGhz54j2DmEmCv/6aZXR9Zis8b5pTtIOViRhTqLr sbuWNrh3VwbrsSjXDc30nL0s0+H6JW+27bORl2gARSWapQdRft5PPRblEs75Mb2ZnPNj1GOXpR6T OEV2nIBgZuu+9vaFzhoiW1PEsctNj6lfFcY/OLVSPU5h3PPNY/3pql/VauFLS+r9TisSaMSUCre8 GVQ9JvtAHDIjFkGPmX3Pl0SPpYJklMTNhntPPaYCqY1J5BWoVQdGj6XCNBUn3O9LgWuIw/5tlUc0 KhUQvCBjn3cq/XUvZaLeeya4bGabmA6nFqrHopTzHBruhN6D4XCppcMb5d/Wy804uqVs9djetnPo 5idn7hSVSQm/S4tvYQeikAVvKE7F6UmzAD2mtoOPVsEY/cL3DaAegxoBdjcswxymvkvI/nVHzgTr MUf1R0GVyR/ZwBCayFEeOUCPyYSkX3QNdzwPZKi96FQpjXz1AsCk/7aub6065i57WekxCTUkqi/n NlPm9Oybl+zopx6Lkv5uPZZzQR0meiy0a4vyOKGJoJpffVFHnH2HHgutaKHNHbQECra94g5aXWIw GkclVI/Jxkj7ZRVAXpMQXY9JeXMI3WA9FuW6oZmes5elIjDpFtjPfcq2fTab2fBcUNq2JI7y837q sSiXcHg4ssxqRb/3j1GPUY9dAj0mXv5n5iZtH3fMoS6UTs/dCPhSdpfZoWZkIdlfpXd/5abHwJ26 cqJB/GLgiEhuXTV6ERm6s/fF4VbhkkpcR1X582N2u3m484L4Dea2B0OPobORG1tgrVOXTitYj6nz 6IXUZvcqej4ZShxsPaZyXAsqe229px4zG+QE8+YQCd8Ph8/u3dGdSHvqNzsq28DsBV3boPfGqTcr bMuMr2jvekLrLH6qGbWd5Nqz6/ClopTz3BruvHFlyG77GxVNtEDFlLf3ryNPRy5vfDv9rur3TnLG wXtSzzCMiKzHVPEuTjh2yUv0qt/63C16QeUGFcbtEBESt9BMmgXH85AZVHu/XFKvxjHCOIoemxQh IIQEdbB7XIkc++W0kypNgb01XxLHHV/RFiciBc2cQJQcD31kEzDJHRxCvBO/fbOOIirXtW9GbbDU Bcnz51I9r5tYbhp2FVNbzyL6FVfRY3D0zU+QSuIZS0XOuc0UD9V+c6CsCzU3n1sjHyX9D3Wcxz2P yOyeciuog6HH3GUjtI6Edm0R5WVoInxdzxfZ8zZqDZteAWv0WGhFC23uTCDBpKXHUhGY05Mzj6Tf jBc8q2MvbpcXNtphnEMTVgY43v1KmckONImyadOvOYpy3dBMj+5l5RXF7XCssqLB3QXn3D4Lakeo 3gLneL1h6M/7H88j9BIOD0eG4T6/sM4M9arYBPqpx1KPUY8Ncz2Gwn2zdmU+qF90CDdLagjO6fdK crjg+lUY8YfXNP1+b6d6fVmBGsMwuyNy1mOpSKOB7Wx/umq1kKZAxTO4f+VRHJnabVIUN++NleYD tffB1ceUYJhQKuvXzbDQYOixWv0SEmlbceZntrbemn7JSagekwF1OFWPrmsC16dfGJqdHstXC/fd yBp0xzG3L6xLbdEpjDtiIfrpMZQx6cNsPba//XwqsmJx4guL6n66tVUVPL2v6aY5NY4QXvbkzHUT y2Q7+Iu7O360qUUCwc+wHJG/TifCXUsbkClKt+g3INvr7tS4vo65jPR8Rbfs7sVgoeU8t4ZbMtcR a0t+hftBxwP5qspeSRzpbN4BMM6UkNXpEqJL5ohs1iuKrwDHCHUHPffXUFB1OdzZ0hu040ivacRv 8RO15ydfxfQzbw4I1mMqULX+BqUCP396S4ssb/tJYDBMR+1wZ5b35E+hel2PZLoKZqCVhqna07Q3 g0TDAbi6qWJOPQbnsiCOAonGUFwB/Nc0IFESOfSRTUb8w7xaXMUEalcL9lD+J5RGdPfhZ1yjo4Tj PM/tbH9iQ4u8s9ERLcYOYCiq/kPTKnFw6hWruhT5LXFMvX9MRwCHK4a7lfhP9nhZbm2mtEu4ARRC tMPqtWbp996KU55zIx8l/UUNwqUeFTnXhkyPuctGlDoS2rVF0WOhiaCklFZfqBpoptAwmneLGz0W WtFCmzuoERmV+/D0KpwB6SBr3T/xWk0ys69B64eOwzN2hVrqpl8e+Jm5SVxFdUD5MSmZWQ0GPajf zgpJhn4E51FBp/RJ/PRYlOtGyfSIXpYsUcFNItPlbRm4uufu69zaZ+H59Lubd7VmV2D6r8dCL+Hw cKrTUlYCO6l3sqVbJOox6rHhrsfE4Vbrksemtvhf+3I5mgA/h9hMYd9o3hw/thRnswOM5qzH1IoI tO/FCT8p2E89JqvsJHijtFz4bP811nVhZPpNuzjmtgW1qVV5RakVyYOkx8B4PJS8XUe/8EQWF71/ cogeSxy/IPt3BTyOvEGl//HuTXwn5zHFCeQsOgD3Glc/PZYaaNQvkDF6TJpONK9q7K0gffJx6vWX Aa8nltKllvVrtwA5CIXg8NElwdH5jUi/CBJurnt5jNpRphNc0spzc05wOc+t4ZZhTnfsLJTqvgiH JXHo3t2ZZUbFtUuXEHjeS2p6ID9GZLl/DF27DKULSD2U8ODmBRXkQ2mJi5REebMzKFiPybYlVSOK Un7bB6ZWwAPLar2iO7Nqfd78o16nVpC60IgpFY6CoXZnpW8D3qGqYmMSDj2G0ouSc036LbfIkXlW uxoxkYMfWbbi3Jz2U43kVhnqGoEO3j+GEqIC0+nhBimicE8DoiziDOLpSpv26LomGbx3xyy19RjE nsy6S4375oqj9vKh3NpMoN7LnL5z6DE8/gd0hZVQlv1p5EPTH1kvb4m1RUIOBXUw9Ji7bESsI8Fd W8Tll6FJhwawrzUYk/j1jnbJNTvAenBFi9Lcwf1QYi/d3KFS37fyqH0JlED1LkqtfPwWU0AZ9l1i XOJP+7WqsdreKAmbFLEkBVW/GF265oDp+tDrRsn06F6WmsMf29deLagKe2FMNu1zX6jkfO8Qa8E/ 778eC72E28M53HlBbfotSLVyaEOe1e9Poh6jHruc2NnSu6v1XPTjoZrQjkQJshyRgx3n0fKawOWD B+58feMZv0XJKrbvkTOX5F3sW5t7pXsQr/0W/yCTjpFv3HDiUr88PmfKT6pgymbKJQoodZuOnvXU 7XYvi3NCCvpFnEOvDxeqPHD1/GCU8+unVdoL8R1qE8+VDCwhfu+WiQ56rGwLDDTYxsAbi5Jf5nWu ORAxs1Cp8Wh+SVTVrZzm/RESUN760J9EDn3kHS299rI0tZevpDR4MMITZAouhNY7GbmZRetXHaE8 2/vHpM30G6fLrc1EdqBQ9b8855b+G73+2v+COiA4ysZAdW0DlXQoQlvS7apj/1hWFS20uUMdxAEB yyXQHga3zEhJv3hF0UFlweNkVbxzuK5npvv1Po5R7+3Nvf1pr/pZ7Ieg1mR7CaTbhmit3GUE9RgZ OmRryozyk1fbg6+qOz0pcyxfDf6Njj2+vpmlIluijGRfWmTxoYlLSQhcjbx850sILznfCdwHT4if HiODjV98RXIFQz1GhmJ6ZEFVt5oRzg/ainoFI4FMHlx9bEriRNHBLrU6SK+aYCd3Reqx1AaJonjo WkFyNVB24uInX6u5bmLZoY7hVd+pxwj1GPUYoR6jHrtakADEsil8e7+XFlymilRFuivo26b1kRlV K+vprF+ZeqxWhzN576RyR6BwcnWigneXxN8cfvWdeoxQj1GPEeox6rGrhcTxCy/sap9ZfvIKW+yb gypbVN0zKX5iQ+OZmh4WjBxZUtPzWkV3cECa4cDBjvOer70mVxu/291hv6N5+ICGCFVp7/Ae2iBs b69CqrpVUE072D2hHqMeI4QQQgghhBDqMUIIIYQQQgihHqMeI4QQQgghhBDqMUIIIYQQQgihHqMe I4QQQgghhBDqMUIIIYQQQgihHqMeI4QQQgghhBDqMUIIIYQQQgihHqMeI4QQQgghhFCPUY8RQggh hBBCCPUYIYQQQgghhFCPUY8RQgghhBBCCPUYIYQQQgghhFCPUY8RQgghhBBCCPUYIYQQQgghhFCP UY8NESNXHP307Jq3Oy9cqhuo6XlnT+u5ZIQjD7SfP9R5nllGCCGEEEII9dgVwl9Pq8wbHdvXdm5Q rzKvsievpPTLS+rtL2eWn7xxVnVeYRw3kFcSv2VucvSBTvdv97ef/+7apryxpeowMC7xvXXNDmFW 1f0Ozo9j5lb2uM/ws22t+OuoXe3MbkIIIYQQQj1GPXbJuH1h3UdnVieHXI+9VtGNq3x2Xq355vmd 7aKv/mZ61XfWNn0cwkz/9/vrm+3bKz958WOvqj+965Wyr73R8KUl9ddMUMLspjk1ld0XM/SY/vl7 J5WXnbjouPpTm1vxp19ub2MBIIQQQggh1GPUY5eMa18ugzKp6bnEeuytprN5+bG8saUbj541x+xp PXejVmVj3z5uvrxraQO+eXD1ser0PUOGfXPFUXx538qjbj0GHlvXTD1GCCGEEEKox6jHhhF7287t bjuXpyeXdrWqz0mXHtve3Dunsgf/+p3kYMf5+ZU9+9uz3sTl0GOFBzrx35HLGx2HzdaH/cuy1Pev xE/gvxBpfssscdoMPZav1j3i39eTPdH1GNIBqYFHkwecW9kT68rYTbfl2NklNT2lx7232CE1FlZ1 L67pkTPYM3s4rfzqUKdKt83HzgYk0er608vrTuFXju9xMziPTAbiPLi9dUfOVPdkcScDkoOEEEII IYR6jHosd/LGlZkZJEGcchE2i6p7PqQ/CHe90eAQBjjgk6/VKMGjD7h1bnJPaxZTag49NuZQF/6L KzrCeMS7Lry0r3NCLDU/9vj6Zhw2MX7CfcJ8reie3daaoceK4n/cr77/4NTKCuv+g/UYRA7+esOM qqe3tMjTTUmkrvjS3s6/mFphkuWRtU32Iknc7T3LG/uSNF9N2cXTWk7EJC4NeWmOed/k8jUNp+2r 484fXH0sb3w6dwrUVeyb/87aJnw/OXHiS0vqzXn+ZnrVW01nI97JgOQgIYQQQgihHqMey52xbx8f DQ2jo2L8aX8nPoviEj0GJfO5+bW/293x6LomUW6/3tEX/WJD4xn1w/Flz+9shxD6BNz60bERUyo8 Z2mi6DE1UzcmgW9+sqXFVjgObp6blNk895/WNpzBn77yer1Dj+HzrfpXEEJZ6TElVApin5pd8/Ca pjfrlWQa9/ZxfP/h6VV45F/taHvPpHLHIkkRSLjcH/Z1ILn+aqpKya+mb0n0GE4LRffM1lbozNsW 1ErkEnt6aqRee4mTFB7oRL783RyVtp+Zm3ToMSQXzv/Tra0/29b6QX2h2xfWRbyTAclBQgghhBBC PUY9Nlj7xx5Yfcx8U6Inr6BMzDfvn6ykiL0IEL6+6Lrc9BiYCLlSrCTZNRNKH13X7FhhmJrTg4Qo jHuGwo91XZDoHW49trW5V525ICayKqoeGx3Dg9trFFXgx7GlJjoIEk2t9syPbdJ73uQGoHDMAXsh MotUrMjD+uUBosdGTK0wqwfxIHcsVun2g40t8g3kE/77xUV1JkfwIBDG9s2IHrthRpW50O7Wc6L0 cHCUOxmQHCSEEEIIIdRj1GODpcf2WvE84MRLPEP572YoE71Azj7PJC027nqjIWc9Vqujenx9aYMo B3DdxPIXd3cY9VV6/IJEt/ddgYm/FsbdegyM2t0hGkbmf6LoMQgn+8uX9ql1j49mhgZ5REuj/9zT KdvD1J0Xxne09NpPtLbhjEw8ih574M1j9hlE635waqX89ytaFK2qy1jBuLzulA4gmbT12Dgrxgn4 8PQqfLlFL1kMvZMByUFCCCGEEEI9Rj02WHrMEV9RLd4bn9JjxQeVhPjozGoIA8O3Vh3Dlx97tbo/ eszIvz/s67hFLzIEdy9rFBGl5qOKE37zY2UnLmoJV+apx/CTT+oleb/QGiyKHvuLTD12/0q1jPDO xfX2U/+jXnD45IbU7NYPN7XI+sORyxsnHD7uCPjhqcf2t5+XxYfyX4hec88G3Dye+poJpQF67DM6 udYeORPlTgYkBwkhhBBCCPUY9dgl0GM/2NjiCARieE96uWB/9Jhhdf1p2aP1i7RwEk3lGXZi3RG1 f+yORXWeeiy1Y6owjm82Hj2bgx6Tl555MnJF3xayCbHjanlhQVyufs/yxlhmPA+HHgPvfkVlAfRk WlJ6pKGEwZRsiqLHgu9kQHKQEEIIIYRQj1GPXQI99sIu9eLm53a2R7wETrW1udfxUuYZ5SdxktsW pPTYtLKTEw4fr3DFdpdVgiaahQouMjo2tfSk+yoSbOPpLS1+egz8fHubbIT7cfZ6TDZ6rag/HeWR D3degByC2sRPrp9WGazH1NrCktR95o1L5BU7F2RW97wjUUCiz48F30m2OUgIIYQQQqjHqMeGix57 tVxNbX1pSX3ES8hKv6ffanXvvHpoTZP8906tdhZVO2N4bNE7nf5sSkqKjNWiy+yksvm4fnM0dF2A HoOwuWFGlSxrzFaPyZzSqN0dfo8Jqfbb3R3L607Zl5P5PYlo76nH8CdbKUEr4r/2ScD8yh58eU/6 5Wyheiz0TrLNQUIIIYQQQj1GPTYoXO+K3hGqx8pPXnyfjs43s/ykrWEgGNzzM+BFHUsD8kai/4HE 8Qvyfq2ig6mYgfI+6BtnVTveXPzkhhb7fdDQFRJs8EebWpLW9ipZfwhRZ7701GPgzfrTeQWptXm/ yEaPqfWQBXHcth0kA2cbubzxbR20cEFVt0TmSFoqaIR+WdnahjNGj71/crlJW8jgL+vA9OZOJsSO S5x6M1VYduLip7VIMy9hC9VjoXcSJQdxbwmfF14TQgghhBDqMeqxgUGmff5hXu3PtrUe6jgfRY+l dn9BnOTH7l959D/3dD66rvm6ieUQP9PLPFYSQlrIC7LyxiUeWH1MTZfpV419anaNLZ9kxgzn/MRr NU9vaRm54qhsrHJIoFjXBXmbFpTkQ2uagEjKD0+vsqNW+Omx2rR4y1aPgaff0j8cW4pEe3FPh3pR WEkcDy5RDSFgZHYLd/KTLS1IT9FReJyktV5R3gH9w00to3Z3iIi69uVy+03Nty+sw5cfmVH1qx1t v9zeJoETcbw5IFSPhd5JlBxU1y2Kb2g8wzpCCCGEEEI9Rj02WGw8evbmdCRD0RVR9BhYVXdahbjI j0mUeXx2rzY07G47d8/yxlRsCS2ToL5iXc7pl7FvH1evP9ZqTU4LzfOWviubXa3n7l5mna1QBavY nRnkI0CPGX2YrR5T81eHjyvdItctiUM77bYSqrL74sNrmmTqT1EQv2/l0QPpdz2LHhu5vFEJqsLU zUM4OV5vDTWlhN+4VCLcMKPq2W0ZSz2j7B8LvpMoOQhBiIzYePQs6wghhBBCCPUY9djgsqOld2/b uRx+WHbi4vrGM+44HJ5U96j9YNBXycDDIEggA6BSgg+D5Nh09OzmY2fxYYiTC4INlw64PYhDHOC4 MXv/WLV+RrcidWSKQ0HlgOedRMnBpF7WyKpBCCGEEEI9Rj1GrgT84isSQgghhBBCPUYI9RghhBBC CKEeox4j1GOEEEIIIYRQjxEyUOxrO/daRfd6RiwkhBBCCCHUY4QQQgghhBBCPUY9RgghhBBCCCHU Y4QQQgghhBBCPUY9RgghhBBCCCHUY4QQQgghhBBCPUY9RgghhBBCCCHUY4QQQgghhBBCPUY9Rggh hBBCCCHUY4QQQgghhBBCPUY9RgghhBBCCCHUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQQgghhBBC PUYIIYQQQggh1GPUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQ QgghhBBCPUYIIYQQQggh1GPUY4QQQgghhBBCPUYIIYQQQggh1GPUY4QQQgghhBDqMeoxQgghhBBC CLna9BiNRqPRaDQajUaj0ajHaDQajUaj0Wg0Go16jEaj0Wg0Go1Go9Fo1GM0Go1Go9FoNBqNRj1G o9FoNBqNRqPRaDTqMRqNRqPRaDQajUajHqPRaDQajUaj0Wg06jEajUaj0Wg0Go1Go1GP0Wg0Go1G o9FoNBr1GI1Go9FoNBqNRqPRqMdoNBqNRqPRaDQajXqMRqPRaDQajUaj0WjUYzQajUaj0Wg0Go1G PUaj0Wg0Go1Go9FoNOoxGo1Go9FoNBqNRqMeo9FoNBqNRqPRaDQa9RiNRqPRaDQajUajUY/RaDQa jUaj0Wg0GvUYjUaj0Wg0Go1Go9Gox2g0Go1Go9FoNBqNeoxGo9FoNBqNRqPRaNRjNBqNRqPRaDQa jUY9RqPRaDQajUaj0Wg06jEajUaj0Wg0Go1Gox6j0Wg0Go1Go9FoNBr1GI1Go9FoNBqNRqNRj9Fo NBqNRqPRaDQazd/+f5BRSXapLR8wAAAAAElFTkSuQmCC --_002_BYAPR19MB2248C54302A11BB5967F529994650BYAPR19MB2248namp_-- From nobody Tue Jun 5 23:24:34 2018 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 4FA7B130EB3 for ; Tue, 5 Jun 2018 23:24:31 -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=yitter.info header.b=k4WHIX/Y; dkim=pass (1024-bit key) header.d=yitter.info header.b=E+JWFudf 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 Y1mMhErIrCli for ; Tue, 5 Jun 2018 23:24:28 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02E1130EAC for ; Tue, 5 Jun 2018 23:24:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id CBB32BDEF9 for ; Wed, 6 Jun 2018 06:23:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528266235; bh=3kjn+73e1JQR3sySOhAwJyL9Wi6315TB1W6+sTHcm4E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=k4WHIX/Y8hAKqO0PzW0HwxLMe9fxMKZ7rV5GTDMlRGqBG2xnY1fv8sn/XfqrLH2Sf m88DZKOOn7ImH8S1jo/luyxxNYb0pmGIl/SLeOOc0pl/XYNRyAbLPDOzKYZb2qbLuA 6hYVFkjhXggCXXVFrYfN7hfUgRIqXG4aFFJSi2Kk= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS6Xf394_B3w for ; Wed, 6 Jun 2018 06:23:54 +0000 (UTC) Date: Wed, 6 Jun 2018 02:23:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528266234; bh=3kjn+73e1JQR3sySOhAwJyL9Wi6315TB1W6+sTHcm4E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=E+JWFudfg8u7HrR+2NcEuOC64MZID6qz23c/T0W1qQ2hcLF/DsPvw4azwy1o8+/2h KqrQRMpCg7YcHZ+fc5iXdbdbAVbBhc+1GwAUPaty3KGvk6P0+sk0zytS2pX2xfyKpk y2A2hNEYV+dRK+xYHa7Zt7TzRysYOLxTpdiS43n4= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180606062352.GD3011@mx4.yitter.info> References: <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> <1FA8A1B3-82F9-4D1E-A555-C82A8E745B53@dotat.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 06:24:31 -0000 Dear colleagues, I gather our colleague Star Brilliant has given up on this thread, but I think there is still an issue here. On Wed, Jun 06, 2018 at 04:37:21AM +0000, Star Brilliant wrote: > RFC 2181 defines what a DNS server and a DNS client should do, *not a DoH server or client*. I think what Tony has been saying, and certainly what I have attempted to say, is that this sort of dismissal of ordinary DNS assumptions is just not helpful, because some portion of the audience of this document will be people coming at HTTP(S) from a DNS background. They're going to import DNS assumptions, and if we haven't dealt with them in the document we'll get less-interoperable implementations. The document as near as I can tell does a lot of work to align nicely with HTTP "normal stuff". But I think it ought to be a serious problem that people with fairly deep expertise in DNS implementation and deployment keep asking pointed questions. I don't think anyone asking these questions is attempting to slow progress or prevent deployment (people may say what they will of me, but neither Bert nor Sara nor Tony are, in my books, part of the "get off my lawn" crowd). It's just that there are well-understood sharp corners in the DNS, and people who are looking at the current I-D from the point of view of general purpose resolution are trying to figure out, "How does that $familiar_thing work?" and coming up with no answer. The WG can perfectly reasonably conclude, "Yep, that part of DNS resolution already sucks, and you DNS people ought to burn in hell." But that needs to go in the document, not be something that people have to infer. There's already _way too much_ inference in how name resolution on the Internet works, and I would like us to make that better rather than worse. So, I'd like to understand what the document ought to say about some things. In particular, > A DoH server *never* touches the TC bit, it's the buggy upstream DNS server that sets the TC bit on a TCP connection. (It's their fault, not DoH's.) > A DoH client *never* reads the TC bit, it just verbatim passes the response to the downstream DNS client. It's the downstream's responsibility to either drop or consume the response. This is just a completely useless response, unless that is literally placed into the document. Because what it means to me is that any TC-bit-containing DOH message is almost certainly garbage that needs to be resolved via a different path, and it's therefore pretty hard for me to see why this isn't just an error condition. If someone (or the document or ideally both) wants to explain why I'm wrong, that would also be helpful. But at the moment, I think I agree with Tony. If there's a TC in a DOH message received by a DNS API client, that client needs to be able to decide what to do. _I_ think it's an indication that DOH resolution has failed and the client needs to do something else, but I can see arguments about two-sided systems (effectively "full service DNS API servers") that might want to pass on anyway. > P.S. I'm not going to talk about this issue any more since I don't think the current specification is inappropriate. Also practice shows it is working.. I am pleased to observe that someone has surveyed the population of all possible DOH resolution systems, and concluded that the current text will ensure they'll all work. I am sceptical of the result, however, and would like another report from the possible worlds. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jun 6 02:32:21 2018 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 2E849130EE4 for ; Wed, 6 Jun 2018 02:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 ufzOe8XPpLUw for ; Wed, 6 Jun 2018 02:32:18 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05D3130EDB for ; Wed, 6 Jun 2018 02:32:17 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 491799FB55 for ; Wed, 6 Jun 2018 09:32:14 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 7C360AC34A8; Wed, 6 Jun 2018 11:32:12 +0200 (CEST) Date: Wed, 6 Jun 2018 11:32:12 +0200 From: bert hubert To: doh@ietf.org Message-ID: <20180606093212.GA23880@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:32:19 -0000 Dear WG, Briefly, the idea behind the 'DNS Camel' is that DNS is already very complicated and that every new draft/RFC that touches it makes it even more complex. A summary of these thoughts can be found on https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/ and was presented at IETF 101. A key insight is that every new feature is guaranteed to interact with many existing features. This leads to an eventual combinatoric explosion because "everything has to think about everything". This is often unintentional and only apparent after a draft has turned into an RFC. Notably BGP and C++ have recently reached similar conclusions in https://mailarchive.ietf.org/arch/msg/idr/z0L79p9WJkv3F6GgJ8J5LtiCpIQ and http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf Version -05 of the DOH draft introduced this small sentence: Also note that while [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", that was later updated by [RFC6891], and this protocol allows DNS on-the-wire format payloads of any size. This is of course a laudable '640KB ought to be enough for everyone'-effort based on our current 64KB limit imposed by TCP envelope size. However, with this single sentence, almost every DNS parser in existence has become obsolete or at least untested! No DNS message larger than 64KB has ever been possible. The offset pointers within a message are 14 bits long. The EDNS payload receive size is 16 bits long. The TCP envelope size is 16 bit. People can be forgiven therefore for assuming 65536 bytes is the absolute limit. Implementors of DOH will now have to find "32 bit safe" DNS message parsers/generators, which may be in short supply. Implementors of DOH proxies will have to standardise alternate means of talking to TCP nameservers so they can retrieve DNS messages larger than 64KB. In effect this means you can't write DOH proxies that sit in front of 'bare' TCP/IP nameservers. Where previously 64KB was the absolute limit, and there was therefore little need to discuss the semantics of the TC bit on a response sent over TCP, this has now become a real possibility if authoritative servers ever start offering DOH. Incidentally, all of a sudden we now have a big thread on the meaning of TC within DOH. So, the DNS Camel has a suggestion. Specify that DNS messages carried over DOH can be up to 65536 bytes large and note that truncation should be handled as if the response was carried over TCP/53. Effectively this means that a TC response over DOH is almost always useless, but this is no loss of functionality since it did not work over TCP/IP either. We've not made anything worse here. And in general this is what I hope that DOH will restrict itself to: provide access to the DNS protocol over HTTPS and not change DNS itself. Because based on the lack of clamor for >64KB DNS responses, I can not see consensus being reached for extending the core DNS protocol for a new transport protocol. Or to put it more strongly, I will not be part of that consensus, and I suspect, neither will many implementors who have better things to do already, like for example spending time on implementing quality DOH servers. Bert From nobody Wed Jun 6 02:50:22 2018 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 5467A130ED0 for ; Wed, 6 Jun 2018 02:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 EucYxYXW6Jxb for ; Wed, 6 Jun 2018 02:50:17 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB9A130EDB for ; Wed, 6 Jun 2018 02:50:17 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by linode64.ducksong.com (Postfix) with ESMTPSA id B109D3A055 for ; Wed, 6 Jun 2018 05:50:15 -0400 (EDT) Received: by mail-oi0-f44.google.com with SMTP id t22-v6so4842669oih.6 for ; Wed, 06 Jun 2018 02:50:15 -0700 (PDT) X-Gm-Message-State: APt69E1ldTxW5KfVY/U7wQW9R9MaAF28x4vpKf4a+VjWkyQAGMWOKp+S Ix4JRrNAMCNl9fBPP+UMwjlvVgYf+719fJUxTJQ= X-Google-Smtp-Source: ADUXVKKkYQ5r7cJpD5RsaYsYf8DWA62le0eJm4OIvKKPXa/0UmXTYKZDbm4dqW6zEzr1PNQFZY6jxnCRsBFxPiDUe3E= X-Received: by 2002:aca:acb:: with SMTP id k72-v6mr1174566oiy.132.1528278615406; Wed, 06 Jun 2018 02:50:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 02:50:13 -0700 (PDT) In-Reply-To: <20180606062352.GD3011@mx4.yitter.info> References: <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> <1FA8A1B3-82F9-4D1E-A555-C82A8E745B53@dotat.at> <20180606062352.GD3011@mx4.yitter.info> From: Patrick McManus Date: Wed, 6 Jun 2018 11:50:13 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000fd3d7b056df617ac" Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:50:20 -0000 --000000000000fd3d7b056df617ac Content-Type: text/plain; charset="UTF-8" On Wed, Jun 6, 2018 at 8:23 AM, Andrew Sullivan wrote: > > > TC-bit-containing DOH message is almost certainly garbage that needs > to be resolved via a different path, and it's therefore pretty hard > for me to see why this isn't just an error condition. It is my understanding that the TC bearing response is the best one that the DOH Server could generate. The assumption is that this is better than returning no response at all (i.e. just an error) because the client might be able to make use of it. If it has no value, then it should be an error (which probably means must not send and if received must be treated as error). But my understanding is it may have value to some clients. Set me straight as necessary. It is what it is - if you need more information and have another path available then try and resolve it that way assuming it meets whatever security requirements you have - but beware that some clients won't have another path.. for example javascript clients have only access to http, and the servers they may connect to are constrained via same origin policy. In practice DoH isn't constrained by size - so shifting to another transport with the same recursive isn't likely to improve things; I would think using a different recursive would be more likely to bear fruit. There's obviously no way to say that definitely. --000000000000fd3d7b056df617ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 6, 2018 at 8:23 AM, Andrew Sullivan <<= a href=3D"mailto:ajs@anvilwalrusden.com" target=3D"_blank">ajs@anvilwalrusd= en.com> wrote:


TC-bit-containing DOH message is almost certainly garbage that needs
to be resolved via a different path, and it's therefore pretty hard
for me to see why this isn't just an error condition.
=
It is my understanding that the TC bearing response is the b= est one that the DOH Server could generate. The assumption is that this is = better than returning no response at all (i.e. just an error) because the c= lient might be able to make use of it. If it has no value, then it should b= e an error (which probably means must not send and if received must be trea= ted as error). But my understanding is it may have value to some clients. S= et me straight as necessary.

It is what it is = - if you need more information and have another path available then try and= resolve it that way assuming it meets whatever security requirements you h= ave - but beware that some clients won't have another path.. for exampl= e javascript clients have only access to http, and the servers they may con= nect to are constrained via same origin policy.
=C2=A0
<= div>In practice DoH isn't constrained by size - so shifting to another = transport with the same recursive isn't likely to improve things; I wou= ld think using a different recursive would be more likely to bear fruit. Th= ere's obviously no way to say that definitely.


=

--000000000000fd3d7b056df617ac-- From nobody Wed Jun 6 04:58:07 2018 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 363A3130EEA for ; Wed, 6 Jun 2018 04:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 ZnS3pUkU-adt for ; Wed, 6 Jun 2018 04:57:59 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 AFEC0130E39 for ; Wed, 6 Jun 2018 04:57:58 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id y72-v6so8671628lfd.2 for ; Wed, 06 Jun 2018 04:57:58 -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=MHe8zdDBP2SOpT5ppQRj0WJFsmzn62oqyFyksb72k6M=; b=KeadDgB7bGDaZGUnyOf2ms8AixpbChevxri4we7mNkBykyC3qzGJ3Gb3Ab5tnMn4FK XWy9d0470VFRWTw8wTLU1+FydMgj7s37av4YNnv/jNCZUZyigw8vitAhZPhCiZr9yN87 QEya0NlH9u5UWU+oGR8EGBfWcSsSf0q24uUiLaciEZjfyRjYA9Lan5UxH2dbJxG8yACB VGkHpKtNgDgXvLkdnKyABP9mOrK5Q4faE1F/8l7/I91vNxj5AYqa1eQedAGdi7gWy9Nx LqPeU4deD4VX9mDkgNoGyg1ie2DDQGannX2xjx6GCq8VfnuNk3h2dIx5J9fzmaKu9kjF Mmgg== 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=MHe8zdDBP2SOpT5ppQRj0WJFsmzn62oqyFyksb72k6M=; b=j6NMOPD3Ao6+ajV81KmTCxIjpOGEqEKX6rdJfq1Wp6exsH5DZsezb7Ewo5AJ6Cb1JZ LDgZwC3kdUZoWrhnoRhjKSXF2gVdIdU1AL/uAaEWQNJP6wO0Ab7QnBgyCu1mp6QAevWp B6k0DQoRo5JTZUZJk78uTDdEAMAjE4V4NXRulP3Vz3RtmYGmMBjtAN+FgA+5vkMJIB/X kV1q7PwR0RRccuVQd8sEdg+FiT6AFON075WfLuqt6EHHEquy1I0zENP35SYrR8HIuoZf Rh/plENfFQhMp1gUe91pfvKrQ3WKfBH/dNOdXdfFTFI8OMfg0hINKLkALvtvB+SaB6rm HWkQ== X-Gm-Message-State: APt69E3w5SPlaTNNLwbPLlUUNeRWTh3fOLrPFqdwpJsgBqOY0k3nNSvu PTfFmjAIUbSaeQ7pZ//U4gqw1/7eYAaRPnLOg1o= X-Google-Smtp-Source: ADUXVKL84Ri/aUpzjsK/s7XP8FT4P+RAlQOxPtrc+jL/OaWEKZGAVN+DMUtrWkL2ZATQhutds5TsTIJkaPISeFlnDb8= X-Received: by 2002:a2e:7a0f:: with SMTP id v15-v6mr2001294ljc.68.1528286276883; Wed, 06 Jun 2018 04:57:56 -0700 (PDT) MIME-Version: 1.0 References: <8CB4E291-95D8-4AC2-9CBA-84D54A6E93DA@icann.org> <1FA8A1B3-82F9-4D1E-A555-C82A8E745B53@dotat.at> <20180606062352.GD3011@mx4.yitter.info> In-Reply-To: From: Massimiliano Fantuzzi Date: Wed, 6 Jun 2018 13:57:43 +0200 Message-ID: To: Patrick McManus Cc: Andrew Sullivan , doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000a61981056df7e021" Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 11:58:04 -0000 --000000000000a61981056df7e021 Content-Type: text/plain; charset="UTF-8" Dear memebers of the WG and/or DoH list Similar questions arose in 1995 and 1996 IETF meetings, https://tools.ietf.org/html/rfc2181#section-9 TC can have multiple origins. I guess we: - cannot fix what is broken (configurations) - cannot establish a new concept of "best effort" answer, not better than the one clarified in the 2181 section 9 - can live with broken answers, broken servers... We shall though, agree on mechanisms to: - clear, ignore or warn about TC bit and implications.. Let's reason on how to switch protocol, and why TC was set. - clarify the need to process (proxy) the ADDITIONAL section ? (the TC bit could be set as effect of that section being too big, not the RR queried for) - make clearer who has to go and try TCP query, as we need to support both. Is it the DoH client or DoH server ? how is this preference expressed from a client perspective (do we still have two content types, i forgot) ? - can we say that TC + minimal + TCP is a FAIL ? (or create an universal URI) ? I want to mention also "minimal-responses" option in BIND. Overhead/overkill from a DoH point of view (certificates, sessions, perceived speed), but that might be a benefit for a DNS server... nowhere in RFC is written than a client needs more than what it queried for (recursion) !! http://www.zytrax.com/books/dns/ch7/queries.html#minimal-responses Another important nuance we should agree on... HTTP is stateless, are we discussing about building a stateful API server ? One that works with "states" before giving out answer? A server able to judge the quality of a given set????? because i do not see how a single API call can drive multiple "interpretation" of the same message (received upstream). Otherwise as usual, the intelligence must reside on client (aka retry, fallback or fail). DNS clients do already "suffer" from the same issues, as also mentioned, many firewalls in between... I think the "retry intelligence" should reside on client, as a DoH server is by definition a proxy (eventually offering options to minimise/alter/complete responses if you want). On Wed, Jun 6, 2018, 11:50 Patrick McManus wrote: > > > On Wed, Jun 6, 2018 at 8:23 AM, Andrew Sullivan > wrote: > >> >> >> TC-bit-containing DOH message is almost certainly garbage that needs >> to be resolved via a different path, and it's therefore pretty hard >> for me to see why this isn't just an error condition. > > > It is my understanding that the TC bearing response is the best one that > the DOH Server could generate. The assumption is that this is better than > returning no response at all (i.e. just an error) because the client might > be able to make use of it. If it has no value, then it should be an error > (which probably means must not send and if received must be treated as > error). But my understanding is it may have value to some clients. Set me > straight as necessary. > > It is what it is - if you need more information and have another path > available then try and resolve it that way assuming it meets whatever > security requirements you have - but beware that some clients won't have > another path.. for example javascript clients have only access to http, and > the servers they may connect to are constrained via same origin policy. > > In practice DoH isn't constrained by size - so shifting to another > transport with the same recursive isn't likely to improve things; I would > think using a different recursive would be more likely to bear fruit. > There's obviously no way to say that definitely. > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000a61981056df7e021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear memebers of the WG and/or DoH list
=
Similar questions arose in 1995 and 1996 IETF m= eetings,=C2=A0htt= ps://tools.ietf.org/html/rfc2181#section-9

<= /div>
TC can have multiple origins.

I guess we:

<= div dir=3D"auto">- cannot fix what is broken (configurations)
- cannot establish a new concept of "best effort" answe= r, not better than the one clarified in the 2181 section 9
- can live with broken answers, broken servers...

We shall though, agree on mechanisms to:
- clear, ignore or warn about TC bit and implications= .. Let's reason on how to switch protocol, and why TC was set.
- clarify the need to process (proxy) the ADDITIONAL section= ? (the TC bit could be set as effect of that section being too big, not th= e RR queried for)=C2=A0
- make clearer who has to go= and try TCP query, as we need to support both. Is it the DoH client or DoH= server ? how is this preference expressed from a client perspective (do we= still have two content types, i forgot) ?
- can we = say that TC + minimal + TCP is a FAIL ? (or create an universal URI) ?
<= /div>

I want to mention also &= quot;minimal-responses" option in BIND. Overhead/overkill from a DoH p= oint of view (certificates, sessions, perceived speed), but that might be a= benefit for a DNS server... nowhere in RFC is written than a client needs = more than what it queried for (recursion) !!

Another importan= t nuance we should agree on... HTTP is stateless, are we discussing about b= uilding a stateful API server ? One that works with "states" befo= re giving out answer? A server able to judge the quality of a given set????= ? because i do not see how a single API call can drive multiple "inter= pretation" of the same message (received upstream). Otherwise as usual= , the intelligence must reside on client (aka retry, fallback or fail).

DNS clients do already &quo= t;suffer" from the same issues, as also mentioned, many firewalls in b= etween...

I think the &q= uot;retry intelligence" should reside on client, as a DoH server is by= definition a proxy (eventually offering options to minimise/alter/complete= responses if you want).


On Wed, Jun 6, 2018, 11:50 Patrick McM= anus <pmcmanus@mozilla.com&g= t; wrote:


On Wed, Jun 6, 2018 a= t 8:23 AM, Andrew Sullivan <ajs@anvilwalrusden.com= > wrote:


TC-bit-containing DOH message is almost certainly garbage that needs
to be resolved via a different path, and it's therefore pretty hard
for me to see why this isn't just an error condition.
=
It is my understanding that the TC bearing response is the b= est one that the DOH Server could generate. The assumption is that this is = better than returning no response at all (i.e. just an error) because the c= lient might be able to make use of it. If it has no value, then it should b= e an error (which probably means must not send and if received must be trea= ted as error). But my understanding is it may have value to some clients. S= et me straight as necessary.

It is what it is = - if you need more information and have another path available then try and= resolve it that way assuming it meets whatever security requirements you h= ave - but beware that some clients won't have another path.. for exampl= e javascript clients have only access to http, and the servers they may con= nect to are constrained via same origin policy.
=C2=A0
<= div>In practice DoH isn't constrained by size - so shifting to another = transport with the same recursive isn't likely to improve things; I wou= ld think using a different recursive would be more likely to bear fruit. Th= ere's obviously no way to say that definitely.


=

_______________________________________________
Doh mailing list
Doh@ie= tf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000a61981056df7e021-- From nobody Wed Jun 6 05:13:12 2018 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 B4FA9130EE8 for ; Wed, 6 Jun 2018 05:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 C8BhsVzTvUOx for ; Wed, 6 Jun 2018 05:13:08 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873A1130EEC for ; Wed, 6 Jun 2018 05:13:08 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 543229FB55 for ; Wed, 6 Jun 2018 12:12:58 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 081FBAC5B16; Wed, 6 Jun 2018 14:12:58 +0200 (CEST) Date: Wed, 6 Jun 2018 14:12:58 +0200 From: bert hubert To: doh@ietf.org Message-ID: <20180606121257.GA16319@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] EDNS UDP Payload size cache issue X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 12:13:10 -0000 Hi, The draft suggests zeroing the DNS ID field to make sure queries can be cached. One other field that needs to be made constant is the EDNS payload size. If a client requests DNSSEC, there will always be such a field, but it has no meaning over DOH. So it can safely be set to zero. Suggested text for insertion near the end of "5.1 The HTTP Request": Similarly, if an EDNS payload size is specified, it SHOULD be set to 0 in every DNS request, as this field has no meaning within this protocol. Bert. From nobody Wed Jun 6 05:45:13 2018 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 3F087130EFE for ; Wed, 6 Jun 2018 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 b2wCunlgyB9b for ; Wed, 6 Jun 2018 05:45:09 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-oln040092011101.outbound.protection.outlook.com [40.92.11.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE75130EFD for ; Wed, 6 Jun 2018 05:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h/Nl19two4+pUoMKeOCYHbl0SRYydK8b6AVXyKvhSOI=; b=FAI+3BZUfDhhz0YrH7QWg4NhxmZvSmNO6vHfAhJvYVItxDKB+S4AFB+T8NCXz6kxNwEr2aN8vI6+dvRKLN7WElzG91gNSczYF37jRRLHQ9IBiPdV4SF8GyfTkFpysoUB/cPGsHDFS8FbfyWX5HAfpw1DyF65Euhw40jDzLNoisEAzadciBlc2/odQ7WP8tG3uLtk81BARyn6KVHurvFcS8zRAYKpx8ZZ08GpBsjFHTaWAMbeqbn1Hzc8tSTyoF6GXM2h4EToe63bcPUsmxIpq+uDOENL8H46fWoJUCLbjTTKt7wpSCRzZFIlEvNXR7MbkAncnVKMrajIyBay5NtNdQ== Received: from SN1NAM04FT044.eop-NAM04.prod.protection.outlook.com (10.152.88.52) by SN1NAM04HT100.eop-NAM04.prod.protection.outlook.com (10.152.88.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10; Wed, 6 Jun 2018 12:45:07 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.88.58) by SN1NAM04FT044.mail.protection.outlook.com (10.152.89.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.841.10 via Frontend Transport; Wed, 6 Jun 2018 12:45:07 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::c536:6718:b509:85cb%4]) with mapi id 15.20.0820.015; Wed, 6 Jun 2018 12:45:07 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] EDNS UDP Payload size cache issue Thread-Index: AQHT/Y/BYqhjynHkY0KeUSZh8SgpsqRTJmVS Date: Wed, 6 Jun 2018 12:45:07 +0000 Message-ID: References: <20180606121257.GA16319@server.ds9a.nl> In-Reply-To: <20180606121257.GA16319@server.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:613959A863FEA6E9DEA43A4768CA9B374C8FCFD4CA9083ADF1E37377A04DAE8C; UpperCasedChecksum:D6602CB14B9E734E19EC5E0DC61E999A4BCFD11E34022321EFFEDD04827582D3; SizeAsReceived:7050; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [rITq4nmMGjdofI2wPqQAhWbCOsFgHhxFfooooUjCDM7arX6bnlEfnA==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT100; 7:KPbJjsxmlmq9Y08Xmz44XCFsCR58OtBRropA3pKF2MULwM5En+IlSJgQP3BGBt2kpKNEMoo+sXgHs+cKRY0kv2WUOtNMRUuZPsrIVudRtMBPuxnFj3yAMcoJgpoolY9ZoBptBHDj9DuNgdtLRPDWtXb27neUP7cvZtlV4AjiEqsvmXoBn+eTIO/sYCA/FwUXwgTVksHax4avTiMhaVl/AaQkPcp7J+A0ONxayl0q8nRvD6ZwJuLHRSNyEJ5ANR83 x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101448)(1701031045); SRVR:SN1NAM04HT100; x-ms-traffictypediagnostic: SN1NAM04HT100: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM04HT100; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT100; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(82202002)(5660300001)(105586002)(55016002)(6916009)(83332001)(97736004)(486006)(446003)(5250100002)(476003)(104016004)(2501003)(20460500001)(46003)(106356001)(229853002)(11346002)(76176011)(73972006)(8936002)(14454004)(68736007)(59450400001)(99286004)(86362001)(102836004)(6506007)(6346003)(7696005)(81156014)(2900100001)(1730700003)(74316002)(305945005)(9686003)(8676002)(25786009)(6436002)(87572001)(3660700001)(6246003)(3280700002)(5640700003)(33656002)(561944003)(2351001)(15852004)(42262002)(217873001); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT100; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: W4UvK56Lzk5Ny+Z2ez/nv0hlPbw4gNYIJ41XpB2bQOeS/BvZBsBdNJu5BwbNeaS8LG2CfXutASkwggM/FVcIrDV2ulGKAdkjnKvig1DAenc56IiOdEsWJux87JvW27ioruyh41JHpeC98x0Gfsk0cLpuGYEUO6Y4/MVEmajd9OcV/blSufchj5X6Epf6/csQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 5f082afd-3efd-4af5-d60a-08d5cbab555e X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: 5f082afd-3efd-4af5-d60a-08d5cbab555e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 12:45:07.3947 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT100 Archived-At: Subject: Re: [Doh] EDNS UDP Payload size cache issue X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 12:45:11 -0000 bert hubert wrote: > The draft suggests zeroing the DNS ID field to make sure queries can be > cached. One other field that needs to be made constant is the EDNS payloa= d > size. If a client requests DNSSEC, there will always be such a field, but= it > has no meaning over DOH. So it can safely be set to zero. > > Suggested text for insertion near the end of "5.1 The HTTP Request": > > =A0=A0 Similarly, if an EDNS payload size is specified, it SHOULD be set = to 0 in > =A0=A0 every DNS request, as this field has no meaning within this protoc= ol. I vote up for this idea. But why "0", instead of other values (e.g. 65535)? Also I would like to say something negative about this proposal: 1) It would require more code to implement. Using a DNS message parser libr= ary may make the implementation easier, but I am not sure every one wants t= his, especially because it may fail when later EDNS versions are released i= n the future. 2) I do not see any benefit for doing it. It does not reduce cache pressure= either: common value is almost always 4096.= From nobody Wed Jun 6 07:18:39 2018 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 59DF9130F20 for ; Wed, 6 Jun 2018 07:18:37 -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] 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 hmUbuXxMsaCi for ; Wed, 6 Jun 2018 07:18:34 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 A5FA6130F1F for ; Wed, 6 Jun 2018 07:18:34 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50089) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQZGi-000Um7-hw (Exim 4.91) (return-path ); Wed, 06 Jun 2018 15:18:32 +0100 Date: Wed, 6 Jun 2018 15:18:32 +0100 From: Tony Finch To: bert hubert cc: doh@ietf.org In-Reply-To: <20180606093212.GA23880@server.ds9a.nl> Message-ID: References: <20180606093212.GA23880@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 14:18:38 -0000 bert hubert wrote: > > So, the DNS Camel has a suggestion. Specify that DNS messages carried over > DOH can be up to 65536 bytes large and note that truncation should be > handled as if the response was carried over TCP/53. > > Effectively this means that a TC response over DOH is almost always useless, > but this is no loss of functionality since it did not work over TCP/IP > either. We've not made anything worse here. > > And in general this is what I hope that DOH will restrict itself to: provide > access to the DNS protocol over HTTPS and not change DNS itself. Full agreement, and with the rest of your message. Thanks for writing it so that I didn't have to! I think the semantics of a DNS message transported over HTTPS should be the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so forth. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher, German Bight: Variable 3 or 4. Moderate at first in west Fisher, otherwise slight. Fair. Moderate or good, occasionally poor. From nobody Wed Jun 6 07:21:42 2018 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 5103D130F20 for ; Wed, 6 Jun 2018 07:21: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 bp1YD1ePUFNn for ; Wed, 6 Jun 2018 07:21:37 -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 87E84130F27 for ; Wed, 6 Jun 2018 07:21:37 -0700 (PDT) Received: from [172.20.6.227] (unknown [172.20.6.227]) by mail.nic.cz (Postfix) with ESMTPSA id CD02E600BD for ; Wed, 6 Jun 2018 16:21:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1528294895; bh=TO9DznH9bekJWECeuZnckNAxBR10W5sRNfYR9JJMWNM=; h=To:From:Date; b=TYAwabp/WpVO1hH9alJeXnprxhK5oXTXG3ZRLDIxdu0PyjHL4bTqGMgSTHRiXDMvZ RK3qrhHv9uYo3WCY/lGbEdZcTDGvtbivQXnztcT2J6oZrz/+O42sJFIJleYZneLh08 FZFlEBWqcpr78GSO6LBNHtRJXwKt6Isy3XmTTV0Y= To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <35969d8d-c64d-86a6-9edb-0bbe8f2863d6@nic.cz> Date: Wed, 6 Jun 2018 16:21:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 14:21:40 -0000 On 6.6.2018 16:18, Tony Finch wrote: > bert hubert wrote: >> >> So, the DNS Camel has a suggestion. Specify that DNS messages carried over >> DOH can be up to 65536 bytes large and note that truncation should be >> handled as if the response was carried over TCP/53. >> >> Effectively this means that a TC response over DOH is almost always useless, >> but this is no loss of functionality since it did not work over TCP/IP >> either. We've not made anything worse here. >> >> And in general this is what I hope that DOH will restrict itself to: provide >> access to the DNS protocol over HTTPS and not change DNS itself. > > Full agreement, and with the rest of your message. Thanks for writing it > so that I didn't have to! > > I think the semantics of a DNS message transported over HTTPS should be > the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so > forth. I totally agree with Bert and Tony, thank you for an excelent summary! -- Petr Špaček @ CZ.NIC From nobody Wed Jun 6 07:49:57 2018 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 7860C130F69 for ; Wed, 6 Jun 2018 07:49:46 -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] 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 ND72ylCIuhpJ for ; Wed, 6 Jun 2018 07:49:43 -0700 (PDT) Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 C8C3F130F89 for ; Wed, 6 Jun 2018 07:49:42 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:44208) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQZkq-0003aY-Lz (Exim 4.91) for doh@ietf.org (return-path ); Wed, 06 Jun 2018 15:49:40 +0100 Date: Wed, 6 Jun 2018 15:49:40 +0100 From: Tony Finch To: doh@ietf.org Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: [Doh] special meta QTYPEs X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 14:49:56 -0000 I think there needs to be some specific wording about query meta-types (i.e. 128 <= QTYPE <= 255). Meta-types can change the framing rules of the response, e.g. IXFR and AXFR, so a DoH server needs to understand them even if it is implemented as a mostly-blind proxy. My DoH implementation generates its own NOTIMP response if it gets a query with 128 <= QTYPE <= 254 (it allows QTYPE=*/ANY). The other meta type is OPT, but it isn't special-cased because it's safe to proxy. BIND returns FORMERR rather than NOTIMP for unknown meta-types; it seems to reserve NOTIMP for known but deprecated types. I think it is reasonable for an implementation to support TKEY or MAILA or MAILB if it wishes. I don't think it's possible to fit AXFR or IXFR into DoH because their responses involve multiple DNS messages. Suggested wording: A DoH server MUST return a DNS error response, either RCODE=1 (format error) or RCODE=4 (not implemented) if it receives a request with an unknown meta-QTYPE between 128 and 254 inclusive. The meta-QTYPE 255 (* or ANY) SHOULD be supported. The meta-QTYPEs 251 (IXFR) and 252 (AXFR) MUST NOT be supported and the DoH server MUST return an error response. This is because meta-QTYPEs can affect the way a DNS response is framed; for example, AXFR and IXFR responses can span multiple DNS messages, whereas A DoH response can only contain one DNS message. Tony. -- f.anthony.n.finch http://dotat.at/ Humber: Variable mainly north, 3 or 4. Moderate at first in northwest, otherwise slight. Fog patches. Moderate or good, occasionally very poor. From nobody Wed Jun 6 07:58:26 2018 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 7D2ED130F4C for ; Wed, 6 Jun 2018 07:58:24 -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] 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 Zr_-JjLIY2MM for ; Wed, 6 Jun 2018 07:58:21 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 C3679130F3A for ; Wed, 6 Jun 2018 07:58:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39275) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQZtE-000UXX-1f (Exim 4.91) for doh@ietf.org (return-path ); Wed, 06 Jun 2018 15:58:20 +0100 Date: Wed, 6 Jun 2018 15:58:20 +0100 From: Tony Finch To: doh@ietf.org Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: [Doh] terminology: "DNS API" X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 14:58:25 -0000 Can we amend the document to replace "DNS API server" with "DNS-over-HTTPS server" or "DoH server" please? To me, "DNS API" suggests something like getaddrinfo() or getdns. I understand that in the web world, "API" suggests something-over-HTTP that isn't a web page, but even in this context I feel I should expect a protocol involving more JSON. Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth: Variable mainly northeast 3 or 4, increasing 5 at times. Slight or moderate. Showers, becoming thundery. Moderate or good, occasionally poor later. From nobody Wed Jun 6 09:07:17 2018 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 AFBFA130F6F for ; Wed, 6 Jun 2018 09:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 Rf4fueOYQ-UT for ; Wed, 6 Jun 2018 09:07:08 -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 A13B3130F66 for ; Wed, 6 Jun 2018 09:07:08 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w56G6XIh029581; Wed, 6 Jun 2018 17:07:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=dRfKShHj9fAc68U4dXiuRr5u+HRy+/bwhriFkrYez8I=; b=D+Kv7hNvs34WTGwQyQFNVKeq0fTD01PKOU4SV5he3jos/6C2yYP41a7uhKrzM/Qe46in hWNANlvesidAR2Ou3qiGs+WmkXmWTno70VoZ4iqpO5g3ENy3kZO0qb/XRGJGxUZPcrlo sv/5tQHFJb2G2v9dJw1iaFVl3GGsiXOR7o7dTn3o2Sg+ZC+yuvs9aqVhD5IzDIYL2mnW qdwZf31y92522CkaxJj5w2U/jvKj9zp6w8rk80Vmx3QkoiaSxlkSo/dQbW43HCFQv8Aw FS5634oXuEXP+q2d+LyKZHURHX1bQwmChwmhxfNpFEts3K+a2ZfCXYYwCfD5+TSWuUbr 4g== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2je97wab3c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 17:07:07 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w56G6A56018465; Wed, 6 Jun 2018 12:07:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2jbpjw3qub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Jun 2018 12:07:06 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 6 Jun 2018 11:07:05 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1365.000; Wed, 6 Jun 2018 11:06:59 -0500 From: "Hewitt, Rory" To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , "doh@ietf.org" Thread-Topic: [Doh] DNS Camel thoughts: TC and message size Thread-Index: AQHT/XlIweVnVgymmkuvmY5C/GuZb6RTm14AgAAA2oD//8lloA== Date: Wed, 6 Jun 2018 16:06:58 +0000 Message-ID: <2444368b1a6543cc9aff67317e9ab82a@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <20180606093212.GA23880@server.ds9a.nl> <35969d8d-c64d-86a6-9edb-0bbe8f2863d6@nic.cz> In-Reply-To: <35969d8d-c64d-86a6-9edb-0bbe8f2863d6@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.63] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F9_01D3FD75.B8BC3760" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_07:, , 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-1805220000 definitions=main-1806060183 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-06_07:, , 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-1805220000 definitions=main-1806060183 Archived-At: Subject: Re: [Doh] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 16:07:14 -0000 ------=_NextPart_000_00F9_01D3FD75.B8BC3760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 from me also. Thanks Tony & Bert (and Star!) for narrowing in on an = elegant solution, wording-wise. Thanks, Rory -----Original Message----- From: Petr =C5=A0pa=C4=8Dek [mailto:petr.spacek@nic.cz]=20 Sent: Wednesday, June 6, 2018 7:22 AM To: doh@ietf.org Subject: Re: [Doh] DNS Camel thoughts: TC and message size On 6.6.2018 16:18, Tony Finch wrote: > bert hubert wrote: >> >> So, the DNS Camel has a suggestion. Specify that DNS messages carried = >> over DOH can be up to 65536 bytes large and note that truncation=20 >> should be handled as if the response was carried over TCP/53. >> >> Effectively this means that a TC response over DOH is almost always=20 >> useless, but this is no loss of functionality since it did not work=20 >> over TCP/IP either. We've not made anything worse here. >> >> And in general this is what I hope that DOH will restrict itself to:=20 >> provide access to the DNS protocol over HTTPS and not change DNS = itself. >=20 > Full agreement, and with the rest of your message. Thanks for writing=20 > it so that I didn't have to! >=20 > I think the semantics of a DNS message transported over HTTPS should=20 > be the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes,=20 > and so forth. I totally agree with Bert and Tony, thank you for an excelent summary! -- Petr =C5=A0pa=C4=8Dek @ CZ.NIC _______________________________________________ Doh mailing list Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh ------=_NextPart_000_00F9_01D3FD75.B8BC3760 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDYwNjE2MDY1N1owIwYJKoZIhvcNAQkEMRYEFGHk0ftJa6HMoYFkL7o2TwDtfJLuMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAKIZmWubXSXxu/3y7tmr+5W+SiVptCcwF/xQWRE/H3R0TBrTXbebB1v+IxaT 7u47rz2iZehdRHhGmuXRTUJJro+PCMRckINrvNIekGNFXFKbwEkgxU71x3Jumq9cSjMvyb/F9LmW H3CQnuUlMlcsSCd7iRPVl2VAzcrrvB/3WdiwImumscd8Q7+mqWpcTlYoY9tAmp8FS0EEsuL2kiJN 1c6Q922AbkebW+85uwsz4Ypg9pEFyggr5xAHzm13f23nJb7G6ZUEZZkRBZUjBzwvvC4KojV/z0iP c7bp1K/WEBu/LAPxuUe7hF6cH+KFd0G9u+0AncwCHB1xr+ZVVF14TMkAAAAAAAA= ------=_NextPart_000_00F9_01D3FD75.B8BC3760-- From nobody Wed Jun 6 14:23:06 2018 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 9B99E130FF3 for ; Wed, 6 Jun 2018 14:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 UGU6zYScvGBS for ; Wed, 6 Jun 2018 14:22:46 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 C7BE8130DD8 for ; Wed, 6 Jun 2018 14:22:45 -0700 (PDT) Received: from hydrogen.local (j48230.upc-j.chello.nl [24.132.48.230]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id DF3E28689 for ; Wed, 6 Jun 2018 23:22:43 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1528320163; bh=0yW9ONGEsQXn9H2NQE/GGU63SEBte1wv/vd47PpzV0g=; h=Subject:To:References:From:Date:In-Reply-To; b=UmNsV8jHVpOi09cvl7GMg5bI2tTI5AT4hOWwTXx2tl+l4+vXkbWEkA9sOS0qKdG8Q nwz9FjcvRoiKvmvQFHCKxY9ZLXIEGI84t62MTBVW1Fuj5VJ+26BHUZAcw6dPPbjAqO TvQHxbs0eaXqgZGycNZDlSwEpbe4kds78wVE5Wfc= To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> <35969d8d-c64d-86a6-9edb-0bbe8f2863d6@nic.cz> From: Benno Overeinder Openpgp: preference=signencrypt Autocrypt: addr=benno@NLnetLabs.nl; prefer-encrypt=mutual; keydata= xsFNBE2vPv0BEADE2LbwfYmwzLAiPe4DJ1FlhYQNFEKik7CLTzdmgUrLldhoQBu+UbzKWrqo 4B61d3jRwgEVXkXzUucwzwJxU0hHoQTdLNWf2xjvyBwtG/I/lim2tm8MT9NhRQgGjfi3emHS QeuyfWHntrVRO6hOqGBGjjeVDmAwA9Mq8Lg1i/pH/0fPBNCJgfGv7W+PIGD/HslwAXJJyetN GoFiSp7A0GpPFQcF3e8ZFuHWGeeLCazPZTEESXR4gQhW0uD1Rin0F5Nn+GP/u3A48RiVRYip hoQU2Y/ZFBowXA9kD+Gk1/4mZ3WExkqbWp9k50uC0eUUJyM8MPFSu+PhXQtXYNAXh+d7Dqua nQEWHOD3UfGPIeH8O8xlkFskDxQKqEFQqbkAsODuute+ogbfME3ET9imDGLuiV2ma98zZS4Y 4ABuYmfV8Uj1PanDN2bCBCHOTzMa5U5LB+YbRDSI6bePs86r/ifICofs8W7yqC9U9eV3Vd3A R7p4Ncu5rN5JK0E/4ydBH/2T/3Nbzd6FKvoFPrjR2fsNfi41RaTQ96Zs2igzdW3Q4KbNiZHx 1VhGDCFLJyW9amZJsM7nBDNg1HnNjg6+Wbc21VjCRGYwgejImaJzqG9BJQJV7PH79GP5Mh/0 AqIwkejZkQmnZCnpyRl69cSJ4N9urKpRGHdo7eCJeYCpvzE3owARAQABzTRCZW5ubyBPdmVy ZWluZGVyIChXb3JrIEFkZHJlc3MpIDxiZW5ub0BOTG5ldExhYnMubmw+wsF7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCTa/1awIZAQAKCRCsiZiNy3/98UrAD/9HRXg7 wFP4E+kIMEz6T2j6lpcLUAbBrZwLsxOD5zH/ClTuRrfDd7nMCGpPtGJVT5pgLurZloRqPBYe QDZn1+a37DUl9t85d4D9J+B6NYP8uxAXZqbSDvDeRPt+NO6wHL1rStv3ZIugX5voJKYlNmvh 3ljvF+VeYjTwZykTd7hXWTwZc4K6Rq3eVfP1aZcDvmjXPWfT4So7VnJTH5XwnDd1zFTjztNM U405uXOM1z9tRYZeDbbSpWidvap+IWHt/OA2Vymd+EKH87yfIxFZsSxT+FGRnxC1Ll3I6TX7 IID1bGP7/SgeZ5yHAq54WTrvTwhib7WWCWmAMnEzdYHTF9bOtiVrGg3LMvfX+g4cuM6aEwqS VOB6zfxwJBcFwYlZ/YhyerhmpIPr4AxnuhEVRX35VSf0XX9Hlb/ETNauCJEKfLFN9VjJ1FC3 7fWOZ+KqvHdFO+gmZ48+5OOqoID8T3QyqoO/MKluV/XTQKkxYXoh3Pf5ZBHshffMUMshFrQi FoZkbkv1DBBtM0YpcDL0+oPH9S8oIpRD0PgpPOrVVC2f23KZ60Lf2vzLJW28/aKEfnGvjU2A ZP7ujjBnQ3bVqdV9iuES6j5W6TpGguvUZ8cjY/n1qfGPvkTgqAG6pQ1UrUMP7Oa+eCml8Ssa GeQkl77jGBjabFnIsW3SVCNOU+waTs7BTQRaJ/NsEAgAn8u+d2VfuogyxrK2SW3r9ZhtQxMo rrizi77DTRqU9sTQjVxRFTJtZ2mdU+E/bi+uc5aYPcehXJSkKA2TZ5/Y2HF4+hDbLslhl22o L6Ti1rfrhdNgir57eY5Bs3DjHkWY59Ij+s1sIL70Z+go66u3x3ChJoM6TXX65vJPRKEYS2Eu ZxEUSgRcssrki9e/Sj1Orsu1J9h4/l7GRGbB5pVLV4/yytShJghijwsjiWYH1SA42T7DVLIy pCy/H/xmJSLO9aW962lJAgHL/J4PSPCLHOk3z364WyrWseb4MLf4gabLTvhuqJ1igrV777L9 oirXEyCxj3nO6WCNqY8ncpgwDwADBQf5AQqPoLRG3chjyvUtkY852rR0vPz4pJP4j+1x8Op5 BEEFCLQa1RHVe0f+L7bl2umtiF+5iatK3SpY1Ra9iU/2Rw26jilLFfymf30OR99SZnL0kicG 4BMoVshN3lWje6DeoAvt6iQfKXEh2cdgbXj3vUcMTpB6wjwalyqhYDgOYXZcsTpHHHCucjjo PvbcMrbNM2wlYaWwrupXbWYaveuVm8JESiZX0XmKPoG7y1mlAOJcfuurDOb1LVFyUX9Uumv2 uSxnycfJQrFwhXcEy8swqZYZGNhw1U8bFYeZPkgkThkIS2PWAT2HczRVVIp86Gt1OAs/ogQN pfZyXigBzIuzIsLBfAQYAQoAJhYhBLflxeOG3VADrVcT4KyJmI3Lf/3xBQJaJ/NsAhsMBQkH hh+AAAoJEKyJmI3Lf/3xTGUP/3JVhY0ILibuuTZxaG4uqS9/POXSswQy2TjC/GvRkhmwall2 57E/YSrbcpEBxZMfRdjKRKlwc0FHvzqlG8Bt0KiuTmEiu14N1ZjsD2ZZp69/inppwMC7QaDT OiGAwkNtTcGEU34od8OlmDolfAy1xZ2EpS/vNHjhsn2RziC1MM7E/b9Fr/X5/Zo3/Qfxb0a4 7BddS3JSN3oG1NHfIa3t/0+eBF1aaejbCAvaBshShonRTaRKPGYM0h7DjHDh/aC46jwrX+TA H66KEc1DcM5Sy/IskgW1HhWRPpDRxGdVI6mVZDAGcPLuLIx8cjRBkOYRkYLeRRPU+TLh1A5f lPaFTgJvajJV2wXYUewuWIk5pEhOIHFi5fTzGR8OW6/PXKe0h5ROQU1lGIgLBO20BAXoBdJj zAi67vFGo4WP+keLy4PZgiWNj/xf6KcOhNYOEUFg0wXjhJud87l8dhZRFvKPefgD37Y0/Jof fpBW7QKUX/9ChJLCQcCBnZIrcxJnz4ii1F1POa5L5ziF1Tew4RX2WFbfNJlyhGRP8xFaNsyW qQfMe+PF9fUa/32K1fCxEJCLTb2Age6cnEEjuWERI4up5Ae8XfvBQj9nM3df4trvewE4KOZ1 nyDa4t9iZCrDMabuudgwJBBxQ2gbnDKQstvp57amDKUKHfG6c3h1R0EanBAl Message-ID: Date: Wed, 6 Jun 2018 23:22:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <35969d8d-c64d-86a6-9edb-0bbe8f2863d6@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 21:23:04 -0000 On 06/06/2018 16:21, Petr Špaček wrote: > On 6.6.2018 16:18, Tony Finch wrote: >> bert hubert wrote: >>> >>> So, the DNS Camel has a suggestion. Specify that DNS messages carried >>> over >>> DOH can be up to 65536 bytes large and note that truncation should be >>> handled as if the response was carried over TCP/53. >>> >>> Effectively this means that a TC response over DOH is almost always >>> useless, >>> but this is no loss of functionality since it did not work over TCP/IP >>> either. We've not made anything worse here. >>> >>> And in general this is what I hope that DOH will restrict itself to: >>> provide >>> access to the DNS protocol over HTTPS and not change DNS itself. >> >> Full agreement, and with the rest of your message. Thanks for writing it >> so that I didn't have to! >> >> I think the semantics of a DNS message transported over HTTPS should be >> the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so >> forth. > > I totally agree with Bert and Tony, thank you for an excelent summary! Thank you for the clear write-up Bert. Like Tony and Petr, I fully agree with your message. -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From nobody Wed Jun 6 15:42:15 2018 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 3A89A130FE5 for ; Wed, 6 Jun 2018 15:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 ElxV1Yr7KMM7 for ; Wed, 6 Jun 2018 15:42:11 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 2A752130DE1 for ; Wed, 6 Jun 2018 15:42:11 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 6 Jun 2018 15:42:08 -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; Wed, 6 Jun 2018 15:42:08 -0700 From: Paul Hoffman To: DoH WG CC: bert hubert Thread-Topic: [Ext] [Doh] DNS Camel thoughts: TC and message size Thread-Index: AQHT/eeZrdvRGu1kHUiE0BSLfpZdOQ== Date: Wed, 6 Jun 2018 22:42:08 +0000 Message-ID: References: <20180606093212.GA23880@server.ds9a.nl> In-Reply-To: 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: <48EED5B625AFF54AB5FDE287B4B4A03F@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 22:42:13 -0000 I hear a lot of support for Bert's wording: Specify that DNS messages carried over DOH can be up to 65536 bytes large and note that truncation should be handled as if the response was carried over TCP/53. This thread has brought up a significant concern that I hope those supporti= ng the language can clear up. On Jun 6, 2018, at 7:18 AM, Tony Finch wrote: > I think the semantics of a DNS message transported over HTTPS should be > the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so > forth. Three people agreed with this statement. DNS-over-TCP is defined in RFC 103= 5 and significantly updated in RFC 7766. Unless I'm missing something, neit= her of those document support the 65535 length restriction; in fact, RFC 10= 35 section 3.3.10 indicates that restriction doesn't exist because a respon= se with a single maximally-sized NULL Rdata record could be slightly longer= than that, and there is no restriction on how many NULL records can be in = the RRset. Such a message could not use name compression into the a section= beyond the Answer in that message. Similarly, there is no restriction on t= he total length of a TXT record. Having such records is clearly a bad idea,= but they are not prohibited by the specs. So, if this WG puts such a limitation in DOH, we are adding a restriction t= o DNS messages that is not currently in DNS-over-TCP, even though it is a "= sensible" restriction. If we do so, I would hope that (as a separate effort= ) we would get the DNSOP WG to start an update RFC 7766 to have the same re= striction. If we don't want to do so, it would be better to only add the fo= llowing from Bert's proposal (slightly reworded): DNS message truncation and the use of the TC bit should be handled as if the response was carried over DNS in TCP as defined in [RFC7766]. As document author, I'm OK with either outcome, but would prefer the second= just because it doesn't require asking the DNSOP to have to add polish to = an existing camel toe. --Paul Hoffman= From nobody Wed Jun 6 15:49:50 2018 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 788E6130DEA for ; Wed, 6 Jun 2018 15:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 SB7b3WGU8f95 for ; Wed, 6 Jun 2018 15:49:38 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 56FE1130DE1 for ; Wed, 6 Jun 2018 15:49:38 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id y4-v6so5095742qka.5 for ; Wed, 06 Jun 2018 15:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BoOvbITB6pUh54BHpv5LoNFzpy0+4gOR/52delANQ2U=; b=Ie9QXiYJpcFXlC0PlQ6KR8pumo06G7jKkTv3IUmC0Q5J54WvEFXGpRAI6GU2qwB2Yp t/4Wug22Twkac3JriJhMtdeqAfX2R0D9zf5gfMLgXiZ5dg9j0L3Kj9mpEfofrleiphMl oZw7Zm7td2PzWmIAfIS/9saif/pBH7BALFDcKK9yuTvISJfPSAZltP2eBLKVywi6QpxD NholrILaiq8XJMF4tLHewxIUEZfJ1Jvio6wk/qRpbi+lXvuPJiZj61ThaEYLQvSpBdvB /eDRaBJc0esdUr1bPuAyx4P+zC3gKxFvabS1s/F2G7ID4ZEYbF5C20lG2HzCfiCxyK2f 40HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BoOvbITB6pUh54BHpv5LoNFzpy0+4gOR/52delANQ2U=; b=Oif7dZQ2UnhKVvki/O76aMATpUeYQOGUGE4YECN6RYK1U8uPDQiMDlo/XXKca2uGGT xt0/3zg3zT9Bti5Nbf6KGdS74REhVJYErZYN79MLWSGHJo7Q423DJ4ZTNOubju/XQ++j /R2uSQeVxG9FFnktmKRYG0EEfMsv8kmZjwbwPztdLql3CnnjNSyC2Fi6BxBLlCRGg15m oOiLm+z28C2vjv2285NRRNzualukERSf+h9iX2LQ6VPwP+huQyQzOsPu/EQ50k/pOzl/ jBo4fL0CunruhOOSq625+dc2QcxStq1v0YpjmOnCfvwb/B4X7mdN8ipsulMMwCqHELVg XHEA== X-Gm-Message-State: APt69E1+kpSmfSpoI0E8PINdCHUd7M8x67SgXIlo93NDxTE7kn2Fz63P n7FSoi+lFm5Vs58fsuDtrknyNkoryi0CLrr7FgzC6g== X-Google-Smtp-Source: ADUXVKLCu2OmXIpntTczIj3ZnBgFJ+sf4hFekNUBNGH9JriDTljmuN/L8EvykFvofL4f2/6Q6qlS00uEO3YEgRJa7Uk= X-Received: by 2002:a37:a608:: with SMTP id p8-v6mr4127012qke.82.1528325377357; Wed, 06 Jun 2018 15:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:32a3:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 15:49:36 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:5c64:b88b:26a2:a5de] In-Reply-To: References: <20180606093212.GA23880@server.ds9a.nl> From: George Michaelson Date: Thu, 7 Jun 2018 08:49:36 +1000 Message-ID: To: Paul Hoffman Cc: DoH WG , bert hubert Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 22:49:46 -0000 I believe the benefits of ensuring a "flow" or "session" underpinning means that fragmentation doesn't happen: that the effective application (DNS as the application) layer payload is delivered UN fragmented, is huge. signalling that in UDP/53 it *would* have happened, maybe thats useful. But carrying a complete, unfragmented, processable, integral outcome, thats a huge upside benefit operationally. Making an unconstrained, non-fragmented channel perform as if it had the same underlying 512 Octet UDP DNS constraint in all ways, I think is a bit silly. So I think a constraint which effects actual end-to-end DNS flow *to the benefit of the client* is worth doing. -G On Thu, Jun 7, 2018 at 8:42 AM, Paul Hoffman wrote= : > I hear a lot of support for Bert's wording: > Specify that DNS messages carried over > DOH can be up to 65536 bytes large and note that truncation should be > handled as if the response was carried over TCP/53. > > This thread has brought up a significant concern that I hope those suppor= ting the language can clear up. > > On Jun 6, 2018, at 7:18 AM, Tony Finch wrote: >> I think the semantics of a DNS message transported over HTTPS should be >> the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so >> forth. > > Three people agreed with this statement. DNS-over-TCP is defined in RFC 1= 035 and significantly updated in RFC 7766. Unless I'm missing something, ne= ither of those document support the 65535 length restriction; in fact, RFC = 1035 section 3.3.10 indicates that restriction doesn't exist because a resp= onse with a single maximally-sized NULL Rdata record could be slightly long= er than that, and there is no restriction on how many NULL records can be i= n the RRset. Such a message could not use name compression into the a secti= on beyond the Answer in that message. Similarly, there is no restriction on= the total length of a TXT record. Having such records is clearly a bad ide= a, but they are not prohibited by the specs. > > So, if this WG puts such a limitation in DOH, we are adding a restriction= to DNS messages that is not currently in DNS-over-TCP, even though it is a= "sensible" restriction. If we do so, I would hope that (as a separate effo= rt) we would get the DNSOP WG to start an update RFC 7766 to have the same = restriction. If we don't want to do so, it would be better to only add the = following from Bert's proposal (slightly reworded): > DNS message truncation and the use of the TC bit should > be handled as if the response was carried over DNS > in TCP as defined in [RFC7766]. > > As document author, I'm OK with either outcome, but would prefer the seco= nd just because it doesn't require asking the DNSOP to have to add polish t= o an existing camel toe. > > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Wed Jun 6 15:56:02 2018 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 28370130DE6 for ; Wed, 6 Jun 2018 15:55:59 -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=yitter.info header.b=C9q9xgXg; dkim=pass (1024-bit key) header.d=yitter.info header.b=lsvTe52E 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 frdjMqFTrqp5 for ; Wed, 6 Jun 2018 15:55:56 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5E31277C8 for ; Wed, 6 Jun 2018 15:55:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id B83ECBDEF9 for ; Wed, 6 Jun 2018 22:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528325725; bh=AkydS5HlWV9FGh0R5ushbgEQ01wp7DN6GAVLmlxASuc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=C9q9xgXgPOILBwAedXKAuPdA0ZraZ7cjMp6G7u5GjzBPnvzXN5Qv7XMuLeUdRtVQJ DjtuFrsJ5Px+aXka2LAsIs4fsm9odbLDjM+Nu+QESdfxFp8+Ya7/voicm+SbSdnYsN Dftct8lbNXf0lF7VR3B718zh4Vjw2+trvoCIC1U4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20uSmmNU4SJk for ; Wed, 6 Jun 2018 22:55:24 +0000 (UTC) Date: Wed, 6 Jun 2018 18:55:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528325724; bh=AkydS5HlWV9FGh0R5ushbgEQ01wp7DN6GAVLmlxASuc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=lsvTe52E6PzE9lebyRW2T/JaXLPkmXCpJEuhknl5WMfpp9oXFC/cpi7uY3DVwbrU5 3uneUvqZbRpgG8jVu8bhmZJYUY5t23zIAX9xgqwaB8KwFrrOVcGMevJO8To/Y3H0CU riO7WrRUyZeRrRw+NKJNY/+FsfA25x+uo5snVGhU= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180606225522.GK2853@mx4.yitter.info> References: <20180606093212.GA23880@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 22:56:00 -0000 Hi, On Wed, Jun 06, 2018 at 10:42:08PM +0000, Paul Hoffman wrote: > Three people agreed with this statement. DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC 7766. Unless I'm missing something, neither of those document support the 65535 length restriction; in fact, RFC 1035 section 3.3.10 indicates that restriction doesn't exist because a response with a single maximally-sized NULL Rdata record could be slightly longer than that, and there is no restriction on how many NULL records can be in the RRset. Such a message could not use name compression into the a section beyond the Answer in that message. Similarly, there is no restriction on the total length of a TXT record. Having such records is clearly a bad idea, but they are not prohibited by the specs. > This sounds actually like a long-unnoticed erratum in RFC 1035, because I _think_ Bert's calculation is correct that there is as of now no interoperable way to send a single message longer than 65535 octets, because of limits in the protocol (I haven't thought about it in detail, but it immediately struck an "exactly" chord with me so I have confidence). I agree, however, that it's not a job for this WG to fix. Therefore, > DNS message truncation and the use of the TC bit should > be handled as if the response was carried over DNS > in TCP as defined in [RFC7766]. I'm ok with this, and I also suspect that an erratum (admittedly not a simple one) on either 1035 or 7766 would be enough to close this hole. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jun 6 15:57:07 2018 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 26A95130FFC for ; Wed, 6 Jun 2018 15:57:04 -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=yitter.info header.b=A19CtNUl; dkim=pass (1024-bit key) header.d=yitter.info header.b=US2CyiGU 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 UgmA6GZfcIpS for ; Wed, 6 Jun 2018 15:57:02 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF483130DE6 for ; Wed, 6 Jun 2018 15:57:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 329EFBDEF9 for ; Wed, 6 Jun 2018 22:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528325822; bh=VgaXZMdvm3ox+iiUeO/mYgCOnckkxTKrQbvcYuGa/HY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=A19CtNUlU93NyuU/lLCWdsg9HnRJLAmmzGKeh+tTRTz4B4gKrhECqNVru2eQfIZbt wAim4BLUkVP8DLyQWuTnXJPqnK/dMj0WDaXUpIVjT3/y95dbK3c1meV+S85bqj9zCM laJTyR7VYLjQMOyqx6HGEgd0ul0bobucQ61lw8VI= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVZ_CdhtQuRn for ; Wed, 6 Jun 2018 22:57:01 +0000 (UTC) Date: Wed, 6 Jun 2018 18:56:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528325820; bh=VgaXZMdvm3ox+iiUeO/mYgCOnckkxTKrQbvcYuGa/HY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=US2CyiGUDACcwnRwmLN/y0VBWaaGWMjbJDbH8RZz1UXCEdh06ZUWiHbLbpvOJa/x3 GwIiz0SFeP3IuqG8r5ctSCffM2DkjCRgs+DHfbHHS/7eqe6TTjKXEkpFn8YLxZR94I 6RslHUiQ9BT2R5WQMYFelAtN6nIbt6sQiSlPUcrg= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180606225659.GL2853@mx4.yitter.info> References: <20180606093212.GA23880@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 22:57:05 -0000 On Thu, Jun 07, 2018 at 08:49:36AM +1000, George Michaelson wrote: > signalling that in UDP/53 it *would* have happened, maybe thats > useful. But carrying a complete, unfragmented, processable, integral > outcome, thats a huge upside benefit operationally. Sure. But if the TC bit is set, surely we're already in the possible world where that hasn't happened? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jun 7 00:19:14 2018 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 6E5F8130E8C for ; Thu, 7 Jun 2018 00:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 LYdWQNM6HmsD for ; Thu, 7 Jun 2018 00:19:09 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD38130E7E for ; Thu, 7 Jun 2018 00:19:09 -0700 (PDT) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 379183A042 for ; Thu, 7 Jun 2018 03:19:07 -0400 (EDT) Received: by mail-ot0-f175.google.com with SMTP id n3-v6so10349769ota.5 for ; Thu, 07 Jun 2018 00:19:07 -0700 (PDT) X-Gm-Message-State: APt69E1LsZY1z1xzOTdKk7MQL6rVNdxKBvH0rm5D3a853DvjiMiq1rTw LpPc/tkGopLbOJ13a7YjKF9KDMCkabEGGg/zGZw= X-Google-Smtp-Source: ADUXVKLrn5sFjDkNPI/0aeglOsSu5aN5dKrfwfNWxcfAdC+KN+0+WFR0efzdnQS/61Uhs0Nru1uD7Fh+o0Hxr0MSoz8= X-Received: by 2002:a9d:2c41:: with SMTP id f59-v6mr322813otb.263.1528355946900; Thu, 07 Jun 2018 00:19:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 00:19:06 -0700 (PDT) In-Reply-To: References: <20180606093212.GA23880@server.ds9a.nl> From: Patrick McManus Date: Thu, 7 Jun 2018 09:19:06 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: DoH WG , bert hubert Content-Type: multipart/alternative; boundary="0000000000004e3473056e081946" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 07:19:12 -0000 --0000000000004e3473056e081946 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 7, 2018 at 12:42 AM, Paul Hoffman wrote: > I hear a lot of support for Bert's wording: > Specify that DNS messages carried over > DOH can be up to 65536 bytes large and note that truncation should be > handled as if the response was carried over TCP/53. > > This thread has brought up a significant concern that I hope those > supporting the language can clear up. > > it seems possible that this is a property of the default media type not of DoH. e.g. a negotiated json response wouldn't have this kind of limitation. Does that make sense? --0000000000004e3473056e081946 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 7, 2018 at 12:42 AM, Paul Hoffman <paul.hoffman@icann= .org> wrote:
I hear a lot o= f support for Bert's wording:
=C2=A0 =C2=A0Specify that DNS messages carried over
=C2=A0 =C2=A0DOH can be up to 65536 bytes large and note that truncation sh= ould be
=C2=A0 =C2=A0handled as if the response was carried over TCP/53.

This thread has brought up a significant concern that I hope those s= upporting the language can clear up.


it seems possible that this is a property of the default = media type not of DoH. e.g. a negotiated json response wouldn't have th= is kind of limitation. Does that make sense?

--0000000000004e3473056e081946-- From nobody Thu Jun 7 02:37:04 2018 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 AB4C3130FE9 for ; Thu, 7 Jun 2018 02:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 F-ioIGoRBomj for ; Thu, 7 Jun 2018 02:37:00 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EF3130E86 for ; Thu, 7 Jun 2018 02:36:59 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id C39889FB55; Thu, 7 Jun 2018 09:36:48 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 9C3C5AC5B25; Thu, 7 Jun 2018 11:36:47 +0200 (CEST) Date: Thu, 7 Jun 2018 11:36:47 +0200 From: bert hubert To: Patrick McManus Cc: Paul Hoffman , DoH WG Message-ID: <20180607093647.GB32326@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 09:37:02 -0000 On Thu, Jun 07, 2018 at 09:19:06AM +0200, Patrick McManus wrote: > it seems possible that this is a property of the default media type not of > DoH. e.g. a negotiated json response wouldn't have this kind of limitation. > Does that make sense? Firstly, it is not a media type limitation. It is a question of if we want to extend DNS into a territory where it has never been before. The moment 100 kilobyte DNS answers become possible, we need to redo a ton of software. This is true if the end transport is JSON or a DNS message wrapped into an HTTP response. Before typing a lot more characters on this, can I ask who is actually arguing that we need bigger DNS messages? Who is hurting under the 65536 byte constraint? DNS over HTTPS implies that we have access to HTTPS. This protocol supports messages as large as you want. The one reason you might like DNS to be able to do something new and large is because you might have no alternate way of getting large data. So I ask, who wants to fundamentally extend the DNS protocol with messages of a size never seen or supported? Who is the customer? Bert From nobody Thu Jun 7 03:30:23 2018 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 DAFB7130EE1 for ; Thu, 7 Jun 2018 03:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 3EzL5l9syRMl for ; Thu, 7 Jun 2018 03:30:17 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 15353130ED2 for ; Thu, 7 Jun 2018 03:30:13 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id p185-v6so11999596itp.4 for ; Thu, 07 Jun 2018 03:30:13 -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=DU+ZWUHCbUSirH7co7XfVLVQHr0WqCmwam4Wnj+U2Cg=; b=sznsv77cmtR5Sm1Bxe+YT8zf2XFBfjAXlif2Yn5a1CS4b2gy5RgsLWhKkiik8UMrdC PGD83moD2DByNWqHiNPIo8SZpE9g4UjTeAs2jqglxc88qJgPo8u7Z8AwRyAF1SQ+2xa3 dLu0fddcxY+UuvWULpAWd3ge//Et8dExTWRQmRP1HNlEWU6LMRQJem+LceP/Lx5EJ4P3 95MHVAuQNfrvyImy+Ubd2WsySWva1inIZi+tgUBleP7X3dsgzLqBNrhQ+78NqKGCRdZk /Ldj1Axc7YLnhwj3a9+HjZBMY3r7CO0wCuedOK3XfvmnkR4Muy2zTTZoEEMUFQkPguEg wfyg== 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=DU+ZWUHCbUSirH7co7XfVLVQHr0WqCmwam4Wnj+U2Cg=; b=a1YpKIt/AOTndNaDuMRd269Cf2eNGCH6EFx06D8i7AaqFXPZ3DhWtSTy0ig23dDVqc DJ0TUWM6tFeZ1NSHWjF89DeJxPouSWnMq6Ist+8DHr/vx9JRy/LDAUMr0Ey51dL+tjsS tgNJA/Iaq2ytT4RLc1tjOaX+3b7eWdVXnp8ysXQ9Ry4uvHuVp8NVMjEWg8MgcUvgT46k sRvWkv/O+5mTJUQ+5f4ENr9LpUdjI9H5DaRfGLcZx5+ZvNqStY50iAqPv1SmAYaavqec fZQNh0lSUTyLqhFa14vne7tABFowa89xWKxo5vAuz2DcZcNVbH5P+xugzkD7NsjksQQj rTZw== X-Gm-Message-State: APt69E1rED5u6FFfl3EglZtRKx0lud48Wqlbdxyx75ox0NPxx/hiyGQu UHmkiJV5ZuKIGSnzO0xmotP4cx7g4JrAuhjSGvEjjK8zlww= X-Google-Smtp-Source: ADUXVKKiQXV8SBCeNUX6cUhk9sPQAvkxr99NNNMAHmBWBXLhr0eA/gncIQZf9XJbee2g6Fy1OTnVgcEaKN8pigurHK8= X-Received: by 2002:a24:1301:: with SMTP id 1-v6mr1374226itz.55.1528367411857; Thu, 07 Jun 2018 03:30:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Thu, 7 Jun 2018 12:29:59 +0200 Message-ID: To: Tony Finch Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b5f2f0056e0ac48c" Archived-At: Subject: Re: [Doh] special meta QTYPEs X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 10:30:22 -0000 --000000000000b5f2f0056e0ac48c Content-Type: multipart/alternative; boundary="000000000000ac100a056e0ac4b8" --000000000000ac100a056e0ac4b8 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 6, 2018 at 4:50 PM Tony Finch wrote: > I think there needs to be some specific wording about query meta-types > (i.e. 128 <= QTYPE <= 255). > > Meta-types can change the framing rules of the response, e.g. IXFR and > AXFR, so a DoH server needs to understand them even if it is implemented > as a mostly-blind proxy. > > My DoH implementation generates its own NOTIMP response if it gets a query > with 128 <= QTYPE <= 254 (it allows QTYPE=*/ANY). The other meta type is > OPT, but it isn't special-cased because it's safe to proxy. > > BIND returns FORMERR rather than NOTIMP for unknown meta-types; it > seems to reserve NOTIMP for known but deprecated types. > > I think it is reasonable for an implementation to support TKEY or MAILA or > MAILB if it wishes. I don't think it's possible to fit AXFR or IXFR into > DoH because their responses involve multiple DNS messages. > Do you believe this is an intrinsic property of DoH, or can you imagine a future media type that could represent AXFR in a single HTTP response? Suggested wording: > > A DoH server MUST return a DNS error response, either RCODE=1 (format > error) or RCODE=4 (not implemented) if it receives a request with an > unknown meta-QTYPE between 128 and 254 inclusive. The meta-QTYPE 255 > (* or ANY) SHOULD be supported. The meta-QTYPEs 251 (IXFR) and 252 > (AXFR) MUST NOT be supported and the DoH server MUST return an error > response. > > This is because meta-QTYPEs can affect the way a DNS response is > framed; for example, AXFR and IXFR responses can span multiple DNS > messages, whereas A DoH response can only contain one DNS message. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Humber: Variable mainly north, 3 or 4. Moderate at first in northwest, > otherwise slight. Fog patches. Moderate or good, occasionally very poor. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000ac100a056e0ac4b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Jun 6, 2018 at 4:50 PM Tony Finch <dot= @dotat.at> wrote:
I think = there needs to be some specific wording about query meta-types
(i.e. 128 <=3D QTYPE <=3D 255).

Meta-types can change the framing rules of the response, e.g. IXFR and
AXFR, so a DoH server needs to understand them even if it is implemented as a mostly-blind proxy.

My DoH implementation generates its own NOTIMP response if it gets a query<= br> with 128 <=3D QTYPE <=3D 254 (it allows QTYPE=3D*/ANY). The other met= a type is
OPT, but it isn't special-cased because it's safe to proxy.

BIND returns FORMERR rather than NOTIMP for unknown meta-types; it
seems to reserve NOTIMP for known but deprecated types.

I think it is reasonable for an implementation to support TKEY or MAILA or<= br> MAILB if it wishes. I don't think it's possible to fit AXFR or IXFR= into
DoH because their responses involve multiple DNS messages.
=

Do you believe this i= s an intrinsic property of DoH, or can you imagine a future media type that= could represent AXFR in a single HTTP response?

Suggested wording:

=C2=A0 =C2=A0 A DoH server MUST return a DNS error response, either RCODE= =3D1 (format
=C2=A0 =C2=A0 error) or RCODE=3D4 (not implemented) if it receives a reques= t with an
=C2=A0 =C2=A0 unknown meta-QTYPE between 128 and 254 inclusive. The meta-QT= YPE 255
=C2=A0 =C2=A0 (* or ANY) SHOULD be supported. The meta-QTYPEs 251 (IXFR) an= d 252
=C2=A0 =C2=A0 (AXFR) MUST NOT be supported and the DoH server MUST return a= n error
=C2=A0 =C2=A0 response.

=C2=A0 =C2=A0 This is because meta-QTYPEs can affect the way a DNS response= is
=C2=A0 =C2=A0 framed; for example, AXFR and IXFR responses can span multipl= e DNS
=C2=A0 =C2=A0 messages, whereas A DoH response can only contain one DNS mes= sage.

Tony.
--
f.anthony.n.finch=C2=A0 <dot@dotat.at>=C2=A0 http://dotat.at/
Humber: Variable mainly north, 3 or 4. Moderate at first in northwest,
otherwise slight. Fog patches. Moderate or good, occasionally very poor.
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000ac100a056e0ac4b8-- --000000000000b5f2f0056e0ac48c 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCC9Fp48US4VNAe0wQ9n63HV QDn6zG7hFJqpqoPTQE6ecjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA2MDcxMDMwMTJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAuxGHmr/iBrJ1hKcOTA1JTU3Xaf6Jx2LJvD2UycAi LGN57cpovE/ax9Brq4463FCWdoNxOpbagQx/9K9KtM/ig9l3BvqTiC+qRihpIMEC9IS2h3yd8am2 R88PVKnVGw8X8lKNNKMA7Nvhi9lTL8p0DF3Pkg4YJuQCIVYrmjSLPl+KQNzlY7eWC5HKDAl177ps ackVMYQxyKr3KxFRyehDAtdm3gqPu1iYJ+1rpGvkKA+ckwD6Vg2AcgtN6/uyB09RC0ADIsME6zrm MQ9dsPO4EuZEznpTuW1r6+NF3iymj2Jo/tsx8FlGH1DwBY1/9E9f7GHhcnoyMIBird9SmaxraA== --000000000000b5f2f0056e0ac48c-- From nobody Thu Jun 7 03:33:31 2018 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 12757130EE7 for ; Thu, 7 Jun 2018 03:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 S2RG9YWRZ1hi for ; Thu, 7 Jun 2018 03:33:24 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 EC50C130ED2 for ; Thu, 7 Jun 2018 03:33:23 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:34226) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQsEL-000MGb-eT (Exim 4.91) (return-path ); Thu, 07 Jun 2018 11:33:21 +0100 Date: Thu, 7 Jun 2018 11:33:21 +0100 From: Tony Finch To: Paul Hoffman cc: DoH WG , bert hubert In-Reply-To: Message-ID: References: <20180606093212.GA23880@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 10:33:28 -0000 Paul Hoffman wrote: > > DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC > 7766. Unless I'm missing something, neither of those document support > the 65535 length restriction; The restriction comes from the 2 octet message length field, RFC 1035 section 4.2.2. > in fact, RFC 1035 section 3.3.10 indicates that restriction doesn't > exist because a response with a single maximally-sized NULL Rdata record > could be slightly longer than that, and there is no restriction on how > many NULL records can be in the RRset. Right. You need to make a distinction between RR data size limits and message size limits. As you say, it's easily possible for an RRset to be too long to fit in a message. If a single RR doesn't fit in a message then it isn't possible to create it via UPDATE or transfer it via AXFR/IXFR, though it can be represented in master files. It's clear such large RRs are not supported by the standards - I guess they don't specify how to cope because huge RRs are an obviously lunatic idea ;-) > So, if this WG puts such a limitation in DOH, we are adding a > restriction to DNS messages that is not currently in DNS-over-TCP, even > though it is a "sensible" restriction. No, the message size limit was always there, even though it is smaller than the RR data size limit. This was the point of Bert's message. As he said, lifting the 64K limit means "almost every DNS parser in existence has become obsolete or at least untested! No DNS message larger than 64KB has ever been possible." > DNS message truncation and the use of the TC bit should > be handled as if the response was carried over DNS > in TCP as defined in [RFC7766]. EDNS buffer sizes need to be handled the samee as for TCP as well. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall, Malin, South Hebrides: Northerly or northeasterly, 3 or 4, occasionally 5 later. Slight or moderate. Mainly fair. Moderate or good, occasionally poor. From nobody Thu Jun 7 03:55:54 2018 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 0E2071310C7 for ; Thu, 7 Jun 2018 03:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ohxwAaj1hvYI for ; Thu, 7 Jun 2018 03:55:47 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 ADB8C130ED0 for ; Thu, 7 Jun 2018 03:55:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:45445) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQsa2-000OOw-11 (Exim 4.91) (return-path ); Thu, 07 Jun 2018 11:55:46 +0100 Date: Thu, 7 Jun 2018 11:55:46 +0100 From: Tony Finch To: Ben Schwartz cc: DoH WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] special meta QTYPEs X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 10:55:52 -0000 Ben Schwartz wrote: > On Wed, Jun 6, 2018 at 4:50 PM Tony Finch wrote: > > > > I think it is reasonable for an implementation to support TKEY or MAILA or > > MAILB if it wishes. I don't think it's possible to fit AXFR or IXFR into > > DoH because their responses involve multiple DNS messages. > > Do you believe this is an intrinsic property of DoH, or can you imagine a > future media type that could represent AXFR in a single HTTP response? It's possible (of course!) but yes, it would require a different media type, and a document along the lines of RFC 5936 (the AXFR spec) that describes it. Maybe your question implies a way for better forwards compatibility: A DoH server MUST return a DNS error response, either RCODE=1 (format error) or RCODE=4 (not implemented) if it receives a request with an unknown meta-QTYPE between 128 and 254 inclusive. The meta-QTYPE 255 (* or ANY) SHOULD be supported. The meta-QTYPEs 251 (IXFR) and 252 (AXFR) SHOULD be treated as unknown. This is because meta-QTYPEs can affect the way a DNS response is framed; for example, AXFR and IXFR responses can span multiple DNS messages, whereas an application/dns-message responsecan only contain one DNS message. Future specifications might extend this protocol to support more meta-QTYPEs over HTTP; these are likely to require media types other than application/dns-message; so the content type of the response MAY depend on the OPCODE and QTYPE of the request. That last MAY is a biggie, I think, and probably needs to be mentioned prominently up front. Tony. -- f.anthony.n.finch http://dotat.at/ oppose all forms of entrenched privilege and inequality From nobody Thu Jun 7 05:41:01 2018 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 C087113111E for ; Thu, 7 Jun 2018 05:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQV2UhRWhcSi for ; Thu, 7 Jun 2018 05:40:50 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0107.outbound.protection.outlook.com [104.47.93.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1C413111C for ; Thu, 7 Jun 2018 05:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=APX7TIqxQaMtIfe4yW5IL2RhHUgGvlTlrhxC8O3A8MQ=; b=Ln8SGPo3vv32Bqp3L7rerzuZ0uN+c34MdQHIqsvClks/JWnWU4K11P99wY+QU6/i0gafvCRgjiSNtPkYGf96Ut6BvsmjRcoMpBz8qNLBZmMksprPL93xYjmXTFYS0wTlGtLRgmfD+bu1ADEJFVLRB0MtZj1kKsjVNhvuORHVoS8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [192.168.1.5] (220.108.140.211) by OSBPR01MB1542.jpnprd01.prod.outlook.com (2603:1096:603:3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Thu, 7 Jun 2018 12:40:46 +0000 To: bert hubert , Patrick McManus Cc: Paul Hoffman , DoH WG References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <527501e1-5a0e-fa58-9394-436daf88a77b@it.aoyama.ac.jp> Date: Thu, 7 Jun 2018 21:40:45 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180607093647.GB32326@server.ds9a.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [220.108.140.211] X-ClientProxiedBy: TYAPR01CA0106.jpnprd01.prod.outlook.com (2603:1096:404:2a::22) To OSBPR01MB1542.jpnprd01.prod.outlook.com (2603:1096:603:3::17) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:OSBPR01MB1542; X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1542; 3:a4i4FTQFovsQdgWUluqWwmirAd5xn9uDnUUZKyHCIN4iQBYyOU9UGwFcdAgU84agoRap7xw4Cok+H1HZljZEWNEwDEQo2aQkHz6PXAvAoT5ma3WDf31AIf6eHY5WTVE/kzD/hvh9SAbiJMSczZJ8FOL4TgNltTsbmlpWNrnRggn2B20n86Ho2doUd4jrTCJyjkmwDQNDx7+d6THGApSlNuXsvGnO/oyPOG0fAhs1K1qatyusoznfJ5T5L9C+iVki; 25:Gj13FzJcI6nXHEo8+mPyaMO8kugzvN8DF1Aj+ZyWWd97RAx6W5zxSSu785yvar8MnteVAXm/GNHgwnX+Gw+2I7jDXDVMiMU5v8z5m6pXC6YeZLBJqhV0FC0jgMxZGdWZhK9hO0xGWjoKyu6SCyUSSTQR6UDya5+gnI4mSTjNZMo5fU50F9aqMe8MDWkwc6O+SlqfW1Jp7d33b89UEMOlZIxkdPJ0QJrdvjhwDii+OT/YzhGEY9STuzr0yoaTVIy0/0INwvqbIXWv8KaLDIbqMEn0PmarGQdbLB3HcUWDxk60+3Agf2ePUYEFSz016LQ7vptiKqsAk7MKZbZzxjZB+w==; 31:2zx53Y3oZaJLcSzst5h6C3xOixBxQh/moANpSY6Y7BKx+MtE3nn9WKWKVRN3d/Ph3My5IhaCyc18gdx4w121v8frZj5VOOkVd7jJBkXmXznfMQTUuFoz+nQarRVxeEzo9kXW8Osa6k6LPHrYTVi75s8X+wrC8UqUQ4nvBrkcL7PKfId6AikZALpWAYVZcEEkmGJogQiexzMujcrJNIPx18qTEUTSsbGHoZRjbfRVBhw= X-MS-TrafficTypeDiagnostic: OSBPR01MB1542: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:OSBPR01MB1542; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB1542; X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1542; 4:112rqVnsAQNa9qTiIlHs8grln0XT1I3B/WM2SKzNH5ni5rDXaKJmskCUBeEiPbBvZYEY7pjiK2FHg1sK4nR0kedOlXl5QNkKcWjymMMWkA+6BESFyeMleh46XZMC9gdHy967ChJX23b9jyjrKgtVsE7CbmVcGQOiwOAW4/WszsB0djAuZojG7tL0CIKv7d/K/Xxemrd6rBDHfQ1d0NltXFhHU/AkoeAsXlEs5WEJZpp9d6RupQinHLnheSCJVnoNfRqbHQixDCAh0j1apVzxYg== X-Forefront-PRVS: 06968FD8C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(396003)(366004)(39840400004)(39380400002)(346002)(199004)(189003)(77096007)(3846002)(81156014)(81166006)(6116002)(26005)(65806001)(65956001)(31686004)(47776003)(8676002)(66066001)(68736007)(23676004)(229853002)(74482002)(65826007)(5660300001)(186003)(16526019)(106356001)(64126003)(50466002)(478600001)(230700001)(117156002)(105586002)(8936002)(2906002)(15650500001)(7736002)(2616005)(52116002)(25786009)(97736004)(305945005)(486006)(53936002)(956004)(11346002)(476003)(93886005)(4326008)(86362001)(6246003)(31696002)(59450400001)(67846002)(36916002)(386003)(53546011)(16576012)(316002)(786003)(110136005)(2486003)(54906003)(58126008)(76176011)(52146003)(446003)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSBPR01MB1542; H:[192.168.1.5]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU0JQUjAxTUIxNTQyOzIzOm5FcFFUWVpxcjN2ZHZKaXhtTkVVVVlFQmVm?= =?utf-8?B?M250Yi9KcklhdkxHRFdJbGl2YjlIU0JuMjN2NHF3YmlGREN1amZqaUlHRU5C?= =?utf-8?B?TDBOdmJ5SW5PNEZ4YWpYVDJSZVgxY3ZTaTQwK0tHMWl3aWtBQ3lCeG9zdjNm?= =?utf-8?B?TzludXpxdWk0Ymk5bjNLRWJnWVNSUDRVWUdGNjkvZm53djlnQXAzSGNYMlhr?= =?utf-8?B?MmJ1N3BDVzBEamhMS0ZDTmJuQjltOUZxTkg1bDFxTDJmZDBkY3lLajc3L3Vk?= =?utf-8?B?b3RGSjJrWGVzT3pXaE50bHRtMnVLaW9wa1VnWEM2NWRlUmhNMnFETWI3Wjdl?= =?utf-8?B?OTIvZGo3N21kWk54N1AvWk9QNzRVYTY1Sy9qTTZZdFNnN08zb01abEh3dThs?= =?utf-8?B?cXBTdU1nbXlBcDB4V0VYc0JYajE2bWxleGtBZ2lMbTIvL1JkS2ZrOGNOeGl5?= =?utf-8?B?MkNnaTkzekdWSXdob0tiblEzbjhtVGc3RW5WZ09Rc21yQzkrYnVWNkg3cHlS?= =?utf-8?B?TzgyMDBmdFJRUGVXdWRZNzNYRzRtNGdvSC9RUVJqT25waDhhTDF5eVc0YnlL?= =?utf-8?B?dEt0Syt5RkZCT1lMR2I4dzdjYzJKZjRQanc0d2pPcGVXNmJDblJFN1hKTXJ3?= =?utf-8?B?ZFJFb2RwMHJZWkNNQktxcytWQVdobXBTazVmSWloSEUyb2U2YkdVelFDejR0?= =?utf-8?B?TzVsRVAwemdVK0czTzlSZE9nV0p4bmVGbDBtcjhOS1hQMU16M0Z0b3MyWE9h?= =?utf-8?B?THlMRTdPRUhHREZLMlUwNFhNU2JpZ09hbVFmL0J0SlJyT2djSmFDcGR3RlVD?= =?utf-8?B?M3JQVDd2TWNFa1NOSW1CTEFaS0I4NXFibVRwOVVYckMxVEcvTnNHUS9sTzhj?= =?utf-8?B?OWU4eDMzamhuUjRsTXdFMWVTa054VXZSZHk2SFNrWkZEK05ZMXNyK1V0SHRB?= =?utf-8?B?SEkrTmJIRDhTYzRSSkVjb0NHZ3p5NExjaEYzVm9yM1oyaVA4Vk94OEdTR1Jr?= =?utf-8?B?R0dTYWFUcEd5SjVGcTBQdEorZ1hubWtSUjNYTWkvSzIxbkFEdGFPQXJhNXQx?= =?utf-8?B?ZFVZRDhOak5taWVBb3lRc3N0ZGpHYlk2RXcvVTBTQlk4YnlHZ2ZhaGZ5cWxj?= =?utf-8?B?a0k4OUYzd2x6VEhhaWlIcktxN3F6bDNNbG1GZStrMDNuQmZBQnVIOWw3UWJh?= =?utf-8?B?VzMrQ25mSmRKenVDdHgwYWVOR0txZFA1d3ZicS9peXpTWTZTQ1VvS2IyOEJp?= =?utf-8?B?VFNxbHN2T3ByNTBKbG5ZRUR5UjJyUzhUT0VBc3d1NUV0ai84UzVpTXphR3VS?= =?utf-8?B?NnZLLzJLM0VZdW9iMGpYTC91MFNFWm1tbnhaQmRDa1N0bmJaNngvSVJqTk11?= =?utf-8?B?cjVKT1orblByYUxkTVBuWktHTlh2V2NOSndmL0xmQ2dROXlTQlk3a0FtNVFI?= =?utf-8?B?bTFpa2s4ZGxVTDdma3VJNjRkK0ZobzNaT1B2Zkd1MG1pV3J3WTV4bXR5RUhz?= =?utf-8?B?cWhoVXpsQTR2cDdSd01MRllKQ1VLRndmYlY0bkplcHA5UEFCb2xDamtLUFZV?= =?utf-8?B?WHhMNURZYWhwYklVeDNxeXVFdG5tT0NKMmt0ZkF3NjFhdFhUSXhzbVM1R1BZ?= =?utf-8?B?cVJVRWpGN1JIa0V3TmZkTXorc2FrcGtGR3VYbStpcWlHc1pGN0h4ZkpBM2E5?= =?utf-8?B?UDdydWl1eDE5T0svN3RNd3BaQ3dLMWFHeDN3eG1qbGx0NHRHaXkrRFZtYTNM?= =?utf-8?B?c1BXWkM5dXhHTlk0UW9XWi9Da2RyWVNKS2RtdTNhS1RDTEt3NTM4M2l4NFI3?= =?utf-8?B?M3A0VXdlMkJtV1lDZkVKSENQaFIyN2p5c3FnSmRScTVwRmR0by9wUnlKU0RS?= =?utf-8?B?eWxPNTkxbVhWY3VkMjVyL3Q3L3pyYzhvZ1grYkxJekNwbmFhQmorUUhpVUlk?= =?utf-8?B?eTBnbmc2YWpKZ0ozWnlPK2xIbWpPN3NBVCtOK1NvQmMwVUVCYW9ZVjk0dU8v?= =?utf-8?B?cE1EZjFKaUlYVS9mZEtmRlo3KzdCQlh2OUZFSlVDSng3OUdpUDVTQlpjQUVa?= =?utf-8?B?am1GRDUrTTBkWXR4SGFwTUo2a2U1RnFobFlyemF5dnhNbUZud2FVK0VkbWND?= =?utf-8?Q?MQV9tJhzMCyyVVdZ+1oXYnA=3D?= X-Microsoft-Antispam-Message-Info: y9OpILFv2dTVd+BXycMrGu7U1TG43ieOefB/scVyn29G1lKbVSFIWTmI+DXwKWFpnIcY+9wx7ZNhca5f7lvL0/FpZmdiw5/orJbfFK5z80tFPt64J0xWFxi14I1sEDnagEaxOC4JfcbUBfIUi6CR+G2ahp5ESm/YVwRjAuUqlQGxlFF/4OdpB1remM+3bLmo X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1542; 6:JbWFzLukr9h6k71YTTBWfrVHhmMMiSTF6xr3DFtm55hM0ZHJWmfvkImkpSeS5OKugPwNSGa/x5gSj3zg+Lsi4NB5fa09JLmrRwBUot53v900cSMS4++3Ev+yqr3LTXVwuH62f9QTlAzOFArBYxTLjvfv77kV2riKDXxQXbIj/uMyupM/h8XYBMnoFajb6RR7293A8v6Ot+de2cFL5jui7RvLb4HVpFyPKuCkaazSbNe0Z2KpRu1wO9g9B8FuZuqWzwmWbbMLUpfTTP5koKxpBslHzTSQGLhJoDeNbTw/eRxyr5N2+fLHIF91O3YfBKS+pc5eDVaovK3BDs2qRTNJqiTUgwQqTSdgyZgcDDM9g5cdqwanwhux11hzAM7a91ejsIIi9KQi5wWbhRePaxbeYGqssYKprj82sJfcEgEpmcaCHK6iryNqWgbYJ+FI2u7KzLyO/Ya7HXCq2OjSUmSTRA==; 5:ebtVZArvR6G2IrRX9pgZ9gimHJRMJQp6KzkoVmCez2yiO5NKEPvk5tmrVxjj7Cnvr7kfbJyCgvilK7YbfB40I0qKOf+W4vmXIoI3iCrMyTTGWeDoR1BQ9hbOimz2UAC7A972m6QwqHx4dgNAk6RFaDwXuKHvpg2QAQT/BiryaY4=; 24:ZnQyTzVRRPM7scfPgO93X47OBtehns2XBKkZ4nvcx7Pj9eiIlOpeA15MRtuOPWtNjkaXgBTkz2DwoYZFYHgFou2Pktf8isz2f+zOVeDFDNs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OSBPR01MB1542; 7:s8Xwd509nX59DGmOl+E8kFsxjJkcuIt91zA0UTmbTXWLnBpVMIeQrB09BIv4UaKYei7nJAYCMdXzZ+bfKcL/p7oLxh5xiQ+7sgbsU3bRKMopD4UoeW+FFUamrm8daKdHu1HiEWgZZBZxYDZEwG4mx6XrNidJ8SAeol73nsTXnZ8A4y1kenpzfnqSbhrbZAzGbjI/NcMuVA0/f8TWue5mK5Xi/weVzYn8kqjjxjbAg18KQVYrQXO9UZynzWCUjFro X-MS-Office365-Filtering-Correlation-Id: 6736f301-72eb-432d-ad6c-08d5cc73e4bf X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2018 12:40:46.9792 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6736f301-72eb-432d-ad6c-08d5cc73e4bf X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB1542 Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 12:40:56 -0000 Hello Bert, On 2018/06/07 18:36, bert hubert wrote: > On Thu, Jun 07, 2018 at 09:19:06AM +0200, Patrick McManus wrote: >> it seems possible that this is a property of the default media type not of >> DoH. e.g. a negotiated json response wouldn't have this kind of limitation. >> Does that make sense? > > Firstly, it is not a media type limitation. It is a question of if we want > to extend DNS into a territory where it has never been before. The moment > 100 kilobyte DNS answers become possible, we need to redo a ton of software. > This is true if the end transport is JSON or a DNS message wrapped into an > HTTP response. I think I agree with Patrick that it is a media type limitation. I might be wrong, but I don't see a way for a JSON-based format to be as efficient as the binary DNS format(s). Even if it were possible, a JSON format could contain lots of additional spaces without changing the meaning of the message at all. So for a JSON message, there's not limit of 64K on the actual message length. But there is (or should be) an *indirect* limitation that can roughly be expressed as "a JSON message, when converted to a binary format, has to fit into 64K". > Before typing a lot more characters on this, can I ask who is actually > arguing that we need bigger DNS messages? Who is hurting under the 65536 > byte constraint? DNS over HTTPS implies that we have access to HTTPS. This > protocol supports messages as large as you want. > > The one reason you might like DNS to be able to do something new and large > is because you might have no alternate way of getting large data. > > So I ask, who wants to fundamentally extend the DNS protocol with messages > of a size never seen or supported? Who is the customer? Not me, at least not for now. Regards, Martin. From nobody Thu Jun 7 06:40:36 2018 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 9055E1310CD for ; Thu, 7 Jun 2018 06:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 e6gPl9jgyyKl for ; Thu, 7 Jun 2018 06:40:31 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 6E14A1310CC for ; Thu, 7 Jun 2018 06:40:31 -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; Thu, 7 Jun 2018 06:40:29 -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; Thu, 7 Jun 2018 06:40:29 -0700 From: Paul Hoffman To: Tony Finch CC: DoH WG Thread-Topic: [Doh] [Ext] DNS Camel thoughts: TC and message size Thread-Index: AQHT/kr9sCZvhcrcI0uOMRalB8RQXqRVQvMA Date: Thu, 7 Jun 2018 13:40:29 +0000 Message-ID: <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> References: <20180606093212.GA23880@server.ds9a.nl> In-Reply-To: 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: <3FFB04715D0BD842BDF0E10BB764A4F5@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 13:40:33 -0000 On Jun 7, 2018, at 3:33 AM, Tony Finch wrote: >=20 > Paul Hoffman wrote: >>=20 >> DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC >> 7766. Unless I'm missing something, neither of those document support >> the 65535 length restriction; >=20 > The restriction comes from the 2 octet message length field, RFC 1035 > section 4.2.2. Ow! (I just slammed my forehead into the desk because this should have been= obvious to me.) Tony is completely correct here. DNS messages have well-defined length limi= ts: 512-or-more-depending if carried over UDP, and 65535 if carried over TC= P. Bert's proposal is fine with me. The fact that RFC 7766 didn't mention this= limitation doesn't change anything. > EDNS buffer sizes need to be handled the samee as for TCP as well. RFC 6891 says that the payload size is for transport over UDP, not TCP. Wha= t change are you requesting here? --Paul Hoffman= From nobody Thu Jun 7 06:48:22 2018 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 291E1130F1F for ; Thu, 7 Jun 2018 06:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vLmoypZMo8AZ for ; Thu, 7 Jun 2018 06:48:15 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 C0A98130F01 for ; Thu, 7 Jun 2018 06:48:15 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:49770) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fQvGw-000HBX-12 (Exim 4.91) (return-path ); Thu, 07 Jun 2018 14:48:14 +0100 Date: Thu, 7 Jun 2018 14:48:14 +0100 From: Tony Finch To: Paul Hoffman cc: DoH WG In-Reply-To: <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> Message-ID: References: <20180606093212.GA23880@server.ds9a.nl> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 13:48:20 -0000 Paul Hoffman wrote: > > > EDNS buffer sizes need to be handled the samee as for TCP as well. > > RFC 6891 says that the payload size is for transport over UDP, not TCP. > What change are you requesting here? An explicit note that it doesn't apply to HTTP either. Maybe that is obvious enough from RCF 6891 that it doesn't need restating? Tony. -- f.anthony.n.finch http://dotat.at/ partnership and community in all areas of life From nobody Thu Jun 7 06:51:41 2018 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 9380E13112D for ; Thu, 7 Jun 2018 06:51:37 -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 ZiMfbhuKKE0c for ; Thu, 7 Jun 2018 06:51:34 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D18E13112A for ; Thu, 7 Jun 2018 06:51:34 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 7 Jun 2018 06:51:32 -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; Thu, 7 Jun 2018 06:51:32 -0700 From: Paul Hoffman To: Tony Finch CC: DoH WG Thread-Topic: [Doh] [Ext] DNS Camel thoughts: TC and message size Thread-Index: AQHT/kr9sCZvhcrcI0uOMRalB8RQXqRVQvMAgAACLACAAADrgA== Date: Thu, 7 Jun 2018 13:51:31 +0000 Message-ID: <1525C798-A267-492A-8B21-FE3D02A15415@icann.org> References: <20180606093212.GA23880@server.ds9a.nl> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> In-Reply-To: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 13:51:38 -0000 On Jun 7, 2018, at 6:48 AM, Tony Finch wrote: >=20 > Paul Hoffman wrote: >>=20 >>> EDNS buffer sizes need to be handled the samee as for TCP as well. >>=20 >> RFC 6891 says that the payload size is for transport over UDP, not TCP. >> What change are you requesting here? >=20 > An explicit note that it doesn't apply to HTTP either. Maybe that is > obvious enough from RCF 6891 that it doesn't need restating? Ah, *doesn't apply*. Sure, if we're adding a note with the max length, this= clarification is probably good as well. --Paul Hoffman= From nobody Thu Jun 7 07:17:39 2018 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 B237B130EF1 for ; Thu, 7 Jun 2018 07:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 B7CFSR_tujSP for ; Thu, 7 Jun 2018 07:17:33 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB0130EF7 for ; Thu, 7 Jun 2018 07:17:33 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id 662FB3A05A for ; Thu, 7 Jun 2018 10:17:32 -0400 (EDT) Received: by mail-oi0-f48.google.com with SMTP id f79-v6so8752496oib.7 for ; Thu, 07 Jun 2018 07:17:32 -0700 (PDT) X-Gm-Message-State: APt69E1UIhDRS3fjjVi7lGm738WSQBHims+5dTkPU3nupw3qdaRL3W1G UpTlwS7tm5qWOrVT0NaGIa8KhyD7MgUMYZ78+Lw= X-Google-Smtp-Source: ADUXVKLb31vnsmsHyB+KGEThe9gITbr5ACWycblc9ZDpSUXVzZrDs88gVhLlmkJr/oLxpDHao98ZyTXw/DGQIwuUcmc= X-Received: by 2002:aca:f3c5:: with SMTP id r188-v6mr676260oih.17.1528381052138; Thu, 07 Jun 2018 07:17:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 07:17:31 -0700 (PDT) In-Reply-To: <20180607093647.GB32326@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> From: Patrick McManus Date: Thu, 7 Jun 2018 16:17:31 +0200 X-Gmail-Original-Message-ID: Message-ID: To: bert hubert Cc: Patrick McManus , Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="000000000000b1c771056e0df174" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 14:17:36 -0000 --000000000000b1c771056e0df174 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 7, 2018 at 11:36 AM, bert hubert wrote: > On Thu, Jun 07, 2018 at 09:19:06AM +0200, Patrick McManus wrote: > > it seems possible that this is a property of the default media type not > of > > DoH. e.g. a negotiated json response wouldn't have this kind of > limitation. > > Does that make sense? > > Firstly, it is not a media type limitation. It is a question of if we want > to extend DNS into a territory where it has never been before. The moment > 100 kilobyte DNS answers become possible, we need to redo a ton of > software. > This is true if the end transport is JSON or a DNS message wrapped into an > HTTP response. > > I still think that your argument only applies to the *wireformat media types. New types mean new parsers. It seems your concerns are about existing parsers that, by definition, can't parse the new types. So I'm not concerned about them with new types. > Before typing a lot more characters on this, can I ask who is actually > arguing that we need bigger DNS messages? Who is hurting under the 65536 > byte constraint? DNS over HTTPS implies that we have access to HTTPS. > This > protocol supports messages as large as you want. > > I don't want to constrain what those new types might do based on our current understanding. For instance some media types might be very space inefficient but super efficient to access.. and we might fix that on the wire with a http compression encoding. heck maybe they come back as jpeg visualizations; I'm not here to judge. If we buy my argument then we don't so much as restrict DoH as note that the wireformat media types effectively have this limitation already that needs to be respected. --000000000000b1c771056e0df174 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 7, 2018 at 11:36 AM, bert hubert <bert.hubert@powerdns.com<= /a>> wrote:
On Thu, Jun 0= 7, 2018 at 09:19:06AM +0200, Patrick McManus wrote:
> it seems possible that this is a property of the default media type no= t of
> DoH. e.g. a negotiated json response wouldn't have this kind of li= mitation.
> Does that make sense?

Firstly, it is not a media type limitation. It is a question of if w= e want
to extend DNS into a territory where it has never been before. The moment 100 kilobyte DNS answers become possible, we need to redo a ton of software= .
This is true if the end transport is JSON or a DNS message wrapped into an<= br> HTTP response.


I still think that your argument only = applies to the *wireformat media types.

New types = mean new parsers. It seems your concerns are about existing parsers that, b= y definition, can't parse the new types. So I'm not concerned about= them with new types.
=C2=A0
Before typing a lot more characters on this, can I ask who is actually
arguing that we need bigger DNS messages?=C2=A0 Who is hurting under the 65= 536
byte constraint?=C2=A0 DNS over HTTPS implies that we have access to HTTPS.= =C2=A0 This
protocol supports messages as large as you want.


I don't want to constrain what those ne= w types might do based on our current understanding. For instance some medi= a types might be very space inefficient but super efficient to access.. and= we might fix that on the wire with a http compression encoding. heck maybe= they come back as jpeg visualizations; I'm not here to judge.

If we buy = my argument then we don't so much as restrict DoH as note that the wire= format media types effectively have this limitation already that needs to b= e respected.


--000000000000b1c771056e0df174-- From nobody Thu Jun 7 09:54:29 2018 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 3C640130F62 for ; Thu, 7 Jun 2018 09:54:27 -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 cT3ekYhb2Hgr for ; Thu, 7 Jun 2018 09:54:18 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DD2130F5E for ; Thu, 7 Jun 2018 09:54:17 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 803E1299B2; Thu, 7 Jun 2018 12:54:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23321.25400.502754.584769@gro.dd.org> Date: Thu, 7 Jun 2018 12:54:16 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> References: <20180606093212.GA23880@server.ds9a.nl> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 16:54:27 -0000 Paul Hoffman writes: > Tony is completely correct here. DNS messages have well-defined > length limits: 512-or-more-depending if carried over UDP, and 65535 > if carried over TCP. Right. And completely undefined over any other transport. There is no intrinsic limit to the limit of a DNS message, compression pointers notwithstanding. I could give you a parser that would happily churn though a multi-megabyte DNS message. I was among the first advocating for making it clear that there needn't be an unnecessary limit imposed here, and I still stand by my position though at the moment it looks like I'll end up on the wrong side of consensus. My point is that when there is not a strict technical need driving some limit, I don't think it should be there. Have we learned nothing of scaling on the Internet over all these years? While "existing DNS message parsers might have a problem with it" is a legitimate potential issue, I don't see it as a compelling need to drive the requirement. It isn't even a given that all existing parsers would have a problem with it. In any event that's something that should be looked at by the programmer before just blindly pumping data through. There's even a use case for going beyond 64k, AXFR. Despite Tony's other message claiming that AXFR needs multiple messages, that's not fully accurate. I have plenty of zones that fit in a single DNS/TCP message when sent over AXFR, and DNS/HTTPS would cover the rest quite easily, except with a restriction on message lengths it actually makes things a bit more complicated. I will readily admit that I personally don't currently have a plan to start doing AXFR over DoH. My point is that this isn't just purely academic, but actually has some practical applications. My personal take is that, given that there is no strict technical limit for imposing a limit inside a transport that doesn't require it, the existing "any size" text should remain, and be augmented with a warning to developers about how that could be an issue with existing code that assumes no message can be greater than 64k based on earlier transport definitions. From nobody Thu Jun 7 09:58:07 2018 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 1E2DE130F73 for ; Thu, 7 Jun 2018 09:58:05 -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 p-6oCnequq6T for ; Thu, 7 Jun 2018 09:58:03 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10671130F5E for ; Thu, 7 Jun 2018 09:58:03 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 515EA299BB; Thu, 7 Jun 2018 12:58:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23321.25626.316926.975797@gro.dd.org> Date: Thu, 7 Jun 2018 12:58:02 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: References: Archived-At: Subject: Re: [Doh] special meta QTYPEs X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 16:58:05 -0000 Tony Finch writes: > I don't think it's possible to fit AXFR or IXFR into > DoH because their responses involve multiple DNS messages. Adding my comment about *XFR from a different thread to this thread too, for tracking. Strictly speaking, that's not fully accurate. I have plenty of zones that fit in a single DNS/TCP message when sent over AXFR, and DNS/HTTPS would cover the rest quite easily if left in its current form. Adding a restriction on message lengths would make this more complicated. From nobody Thu Jun 7 10:21:35 2018 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 A9172130F75 for ; Thu, 7 Jun 2018 10:21:31 -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 YvaF3tEKl3HW for ; Thu, 7 Jun 2018 10:21:23 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64D013113F for ; Thu, 7 Jun 2018 10:21:23 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 17E38299D7; Thu, 7 Jun 2018 13:21:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23321.27027.73356.94056@gro.dd.org> Date: Thu, 7 Jun 2018 13:21:23 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 17:21:32 -0000 Bert: > Before typing a lot more characters on this, can I ask who is actually > arguing that we need bigger DNS messages? Who is hurting under the 65536 > byte constraint? Me, and not me. The two questions are orthogonal. Tautologically, putting in limits results in limits -- limits on what could be built if the limits were not in place. I'm personally not particularly hurting right now, though I do know of some people who are in fact having trouble with large zone transfers that could be ameliorated with HTTPS restarts (or, of course, by shoehorning some other data transfer method in). Beyond pain, I can't really tell you what interesting applications that would us a hierarchically distributed public database are going uninvented because of the existing limits. Give people more powerful tools and they can build more powerful things. Patrick: > I don't want to constrain what those new types might do based on our > current understanding. For instance some media types might be very > space inefficient but super efficient to access.. and we might fix > that on the wire with a http compression encoding. heck maybe they > come back as jpeg visualizations; I'm not here to judge. Exactly. > If we buy my argument then we don't so much as restrict DoH as note > that the wireformat media types effectively have this limitation > already that needs to be respected. "Sort of". Wire format itself does not have the limitation. Its use on certain transports does. This distinction needs to keep being made. From nobody Thu Jun 7 14:21:25 2018 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 4B4F6130FD0 for ; Thu, 7 Jun 2018 14:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 1QQ5Azw8N8Ax for ; Thu, 7 Jun 2018 14:21:15 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBAA130FB7 for ; Thu, 7 Jun 2018 14:21:14 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:51801 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fR2LF-0002JO-PI (Exim 4.72) for doh@ietf.org (return-path ); Thu, 07 Jun 2018 22:21:09 +0100 To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> From: Ray Bellis Message-ID: <62644ffc-b403-3e14-72b7-7721b5713c1c@bellis.me.uk> Date: Thu, 7 Jun 2018 22:21:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:21:22 -0000 On 06/06/2018 23:42, Paul Hoffman wrote: > Similarly, there is no restriction on the total length of a TXT > record. Yes, there is. Every RR is constrained in size by the 16 bit RDLENGTH field. Ray p.s. count this as another vote for requiring the DOH limit to be 65535 (when represented in binary format) From nobody Thu Jun 7 14:23:54 2018 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 8BE86130EC7 for ; Thu, 7 Jun 2018 14:23:51 -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 RA3kI9Heyuwx for ; Thu, 7 Jun 2018 14:23:48 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1553130DD6 for ; Thu, 7 Jun 2018 14:23:47 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:51844 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fR2Nj-0002Mf-E2 (Exim 4.72) for doh@ietf.org (return-path ); Thu, 07 Jun 2018 22:23:43 +0100 To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> From: Ray Bellis Message-ID: <29813ef9-1b16-e84b-10dd-8103cb34b820@bellis.me.uk> Date: Thu, 7 Jun 2018 22:23:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:23:52 -0000 On 06/06/2018 23:42, Paul Hoffman wrote: > I hear a lot of support for Bert's wording: > Specify that DNS messages carried over > DOH can be up to 65536 bytes large and note that truncation should be > handled as if the response was carried over TCP/53. NB: that's up to but *not including* 65536. UDP packets and TCP-framed DNS messages both have a 16 bit length field with a maximum value of 65535. In fact for UDP the actual DNS payload size is smaller, because that 65535 has to include the 8 byte UDP header. Ray From nobody Thu Jun 7 14:31:59 2018 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 C5CE4130FD0 for ; Thu, 7 Jun 2018 14:31:56 -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 IJmua_9Pnccb for ; Thu, 7 Jun 2018 14:31:55 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9CB130FCE for ; Thu, 7 Jun 2018 14:31:55 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:51979 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fR2Va-0002bZ-Jn (Exim 4.72) for doh@ietf.org (return-path ); Thu, 07 Jun 2018 22:31:50 +0100 To: doh@ietf.org References: <20180605120510.GA29047@server.ds9a.nl> <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> From: Ray Bellis Message-ID: <9b4abad9-5fdb-22cd-4ad4-eb4f9ca6b520@bellis.me.uk> Date: Thu, 7 Jun 2018 22:31:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <663E7B21-9107-4A2B-9DEB-E13475A4E5FF@icann.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] a tad confused on response sizes X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:31:57 -0000 On 05/06/2018 15:48, Paul Hoffman wrote: > In both cases, the TC bit means "here's the best I got". 'Twas always thus. There's a school of thought that says a TC response should contain the absolute bare minimum, per RFC 6891, i.e. the question section, an OPT RR if there was one in the original query, and *nothing else*. Ray From nobody Thu Jun 7 14:39:25 2018 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 8CED2130DD1 for ; Thu, 7 Jun 2018 14:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 0OFl_h5N8cay for ; Thu, 7 Jun 2018 14:39:19 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id AA77F130DD4 for ; Thu, 7 Jun 2018 14:39:19 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id F2E263A066 for ; Thu, 7 Jun 2018 17:39:16 -0400 (EDT) Received: by mail-oi0-f51.google.com with SMTP id l22-v6so10020700oib.4 for ; Thu, 07 Jun 2018 14:39:16 -0700 (PDT) X-Gm-Message-State: APt69E0U68hOSiZY4acmA/vqReyz4T1Uo3DkUEJGcKbHh1pLVGMoi3UD F1FLbrhIgpb98/G9MYUY3M+n2H0uvbKnIihn0tU= X-Google-Smtp-Source: ADUXVKJpNNXNiknEyAeCL2nzAhsezfqhB6FRv6TP3pQuBvoGbXshadr5a33wApEERzLJhyixOR0oqk1Gwzxc99iRi0c= X-Received: by 2002:aca:5a44:: with SMTP id o65-v6mr1769041oib.155.1528407556710; Thu, 07 Jun 2018 14:39:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 14:39:16 -0700 (PDT) In-Reply-To: <23321.27027.73356.94056@gro.dd.org> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> From: Patrick McManus Date: Thu, 7 Jun 2018 23:39:16 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Dave Lawrence Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000007d67a7056e141df8" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:39:22 -0000 --0000000000007d67a7056e141df8 Content-Type: text/plain; charset="UTF-8" > > "Sort of". Wire format itself does not have the limitation. Its use > on certain transports does. This distinction needs to keep being > made. > > tale has convinced me of this point. --0000000000007d67a7056e141df8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


"Sort of".=C2=A0 Wire format itself does not have the limi= tation.=C2=A0 Its use
on certain transports does.=C2=A0 This distinction needs to keep being
made.

<= br>
tale has convinced me of this point.

--0000000000007d67a7056e141df8-- From nobody Thu Jun 7 14:48:19 2018 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 C3719130DD4 for ; Thu, 7 Jun 2018 14:48:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=Y1MJs++V; dkim=pass (1024-bit key) header.d=yitter.info header.b=eWdY/F84 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 DhV89X4TeTFR for ; Thu, 7 Jun 2018 14:48:12 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DAD130DD1 for ; Thu, 7 Jun 2018 14:48:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 17279BDEF9 for ; Thu, 7 Jun 2018 21:47:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528408061; bh=HrICC6qIQYCqUv3fAZ3XVyEKqnMSbXkbwYyYPi643P8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Y1MJs++VWlvJHB2c0x3I/qCvtxmwPrzYWjdxBu6gDa67brCVjO8uIcdyHbcVHSFrw oBcAi0S2rZaP81bNYEGJGqTBvlnRRANGtA41ij6RJQeno9RjESb3jfCnnZbFuMsfNY XdEJs1JRRmbx4cBGxTwgftbibXjWgwSrpgvq9FbA= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y46rbYgOd8nq for ; Thu, 7 Jun 2018 21:47:40 +0000 (UTC) Date: Thu, 7 Jun 2018 17:47:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528408059; bh=HrICC6qIQYCqUv3fAZ3XVyEKqnMSbXkbwYyYPi643P8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=eWdY/F84U/zZp5DkoB1vxNrWPDT1yZJSBanNUYD6tur1ICY5Y1hIvWVN4brg3Zo4F T+U78azAufsy6ns+hTBOpSmcQCGZrDEdeLW2vVWngNqsSQ1qL4WrUM334pjCDIRdqr jJe4UpMoaLAQ85tQbh4Dzsw0Ld/fZIfC8Ey9p3AU= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180607214737.GP11227@mx4.yitter.info> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23321.27027.73356.94056@gro.dd.org> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:48:17 -0000 On Thu, Jun 07, 2018 at 01:21:23PM -0400, Dave Lawrence wrote: > > "Sort of". Wire format itself does not have the limitation. Its use > on certain transports does. This distinction needs to keep being > made. That sounds like a foot-gun loaded for bear, to me. Wire format on every transport so far has this limitation. Even if you break that limitation (and I'm still not fully convinced you can), the mere fact that this is called the "wire format" will lead people to expect that they can pop in the very same parsing code they already use for the "traditional" wire format, and it'll work fine. So, if the document is not going to set the limit in concrete, it had better have a Big Giant Warning section that points out that a completely reasonable assumption is not true and that the competent implementer will have to do a bunch of additional work to be safe in a corner condition that is incredibly rare right now. What will actually happen, of course, is that some programmer will say, "Aw, nobody's going to do that," fail to check the bounds carefully, and create some festering large problem somewhere down the road. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jun 7 14:59:00 2018 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 156D2130FAC for ; Thu, 7 Jun 2018 14:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 n6LqQaCNscQ3 for ; Thu, 7 Jun 2018 14:58:56 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939BE130DDB for ; Thu, 7 Jun 2018 14:58:56 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id CE4D29FB55; Thu, 7 Jun 2018 21:58:51 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 433FBAC5B1B; Thu, 7 Jun 2018 23:58:51 +0200 (CEST) Date: Thu, 7 Jun 2018 23:58:51 +0200 From: bert hubert To: Patrick McManus Cc: Dave Lawrence , DoH WG Message-ID: <20180607215851.GA32738@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 21:58:58 -0000 On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote: > > "Sort of". Wire format itself does not have the limitation. Its use > > on certain transports does. This distinction needs to keep being > > made. > tale has convinced me of this point. In the interest of reaching consensus, can we park this discussion until another message type is invented and standardised that is not a DNS message in "wire format"? Whenever we make life harder on the whole DNS implementation community, we had better have a very good reason for that. To put it bluntly, a significant part of the DNS implementation community (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit is here to stay for now, so I don't see a viable consensus for expanding DNS - especially given the lack of concrete usecases. Finally, I note that the DOH charter contains the following: "The working group will coordinate with the DNSOP and INTAREA working groups for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics, respectvely. In particular, DNSOP will be consulted for guidance on the operational impacts that result from traditional host behaviors (i.e., stub-resolver to recursive-resolver interaction) being replaced with the specified mechanism. Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group." It may be good to point out that 'normal DNS queries' have never involved getting >64KB responses. We might also have to consult DNSOP about changing DNS semantics, an activity they aren't stimulated to explore. Finally, I do really understand how much fun it would be to liberate DNS from its pedestrian 64KB shackles. It is an arbitrary limitation, and perhaps one day we'd love to put gigantic post-quantum cryptographical keys in DNS. But given the amount of developer cycles in DNS, please also understand my (our) reticence in overhauling this ancient protocol. Bert From nobody Thu Jun 7 18:49:35 2018 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 CC073130E02 for ; Thu, 7 Jun 2018 18:49:33 -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 hJX-5Yz3qmKs for ; Thu, 7 Jun 2018 18:49:32 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB7612F1A6 for ; Thu, 7 Jun 2018 18:49:32 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 6513829BB8; Thu, 7 Jun 2018 21:49:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23321.57515.396358.24195@gro.dd.org> Date: Thu, 7 Jun 2018 21:49:31 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <20180607214737.GP11227@mx4.yitter.info> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607214737.GP11227@mx4.yitter.info> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 01:49:34 -0000 Andrew Sullivan writes: > So, if the document is not going to set the limit in concrete, it > had better have a Big Giant Warning section that points out that a > completely reasonable assumption is not true Yes, I think that either way there should be more of an explanation of what's going. From nobody Thu Jun 7 19:09:48 2018 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 13D3F130E0D for ; Thu, 7 Jun 2018 19:09:46 -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 CJwmdNiQANvW for ; Thu, 7 Jun 2018 19:09:45 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D5112F1A6 for ; Thu, 7 Jun 2018 19:09:45 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 3A8C829BCB; Thu, 7 Jun 2018 22:09:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23321.58728.220321.285973@gro.dd.org> Date: Thu, 7 Jun 2018 22:09:44 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <527501e1-5a0e-fa58-9394-436daf88a77b@it.aoyama.ac.jp> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <527501e1-5a0e-fa58-9394-436daf88a77b@it.aoyama.ac.jp> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 02:09:46 -0000 Martin J. D=FCrst writes: > So for a JSON message, there's not limit of 64K on the actual message= =20 > length. But there is (or should be) an *indirect* limitation that can= =20 > roughly be expressed as "a JSON message, when converted to a binary=20= > format, has to fit into 64K". If I understand correctly, you are saying that it is a better state of affairs to require servers to be cognizant of the encoding size of one media type when responding with another=3F I'm having a hard time seeing how this wouldn't mean having to at least sometimes do the work of fully encoding it in the one before it can send it in the other. Incidentally, this has raised another question in my mind. In a defined-limit world, what happens when some rogue DoH server generates Content-Length > 64k=3F Presumably well-behaved clients will be sanity= checking for the possibility of that. In a Content-Length: unlimited world you are still free to consider > 64k responses to have failed until you get around to adapting your software. It seems to me you're no worse off for being forward-looking now. From nobody Thu Jun 7 19:45:24 2018 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 E0AD2130E13 for ; Thu, 7 Jun 2018 19:45:19 -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 PwpW8jfMrqG8 for ; Thu, 7 Jun 2018 19:45:17 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32BB130E15 for ; Thu, 7 Jun 2018 19:45:16 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id C620512C1D14; Thu, 7 Jun 2018 22:45:15 -0400 (EDT) Date: Thu, 7 Jun 2018 22:45:15 -0400 From: Robert Edmonds To: Dave Lawrence Cc: DoH WG Message-ID: <20180608024515.jkimytwch7lstkxi@mycre.ws> References: <20180606093212.GA23880@server.ds9a.nl> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> <23321.25400.502754.584769@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23321.25400.502754.584769@gro.dd.org> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 02:45:20 -0000 Dave Lawrence wrote: > Paul Hoffman writes: > > Tony is completely correct here. DNS messages have well-defined > > length limits: 512-or-more-depending if carried over UDP, and 65535 > > if carried over TCP. > > Right. And completely undefined over any other transport. There is > no intrinsic limit to the limit of a DNS message, compression pointers > notwithstanding. No, there is an intrinsic limit to the size of a DNS message. If I'm not mistaken: 12 octets header 1 question resource record: 255 octets QNAME 2 octets QTYPE 2 octets QCLASS 3 response sections: 65535 RR's per section: 255 octets NAME 2 octets TYPE 2 octets CLASS 4 octets TTL 2 octets RDLENGTH 65535 octets RDATA 12 + 1*(255+2+2) + 3*65535*(255+2+2+4+2+65535) = 12936609271 octets, or, about 13 gigs. -- Robert Edmonds From nobody Thu Jun 7 20:01:28 2018 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 11FDB130E13 for ; Thu, 7 Jun 2018 20:01:26 -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 UoCxDvYDeORZ for ; Thu, 7 Jun 2018 20:01:24 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C8E130DFD for ; Thu, 7 Jun 2018 20:01:24 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id B961D29BE6; Thu, 7 Jun 2018 23:01:23 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23321.61827.730086.802766@gro.dd.org> Date: Thu, 7 Jun 2018 23:01:23 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <20180607215851.GA32738@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 03:01:26 -0000 bert hubert writes: > especially given the lack of concrete usecases. I would characterize "being able to fit a whole AXFR" as a concrete use case, especially given that it is data already carried by the DNS and is simpler to implement in a world where it doesn't have to be chunked. From nobody Thu Jun 7 20:03:41 2018 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 84DF1130E13 for ; Thu, 7 Jun 2018 20:03:39 -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 0Q3bpHLR02tO for ; Thu, 7 Jun 2018 20:03:38 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B31130DFD for ; Thu, 7 Jun 2018 20:03:38 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id A13B529BEA; Thu, 7 Jun 2018 23:03:37 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23321.61961.643620.25255@gro.dd.org> Date: Thu, 7 Jun 2018 23:03:37 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <20180608024515.jkimytwch7lstkxi@mycre.ws> References: <20180606093212.GA23880@server.ds9a.nl> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> <23321.25400.502754.584769@gro.dd.org> <20180608024515.jkimytwch7lstkxi@mycre.ws> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 03:03:40 -0000 Robert Edmonds writes: > > There is no intrinsic limit to the limit of a DNS message, > > No, there is an intrinsic limit to the size of a DNS message. If I'm not > mistaken: Right, you are absolutely correct. I was being lazy and not doing the math to get "number much larger than 64k". > 12 + 1*(255+2+2) + 3*65535*(255+2+2+4+2+65535) = 12936609271 octets, or, > about 13 gigs. From nobody Fri Jun 8 02:34:27 2018 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 E43D6130E50 for ; Fri, 8 Jun 2018 02:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 H8vzqfCoSFcv for ; Fri, 8 Jun 2018 02:34:24 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id CCD55130E54 for ; Fri, 8 Jun 2018 02:34:23 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 54F403A081 for ; Fri, 8 Jun 2018 05:34:21 -0400 (EDT) Received: by mail-oi0-f41.google.com with SMTP id t133-v6so11246077oif.10 for ; Fri, 08 Jun 2018 02:34:21 -0700 (PDT) X-Gm-Message-State: APt69E1gWUHIoTfbN9npN7TcWlkKJ+i31l8GMlM2YpTzLaNh42pHk6I2 2v1DGwSbtbGx9wcIY1i6eKln3TVfngU+jpzoBt8= X-Google-Smtp-Source: ADUXVKLt1g3ZTAQiVObdZ6+BLuJH5wgeLLVUvibtcR4P+YybEEIvsyRLyiEF3X3feZzz9uU7Z1AvYctGUYxhmNC4Ntw= X-Received: by 2002:aca:f288:: with SMTP id q130-v6mr2560414oih.347.1528450460959; Fri, 08 Jun 2018 02:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 02:34:19 -0700 (PDT) In-Reply-To: <20180607215851.GA32738@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> From: Patrick McManus Date: Fri, 8 Jun 2018 11:34:19 +0200 X-Gmail-Original-Message-ID: Message-ID: To: bert hubert Cc: Patrick McManus , Dave Lawrence , DoH WG Content-Type: multipart/alternative; boundary="000000000000c85f91056e1e1ae9" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 09:34:26 -0000 --000000000000c85f91056e1e1ae9 Content-Type: text/plain; charset="UTF-8" I'm not on board with limiting a 2018 protocol to 64KB variants because some parser of some some format might have a bug. At the very least we need to be more specific so we can assess the scope of the interoperability issue. DoH opens up new things - that's a good property. Not everything will be gatewayed back and forth into wireformat, and the wireformat isn't inherently limited to 16bit either. AXFR is an especially interesting case for DoH because it supports multiplexing and priority between streams, it might actually be the best way to carry it. as for other formats they are coming. Paul has an informational draft that has been sent to the IESG: https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/ and I've heard rumors of others in the works - even from the dns community :) If there is a known problem with gatewaying between formats, that's worth some non normative text to mention - but the notion that 64KB is enough for anybody is one I want to push back on. Even for that I would appreciate a citation of where the problem lays - there isn't agreement that wireformat actually has such a limit (though its existing transports do and maybe that's what should be noted), and no particular implementation choices, much less widely deployed and hard to upgrade implementations, have been cited (again - I'm not saying they don't exist.). -Patrick On Thu, Jun 7, 2018 at 11:58 PM, bert hubert wrote: > On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote: > > > "Sort of". Wire format itself does not have the limitation. Its use > > > on certain transports does. This distinction needs to keep being > > > made. > > tale has convinced me of this point. > > In the interest of reaching consensus, can we park this discussion until > another message type is invented and standardised that is not a DNS message > in "wire format"? > > Whenever we make life harder on the whole DNS implementation community, we > had better have a very good reason for that. > > To put it bluntly, a significant part of the DNS implementation community > (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit is > here to stay for now, so I don't see a viable consensus for expanding DNS - > especially given the lack of concrete usecases. > > Finally, I note that the DOH charter contains the following: > > "The working group will coordinate with the DNSOP and INTAREA working > groups > for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics, > respectvely. > > In particular, DNSOP will be consulted for guidance on the operational > impacts that result from traditional host behaviors (i.e., stub-resolver to > recursive-resolver interaction) being replaced with the specified > mechanism. > > Specification of how DNS-formatted data may be used for use cases beyond > normal DNS queries is out of scope for the working group." > > It may be good to point out that 'normal DNS queries' have never involved > getting >64KB responses. We might also have to consult DNSOP about changing > DNS semantics, an activity they aren't stimulated to explore. > > Finally, I do really understand how much fun it would be to liberate DNS > from its pedestrian 64KB shackles. It is an arbitrary limitation, and > perhaps one day we'd love to put gigantic post-quantum cryptographical keys > in DNS. But given the amount of developer cycles in DNS, please also > understand my (our) reticence in overhauling this ancient protocol. > > Bert > --000000000000c85f91056e1e1ae9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not on board with limiting a 2018 protocol to= 64KB variants because some parser of some some format might have a bug. At= the very least we need to be more specific so we can assess the scope of t= he interoperability issue. DoH opens up new things - that's a good prop= erty. Not everything will be gatewayed back and forth into wireformat, and = the wireformat isn't inherently limited to 16bit either. AXFR is an esp= ecially interesting case for DoH because it supports multiplexing and prior= ity between streams, it might actually be the best way to carry it.


If there is = a known problem with gatewaying between formats, that's worth some non = normative text to mention - but the notion that 64KB is enough for anybody = is one I want to push back on. Even for that I would appreciate a citation = of where the problem lays - there isn't agreement that wireformat actua= lly has such a limit (though its existing transports do and maybe that'= s what should be noted), and no particular implementation choices, much les= s widely deployed and hard to upgrade implementations, have been cited (aga= in - I'm not saying they don't exist.).

-Patrick

On Thu, Jun 7, 2018 at 11:58 PM, bert hubert <bert.hubert@powerd= ns.com> wrote:
On Thu, Jun 07, 2018 at 11:39:16PM +0200, Pat= rick McManus wrote:
> > "Sort of".=C2=A0 Wire format itself does not have the l= imitation.=C2=A0 Its use
> > on certain transports does.=C2=A0 This distinction needs to keep = being
> > made.
> tale has convinced me of this point.

In the interest of reaching consensus, can we park this discuss= ion until
another message type is invented and standardised that is not a DNS message=
in "wire format"?

Whenever we make life harder on the whole DNS implementation community, we<= br> had better have a very good reason for that.

To put it bluntly, a significant part of the DNS implementation community (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit is here to stay for now, so I don't see a viable consensus for expanding D= NS -
especially given the lack of concrete usecases.

Finally, I note that the DOH charter contains the following:

"The working group will coordinate with the DNSOP and INTAREA working = groups
for input on DNS-over-HTTPS's impact on DNS operations and DNS semantic= s,
respectvely.

In particular, DNSOP will be consulted for guidance on the operational
impacts that result from traditional host behaviors (i.e., stub-resolver to=
recursive-resolver interaction) being replaced with the specified mechanism= .

Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group."

It may be good to point out that 'normal DNS queries' have never in= volved
getting >64KB responses. We might also have to consult DNSOP about chang= ing
DNS semantics, an activity they aren't stimulated to explore.

Finally, I do really understand how much fun it would be to liberate DNS from its pedestrian 64KB shackles. It is an arbitrary limitation, and
perhaps one day we'd love to put gigantic post-quantum cryptographical = keys
in DNS. But given the amount of developer cycles in DNS, please also
understand my (our) reticence in overhauling this ancient protocol.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bert

--000000000000c85f91056e1e1ae9-- From nobody Fri Jun 8 03:11:12 2018 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 BB495130E58 for ; Fri, 8 Jun 2018 03:11:10 -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 hglYA1YeAPxV for ; Fri, 8 Jun 2018 03:11:08 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B01A12F18C for ; Fri, 8 Jun 2018 03:11:08 -0700 (PDT) Received: from jurassic (unknown [182.156.107.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id F37D432C0AC6; Fri, 8 Jun 2018 10:11:05 +0000 (UTC) Date: Fri, 8 Jun 2018 15:41:02 +0530 From: Mukund Sivaraman To: Patrick McManus Cc: bert hubert , DoH WG , Dave Lawrence Message-ID: <20180608101102.GA12334@jurassic> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 10:11:11 -0000 On Fri, Jun 08, 2018 at 11:34:19AM +0200, Patrick McManus wrote: > I'm not on board with limiting a 2018 protocol to 64KB variants because > some parser of some some format might have a bug. It's not "some parser".. for a long time implementations have assumed 64kB for message formats and these are implicit assumptions. It isn't reasonable to alter this now. RFC 1035 is from 1987 and these implicit assumptions have remained so for the last 30 years. It is ok if you want to prepare different rules in 2018, but please don't call it DNS. Mukund From nobody Fri Jun 8 03:24:54 2018 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 1D62A130E6C for ; Fri, 8 Jun 2018 03:24:52 -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 TLHOwh1Qa5ur for ; Fri, 8 Jun 2018 03:24:51 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id CFF18130E64 for ; Fri, 8 Jun 2018 03:24:50 -0700 (PDT) Received: from jurassic (unknown [182.156.107.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id E8B8732C0AC6; Fri, 8 Jun 2018 10:24:48 +0000 (UTC) Date: Fri, 8 Jun 2018 15:54:45 +0530 From: Mukund Sivaraman To: Robert Edmonds Cc: Dave Lawrence , DoH WG Message-ID: <20180608102445.GB12334@jurassic> References: <20180606093212.GA23880@server.ds9a.nl> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> <23321.25400.502754.584769@gro.dd.org> <20180608024515.jkimytwch7lstkxi@mycre.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180608024515.jkimytwch7lstkxi@mycre.ws> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 10:24:52 -0000 On Thu, Jun 07, 2018 at 10:45:15PM -0400, Robert Edmonds wrote: > Dave Lawrence wrote: > > Paul Hoffman writes: > > > Tony is completely correct here. DNS messages have well-defined > > > length limits: 512-or-more-depending if carried over UDP, and 65535 > > > if carried over TCP. > > > > Right. And completely undefined over any other transport. There is > > no intrinsic limit to the limit of a DNS message, compression pointers > > notwithstanding. > > No, there is an intrinsic limit to the size of a DNS message. If I'm not > mistaken: > > 12 octets header > > 1 question resource record: > 255 octets QNAME > 2 octets QTYPE > 2 octets QCLASS > > 3 response sections: > 65535 RR's per section: > 255 octets NAME > 2 octets TYPE > 2 octets CLASS > 4 octets TTL > 2 octets RDLENGTH > 65535 octets RDATA > > 12 + 1*(255+2+2) + 3*65535*(255+2+2+4+2+65535) = 12936609271 octets, or, > about 13 gigs. I think BIND will happily load, zone transfer (in and out) and store an RRset in memory that didn't fit in 64kB. Initially for catalog zones, we'd have used such an RRset as there's no 64kB transfer limit to an RRset. However, anything over 64kB cannot be queried for as the server will fail to construct a reply. Mukund From nobody Fri Jun 8 03:27:23 2018 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 AAD22130E64 for ; Fri, 8 Jun 2018 03:27:21 -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 QLLt641R3Dft for ; Fri, 8 Jun 2018 03:27:19 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF18130E5E for ; Fri, 8 Jun 2018 03:27:19 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:64897 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fREc1-0008Ta-1M (Exim 4.72) for doh@ietf.org (return-path ); Fri, 08 Jun 2018 11:27:17 +0100 To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> From: Ray Bellis Message-ID: <4d37f79d-df25-7b23-eca3-fb9a69f0d1e2@bellis.me.uk> Date: Fri, 8 Jun 2018 11:27:17 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 10:27:22 -0000 On 08/06/2018 10:34, Patrick McManus wrote: > Even for that I would appreciate a citation of where the problem lays > - there isn't agreement that wireformat actually has such a limit > (though its existing transports do and maybe that's what should be > noted), and no particular implementation choices, much less widely > deployed and hard to upgrade implementations, have been cited (again > - I'm not saying they don't exist.). There are likely numerous existing DNS implementations that currently assume that a 64kB buffer is large enough for any possible DNS message. I know I've written code that does that, because notwithstanding it's a limitation of UDP and a limitation of the chosen framing mechanism used when carried in TCP (but not of TCP itself, mind), it *is* the defacto limit on the size of a DNS message. I can allocate a buffer of 64kB, even on the stack, safe in the knowledge that it's "big enough". It's a trivial amount of RAM by today's standards but it avoids a lot of dynamic buffer allocation and/or re-sizing. I would also be unsurprised to find DNS server software with enforced 64kB limits on the total size of an RRset. Whilst I believe AXFR does permit RRsets to be split across message boundaries, the QUERY opcode does not (they have to be treated as a single atomic unit) so RRsets that exceed that size are effectively useless. I would be OK with special case treatment for AXFR in DOH, but *please* don't mess with the normal message size constraints for standard queries. Ray From nobody Fri Jun 8 03:30:13 2018 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 83C2C130E5E for ; Fri, 8 Jun 2018 03:30:11 -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] 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 VOT_k8pGLCuX for ; Fri, 8 Jun 2018 03:30:09 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 4EFEA130E64 for ; Fri, 8 Jun 2018 03:30:09 -0700 (PDT) Received: from [2001:b98:204:102:fff1::f145] (port=58197 helo=[192.168.12.13]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fREeh-0003rY-Dq; Fri, 08 Jun 2018 11:30:07 +0100 From: "John Dickinson" To: "DoH WG" Cc: "Patrick McManus" , "bert hubert" , "Dave Lawrence" , "Mukund Sivaraman" Date: Fri, 08 Jun 2018 11:33:35 +0100 X-Mailer: MailMate (1.11.2r5479) Message-ID: <28E66CE7-6F25-4074-958D-AA566DE3A0BC@sinodun.com> In-Reply-To: <20180608101102.GA12334@jurassic> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <20180608101102.GA12334@jurassic> MIME-Version: 1.0 X-BlackCat-Spam-Score: 0 Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 10:30:12 -0000 On 8 Jun 2018, at 11:11, Mukund Sivaraman wrote: > On Fri, Jun 08, 2018 at 11:34:19AM +0200, Patrick McManus wrote: >> I'm not on board with limiting a 2018 protocol to 64KB variants because >> some parser of some some format might have a bug. > > It's not "some parser".. for a long time implementations have assumed > 64kB for message formats and these are implicit assumptions. It isn't > reasonable to alter this now. RFC 1035 is from 1987 and these implicit > assumptions have remained so for the last 30 years. > > It is ok if you want to prepare different rules in 2018, but please > don't call it DNS. +1, I totally agree. John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K. From nobody Fri Jun 8 03:34:03 2018 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 93C8F130E6E for ; Fri, 8 Jun 2018 03:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 5Z4SC6vLg9Dg for ; Fri, 8 Jun 2018 03:34:00 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E025130E5E for ; Fri, 8 Jun 2018 03:33:59 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 0638D9FB55; Fri, 8 Jun 2018 10:33:56 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id E666DAC5B0A; Fri, 8 Jun 2018 12:33:55 +0200 (CEST) Date: Fri, 8 Jun 2018 12:33:55 +0200 From: bert hubert To: Ray Bellis Cc: doh@ietf.org Message-ID: <20180608103355.GB19916@server.ds9a.nl> References: <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <4d37f79d-df25-7b23-eca3-fb9a69f0d1e2@bellis.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d37f79d-df25-7b23-eca3-fb9a69f0d1e2@bellis.me.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] AXFR as several messages Re: [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 10:34:02 -0000 On Fri, Jun 08, 2018 at 11:27:17AM +0100, Ray Bellis wrote: > I can allocate a buffer of 64kB, even on the stack, safe in the > knowledge that it's "big enough". It's a trivial amount of RAM by > today's standards but it avoids a lot of dynamic buffer allocation > and/or re-sizing. Indeed. Another question is also, if 65kB is too small, what is a reasonable limit, in other words, what can protocol users count on? Several megabytes? I would expect people arguing for larger messages to come up with a value they can defend. > I would be OK with special case treatment for AXFR in DOH, but *please* > don't mess with the normal message size constraints for standard queries. So interestingly enough, AXFR already consists of a series of DNS messages. A DNS message does not actually need an envelope (as in TCP) since it knows where it ends. So to do AXFR over DOH, simply return multiple DNS messages concatenated. Interestingly this would make it very easy for existing authoritative servers to support DOH for AXFR since this is exactly what they do already, without the need for protocol action. Bert (Oddly enough DNS over TCP could have been done without length fields, but this was likely easier on the system calls. ) From nobody Fri Jun 8 04:22:05 2018 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 C3B4C130E79 for ; Fri, 8 Jun 2018 04:22:03 -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, FREEMAIL_FROM=0.001, 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 bMI31GOzjs26 for ; Fri, 8 Jun 2018 04:22:01 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 ED891130E78 for ; Fri, 8 Jun 2018 04:22:00 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 28976 invoked from network); 8 Jun 2018 13:21:58 +0200 Received: from acla231.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.102.231]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 8 Jun 2018 13:21:58 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: John Dickinson , DoH WG References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <20180608101102.GA12334@jurassic> <28E66CE7-6F25-4074-958D-AA566DE3A0BC@sinodun.com> Openpgp: preference=signencrypt Message-ID: Date: Fri, 8 Jun 2018 13:21:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <28E66CE7-6F25-4074-958D-AA566DE3A0BC@sinodun.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JgqpmZUf9eAYZZ4QxkQzLcshSheoLpaUf" X-WP-MailID: 79d14b6cc01904a48dc7613f01b563be X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [IdPE] Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 11:22:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JgqpmZUf9eAYZZ4QxkQzLcshSheoLpaUf Content-Type: multipart/mixed; boundary="HZDRHiSwqPtHSUUANIUvcuahoxjVdeM5l"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: John Dickinson , DoH WG Message-ID: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <20180608101102.GA12334@jurassic> <28E66CE7-6F25-4074-958D-AA566DE3A0BC@sinodun.com> In-Reply-To: <28E66CE7-6F25-4074-958D-AA566DE3A0BC@sinodun.com> --HZDRHiSwqPtHSUUANIUvcuahoxjVdeM5l Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 08.06.2018 o=C2=A012:33, John Dickinson pisze: > On 8 Jun 2018, at 11:11, Mukund Sivaraman wrote: >=20 >> On Fri, Jun 08, 2018 at 11:34:19AM +0200, Patrick McManus wrote: >>> I'm not on board with limiting a 2018 protocol to 64KB variants becau= se >>> some parser of some some format might have a bug. >> >> It's not "some parser".. for a long time implementations have assumed >> 64kB for message formats and these are implicit assumptions. It isn't >> reasonable to alter this now. RFC 1035 is from 1987 and these implicit= >> assumptions have remained so for the last 30 years. >> >> It is ok if you want to prepare different rules in 2018, but please >> don't call it DNS. >=20 > +1, I totally agree. I have been absent from much of this discussion, but I also would support= limiting message size to 64kB. On Thu, Jun 7, 2018 at 11:58 PM, bert hubert In the interest of reaching consensus, can we park this discussion unti= l > another message type is invented and standardised that is not a DNS mes= sage > in "wire format"? +1 Greetings, Mateusz --HZDRHiSwqPtHSUUANIUvcuahoxjVdeM5l-- --JgqpmZUf9eAYZZ4QxkQzLcshSheoLpaUf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbGmbUAAoJEPvWWrhhCv7GPvIQAITeFmHr4tzFF3CuS7EEPKQb 5cf/EcC9amY9IjrCnUItCH7Wv3rZSRWNc6nvJHuLa30GV1y1lDIzsGZ6PaT5dpOG jgUsfpoQe1Cl+drLX2avcyeLYZzbmAz/gAC4EGL6WIWA9fqIj9SPozJUL1XtFQxf Qdq84gew2j4TnbdWEHXRS+TuwBW/3tnOEF42i3OcEi3U5sQ/1Bygj/tl5+9nzjWF G9ZDFE68v3PzinG6AT/Vm/LPqYyfjQQExX+sV3kpwZ96swUMZCorPOfAIWwdMWaA pGahDNSIwN5KVR2QD35Ji2a92j9NoLM8wojbfPtE30DxHKcoKeeZJr1OVbqsxHwV 2urhq/Lb/fJQy9N682HSJPRY2Ml/HVMlbufTyJ46uNLhXiA7Zyp+gAzRNvMqwiX5 gRKdVaFoBqvqT86jkQRXEvqbmOHA3eNN/vF/8LOcy7g0KaS9Tt+KnwxMyA6UvgCO xH/kxJdu9qB2eFXIgh3BNlDc5LCloGBPCorAQToYFFHDLyNCc9fYMqOzKyPm/9I5 Do0x6hoy7pAWkmW58O1EZ9Iq4UI8J0bnyaW48zFuUI20TVHXZdNu+Hp7mG6E/+vT 1zN4Nz5RbKnE3r+11vrqY2zfVioLP8X57RZMnwgnIPt3J11Ha2EUiPsm+O74tSJG n7NVztyZP8LgH8PymWXM =f+pe -----END PGP SIGNATURE----- --JgqpmZUf9eAYZZ4QxkQzLcshSheoLpaUf-- From nobody Fri Jun 8 05:15:25 2018 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 A77F312785F for ; Fri, 8 Jun 2018 05:15:23 -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] 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 AjYl62xn0zEi for ; Fri, 8 Jun 2018 05:15:21 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 68CB8130E80 for ; Fri, 8 Jun 2018 05:15:21 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=53764) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fRGIV-0008AO-TD; Fri, 08 Jun 2018 13:15:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sara Dickinson In-Reply-To: Date: Fri, 8 Jun 2018 13:15:12 +0100 Cc: doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Finch X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] terminology: "DNS API" X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 12:15:24 -0000 > On 6 Jun 2018, at 15:58, Tony Finch wrote: >=20 > Can we amend the document to replace "DNS API server" with = "DNS-over-HTTPS > server" or "DoH server" please? +1 on this (since also in practice =E2=80=98DoH server=E2=80=99 seems to = be the term everyone is using) What was the reason that this name was chosen? Sara.=20 >=20 > To me, "DNS API" suggests something like getaddrinfo() or getdns. I > understand that in the web world, "API" suggests something-over-HTTP > that isn't a web page, but even in this context I feel I should expect = a > protocol involving more JSON. >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > Portland, Plymouth: Variable mainly northeast 3 or 4, increasing 5 at = times. > Slight or moderate. Showers, becoming thundery. Moderate or good, = occasionally > poor later. >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Fri Jun 8 05:41:39 2018 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 63381124D68 for ; Fri, 8 Jun 2018 05:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 zaGFd0EjDlEc for ; Fri, 8 Jun 2018 05:41:34 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB2512872C for ; Fri, 8 Jun 2018 05:41:34 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6113C3A08D for ; Fri, 8 Jun 2018 08:41:33 -0400 (EDT) Received: by mail-ot0-f176.google.com with SMTP id q17-v6so15512432otg.2 for ; Fri, 08 Jun 2018 05:41:33 -0700 (PDT) X-Gm-Message-State: APt69E2aUtTI0PUIARAUn02iT37TWtiifTDF76tTnRa7NpZXcwoNyWEf kecM1FxqOGAaSfZjazY7E0fvGNf2EVpyfhQP57Y= X-Google-Smtp-Source: ADUXVKIJScu9S+me1QTexs11WBoVErPBLMTChxqFbiWF4cxdHoIwDKfpJgbKEqTBNQAdIptX8GFM4jbZtCml/nntly8= X-Received: by 2002:a9d:2f2a:: with SMTP id h39-v6mr3325860otb.214.1528461693038; Fri, 08 Jun 2018 05:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 05:41:32 -0700 (PDT) In-Reply-To: References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <20180608101102.GA12334@jurassic> <28E66CE7-6F25-4074-958D-AA566DE3A0BC@sinodun.com> From: Patrick McManus Date: Fri, 8 Jun 2018 14:41:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Mukund Sivaraman Cc: Patrick McManus , bert hubert , DoH WG , Dave Lawrence Content-Type: multipart/alternative; boundary="00000000000044389e056e20b862" Archived-At: Subject: [Doh] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 12:41:37 -0000 --00000000000044389e056e20b862 Content-Type: text/plain; charset="UTF-8" On Friday, June 8, 2018, Mukund Sivaraman wrote: > On Fri, Jun 08, 2018 at 11:34:19AM +0200, Patrick McManus wrote: > > I'm not on board with limiting a 2018 protocol to 64KB variants because > > some parser of some some format might have a bug. > > It's not "some parser".. for a long time implementations have assumed > 64kB for message formats and these are implicit assumptions. Perhaps you feel I was being dismissive - I'm genuinely sorry about that. I was really trying to ask for specificity. If we understand the scope of the issue we can then deal with it on a corresponding scope. I mostly hear general appeals that concern how different implementations might (without citation) struggle with >64KB wireformat messages because they were unanticipated and a subsequent request to ban them from all media types as a result. I also hear some disagreement that >64KB wireformat is even a problem. I'm pushing back because the size of the hammer needs more justification from particular instances of the problem. I don't deny the possible existence of a legacy problem - I'm asking for details about it and then we can analyze how those messages will get into the hands of those implementations.. that will drive next steps There are a few options here.. sorted roughly on a spectrum from a] do nothing, b] non-normative there be dragons here text, c] wireformat specific text that clarifies it already has a 64KB limit, d] restrict all DoH content-type variants (even non wireformat ones) to 64KB. If the problem were laid out in specifics, we could more meaningfully figure out where to be on that spectrum instead of just staking out either end. As for justifying longer representations there are two angles to consider.. one is specific use cases, the other is the general architectural consideration that arbitrary limits come back to bite you later on (rejecting 640KB is enough for anybody as Bert put it.). Its ok if DoH enables some use cases that will only be used natively - it is not a mere tunnel. wrt use cases, I've spoken about JSON at the last-call level, and other JSON formats in the works. I also think key management could become an issue - lots of things are interested in storing public keys in DNS (including but not limited to dnssec) - post quantum those keys necessarily explode in size. And of course zone transfers are related large objects too. Cheerfully, Patrick --00000000000044389e056e20b862 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, June 8, 2018, Mukund Sivaraman <muks@mukund.org> wr= ote:
On Fri, Jun 08, 2018 at 11:34:19AM += 0200, Patrick McManus wrote:
> I'm not on board with limiting a 2018 protocol to 64KB variants be= cause
> some parser of some some format might have a bug.

It's not "some parser".. for a long time implementations have= assumed
64kB for message formats and these are implicit assumptions.
<= div>
Perhaps you feel I was being dismissive - I'm genuin= ely sorry about that. I was really trying to ask for specificity. If we und= erstand the scope of the issue we can then deal with it on a corresponding = scope.

I mostly hear general appeals that concern = how different implementations might (without citation) struggle with >64= KB wireformat messages because they were unanticipated and a subsequent req= uest to ban them from all media types as a result.=C2=A0 I also hear some d= isagreement that >64KB wireformat is even a problem. I'm pushing bac= k because the size of the hammer needs more justification from particular i= nstances of the problem.

I don't deny the = possible existence of a legacy problem - I'm asking for details about i= t and then we can analyze how those messages will get into the hands of tho= se implementations.. that will drive next steps

Th= ere are a few options here.. sorted roughly on a spectrum from a] do nothin= g, b] non-normative there be dragons here text, c] wireformat specific text= that clarifies it already has a 64KB limit, d] restrict all DoH content-ty= pe variants (even non wireformat ones) to 64KB.

If= the problem were laid out in specifics, we could more meaningfully figure = out where to be on that spectrum instead of just staking out either end.
=C2=A0
As for justifying longer representations there are= two angles to consider.. one is specific use cases, the other is the gener= al architectural consideration that arbitrary limits come back to bite you = later on (rejecting 640KB is enough for anybody as Bert put it.). Its ok if= DoH enables some use cases that will only be used natively - it is not a m= ere tunnel.

wrt use cases, I've spoken about J= SON at the last-call level, and other JSON formats in the works. I also thi= nk key management could become an issue - lots of things are interested in = storing public keys in DNS (including but not limited to dnssec) - post qua= ntum those keys necessarily explode in size. And of course zone transfers a= re related large objects too.

Cheerfully,
Patrick




--00000000000044389e056e20b862-- From nobody Fri Jun 8 05:46:51 2018 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 E8E67130EB0 for ; Fri, 8 Jun 2018 05:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=a+qpJzqH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FfjgXaQu 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 qc0NDZoFKxkn for ; Fri, 8 Jun 2018 05:46:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F28D124C04 for ; Fri, 8 Jun 2018 05:46:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E9BBA20F60; Fri, 8 Jun 2018 08:46:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 08 Jun 2018 08:46:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=J+PkM1G2Ub8Ix38nW46NZOUrsJHHy u/ao9YGXXFvjpA=; b=a+qpJzqHBPSK1fJd3+GZmXCq/6wII4igwSEAtikzhHZRW YnhAI3c31HZbOkrouSZGWMLgo/ibaG373f9qtOq9W5oJoHDXHvY96qvt6UNsIp85 vpilZeD4b8WCuPbVwA01ODVhv7Vk6R+F/bEMBmpIjCKhM57gRk275/r5EkoPuHyA GviX/HhoGWe+jVfc74d5qdZ5qsmmTvPE1gtwhfwzj1BmaWXtrcWAQ8AAYCKwP1PH MqpdqF3k4fdCJNsOPwMwiAR3UBX2ZzhsD/G9yHrC7EUIujgZfElyt28tNDQrIAce l5DKmcgHjeTro6hD36jJy9WZvjhJeeW+Pc5Q12brA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=J+PkM1 G2Ub8Ix38nW46NZOUrsJHHyu/ao9YGXXFvjpA=; b=FfjgXaQuQ/nxGhQUdXz3FZ oKK4fm/Jd/Goe/bNdFTJyYOJc2yAbUyvcfRluhyMLqFIYBEuRqQLe3rOZ4qRdwxS ORw/TfPIWJI7vycUgbbwDoCX+O+ewpcCF/4O1vTvMnTX2cEyqDXb44Vy+3l7mqAx OP+tZVCmcVjsHFbyDyDYHM546uBuhoWTPB1xSr+kWul/PzvZRmmMc+ilX4XM2BlD amLDqAS0n7pMO1GdLd9u1qL/TSP8zgiUXG8Z2snhVNp7x1NSbi22wpw0QadFGJmV DtZkg/7h1tosFEtx2Xy6+6M7Bbs4FWMLb+WP3nySa7xBSa/1Ies6htdU0WHLutbA == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from [10.21.164.254] (unknown [81.92.27.129]) by mail.messagingengine.com (Postfix) with ESMTPA id AF7AA10268; Fri, 8 Jun 2018 08:46:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: Date: Fri, 8 Jun 2018 14:46:35 +0200 Cc: bert hubert , DoH WG , Dave Lawrence Content-Transfer-Encoding: quoted-printable Message-Id: <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> To: Patrick McManus X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 12:46:49 -0000 AFAICT there are two of situations that might be relevant here: 1. A DOH request is gatewayed to "normal" DNS 2. A DOH response is gatewayed to "normal" DNS Could the folks who are concerned about this explain if there are any = others (with detail)? For #1, the DOH gateway should know the limitations of the protocol it's = gatewaying (in this case, DNS over UDP), and can generate a 413 or 414 = status code as appropriate (see = ). That's the correct = way to express "that request is too big" in HTTP. Some non-normative = advice in the spec about DOH servers generating appropriate status codes = and clients understanding them might help here. For #2, it seems like people are claiming that a client library is going = to implement DOH but *not* update itself to take arbitrary-sized = responses. Is anyone actually saying that's their implementation = strategy, or is this just "what if"-ism? If it's necessary to support those clients, it would be easy enough to = define a preference that allows = them to say "please give me small* responses", and require DOH servers = to honour that preference. Cheers, * Where "small" is defined as "able to be expressed in less than N bytes = in the UDP wire format" or similar. Limiting *all* DOH messages using = Content-Length is not what we want to do here. > On 8 Jun 2018, at 11:34 am, Patrick McManus = wrote: >=20 > I'm not on board with limiting a 2018 protocol to 64KB variants = because some parser of some some format might have a bug. At the very = least we need to be more specific so we can assess the scope of the = interoperability issue. DoH opens up new things - that's a good = property. Not everything will be gatewayed back and forth into = wireformat, and the wireformat isn't inherently limited to 16bit either. = AXFR is an especially interesting case for DoH because it supports = multiplexing and priority between streams, it might actually be the best = way to carry it. >=20 > as for other formats they are coming. Paul has an informational draft = that has been sent to the IESG: = https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/ and I've = heard rumors of others in the works - even from the dns community :) >=20 > If there is a known problem with gatewaying between formats, that's = worth some non normative text to mention - but the notion that 64KB is = enough for anybody is one I want to push back on. Even for that I would = appreciate a citation of where the problem lays - there isn't agreement = that wireformat actually has such a limit (though its existing = transports do and maybe that's what should be noted), and no particular = implementation choices, much less widely deployed and hard to upgrade = implementations, have been cited (again - I'm not saying they don't = exist.). >=20 > -Patrick >=20 > On Thu, Jun 7, 2018 at 11:58 PM, bert hubert = wrote: > On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote: > > > "Sort of". Wire format itself does not have the limitation. Its = use > > > on certain transports does. This distinction needs to keep being > > > made. > > tale has convinced me of this point. >=20 > In the interest of reaching consensus, can we park this discussion = until > another message type is invented and standardised that is not a DNS = message > in "wire format"? >=20 > Whenever we make life harder on the whole DNS implementation = community, we > had better have a very good reason for that.=20 >=20 > To put it bluntly, a significant part of the DNS implementation = community > (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit = is > here to stay for now, so I don't see a viable consensus for expanding = DNS - > especially given the lack of concrete usecases. >=20 > Finally, I note that the DOH charter contains the following: >=20 > "The working group will coordinate with the DNSOP and INTAREA working = groups > for input on DNS-over-HTTPS's impact on DNS operations and DNS = semantics, > respectvely. >=20 > In particular, DNSOP will be consulted for guidance on the operational > impacts that result from traditional host behaviors (i.e., = stub-resolver to > recursive-resolver interaction) being replaced with the specified = mechanism.. >=20 > Specification of how DNS-formatted data may be used for use cases = beyond > normal DNS queries is out of scope for the working group." >=20 > It may be good to point out that 'normal DNS queries' have never = involved > getting >64KB responses. We might also have to consult DNSOP about = changing > DNS semantics, an activity they aren't stimulated to explore.=20 >=20 > Finally, I do really understand how much fun it would be to liberate = DNS > from its pedestrian 64KB shackles. It is an arbitrary limitation, and > perhaps one day we'd love to put gigantic post-quantum cryptographical = keys > in DNS. But given the amount of developer cycles in DNS, please also > understand my (our) reticence in overhauling this ancient protocol.=20 >=20 > Bert >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh -- Mark Nottingham https://www.mnot.net/ From nobody Fri Jun 8 05:57:25 2018 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 67931130EA4 for ; Fri, 8 Jun 2018 05:57:23 -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 hlonwC_rdH1i for ; Fri, 8 Jun 2018 05:57:21 -0700 (PDT) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::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 5F97C124C04 for ; Fri, 8 Jun 2018 05:57:21 -0700 (PDT) Received: by mail-ot0-x242.google.com with SMTP id 101-v6so15554409oth.4 for ; Fri, 08 Jun 2018 05:57:21 -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=hakalB80Y/kaqxvbE5kVRPAk9Uk7vwioQrzf/F3Pufw=; b=HYHp8JIgpTZMMerAA6cy6+yRq5Qy6mj+vKzZztYuhuLhMQ/nFzqI4qh7T50FnlVS6i 00yq+xoyUOQ03YybVVDCqgWjlRYyhWh2AfPrrZIIZXGFW5VYd5cl+Wcu8SjlPtHjbSZD ygjs36MRJhgXmBZ4v8m9MyrK/FJyp02jrLvMnbgZaEPv/2wUjVPtTryvBfTXNsbYPKAk na1XjDfcs8UlKhUloByyUb7UOFIv1RPO20u7zbxOrIO/53krPtrvYO/ADNZx4QThPZI1 OYhafgYIwa6zwiaJL0mu8xxnr5+3OwLGiuGxTMAVaXiONlvpqYpFBiBJCREuPXFD9l+q QR2Q== 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=hakalB80Y/kaqxvbE5kVRPAk9Uk7vwioQrzf/F3Pufw=; b=s18RSbaUv9+/wakbw6Aeos2+BWsKSBPDb0tf+9At/gNo3tRvj48lL78ErPOQVM2m/q kkqcDK8tPvcvK72BOPDcILvooRqgxWsP5WaOlK++Uqa5NNcaQUoyi9z83qnBdEJT2UAM cWwBPhMp9HI2/KdV09drsIxHgqz72RvytuFhNg6zGF1iQsDTr8mMMS9LSOd5SjYrROVe G8v9usHuMrohHtLhG+VPsMYaxZLlMi15IPEMOc/Vyc3s5G8exU7zpNGdFHv2PmnRAYUh Ikl27j0EwbK6DoBH5qEJMajCNj16VtFSelH6r9o2OKNdeQl/nPdLY1QWDjyJCgBVuS65 w+gg== X-Gm-Message-State: APt69E2Mi9XYUE7RFN5jp0L1l2aNhH3nIaMkDvD4E+Pw7I9vRj8z+Myt z8wzJEY2ySpohWok3JLz4A56L3R7dRTS2dLnme+QUNom X-Google-Smtp-Source: ADUXVKJgoTHQX1oIaXkzdvU1Ykcr6nFYKiudFBEVoOGv/uUnSR8KJNaMrmoD/oaRsfJN918G7sHKSLxIPT0DbRsoEEw= X-Received: by 2002:a9d:4044:: with SMTP id o4-v6mr3328121oti.283.1528462640718; Fri, 08 Jun 2018 05:57:20 -0700 (PDT) MIME-Version: 1.0 References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <20180608101102.GA12334@jurassic> In-Reply-To: <20180608101102.GA12334@jurassic> From: Martin Thomson Date: Fri, 8 Jun 2018 14:57:09 +0200 Message-ID: To: muks@mukund.org Cc: patrick mcmanus , DoH WG , bert.hubert@powerdns.com, tale@dd.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 12:57:24 -0000 Have we agreed that limiting DOH (which might use multiple encodings) is nonsensical? And that this is just a discussion about the wireformat? On Fri, Jun 8, 2018 at 12:11 PM Mukund Sivaraman wrote: > for a long time implementations have assumed > 64kB for message formats and these are implicit assumptions OK, if this is correct, let's examine the consequences. If we limit the size, that's an artificial limit that will be hard to remove. But it is easy to understand. And future versions of ourselves will be smarter and more experienced than current us, so it's really tempting to have them deal with any problems. YAGNI and all that. On the other hand, if we fail to limit the size, it's a little harder to reason about, but I haven't seen anything significant on the thread to suggest that this would be a genuine problem. Implementations that aren't prepared to receive very large messages will break. But we have to consider that all DOH implementations will be new even if they use an existing parser. Those implementations can therefore check that they don't break. And I can't see any way for a message larger than 64k to end up in DNS over UDP or TCP. Both contain length fields that just don't permit it[1]. So the consequences seem limited to those implementations that copy queries and answers from DOH (copying *to* DOH would obviously be safe if the limit were higher). This isn't materially different from moving from TCP to UDP in that sense. Requests that go from a DOH leg to a non-DOH leg and won't fit can be immediately turned around with an error code; responses that go from a DOH leg to a non-DOH leg and won't fit can be truncated, or turned into an error response. So I'm not seeing any need to change text here. I can see how putting some fluff in about how it might be sensible to allow for limitations of decoders and so forth might seem attractive, but it doesn't appear to be *necessary*. Of course, I wouldn't object if someone wanted to insist. Cheers, Martin [1] Absent an implementation of RFC 2675, which I believe is not relevant on the internet and probably needs to be made Historic. From nobody Fri Jun 8 06:27:04 2018 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 EE594130EA3 for ; Fri, 8 Jun 2018 06:27:01 -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] 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 hSaMor35PUCo for ; Fri, 8 Jun 2018 06:26:59 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 C29A4130E39 for ; Fri, 8 Jun 2018 06:26:59 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:45399) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fRHPp-0002ZW-do (Exim 4.91) (return-path ); Fri, 08 Jun 2018 14:26:53 +0100 Date: Fri, 8 Jun 2018 14:26:53 +0100 From: Tony Finch To: Mukund Sivaraman cc: Robert Edmonds , DoH WG , Dave Lawrence In-Reply-To: <20180608102445.GB12334@jurassic> Message-ID: References: <20180606093212.GA23880@server.ds9a.nl> <5B71AC15-80F4-427B-BABA-1BE3C514145F@icann.org> <23321.25400.502754.584769@gro.dd.org> <20180608024515.jkimytwch7lstkxi@mycre.ws> <20180608102445.GB12334@jurassic> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 13:27:03 -0000 Mukund Sivaraman wrote: > > I think BIND will happily load, zone transfer (in and out) and store an > RRset in memory that didn't fit in 64kB. Initially for catalog zones, > we'd have used such an RRset as there's no 64kB transfer limit to an > RRset. However, anything over 64kB cannot be queried for as the server > will fail to construct a reply. BIND handles this better than I feared it might :-) See first dig output below - you can axfr the zone if you want. However other implementations did not have as much foresight - the second dig output is from a name server hosted on the CommunityDNS anycast service - it seems to have transfered the zone OK, though. 1. BIND ; <<>> DiG 9.13.0 <<>> +tcp +norec 65536.dotat.at in txt @grey.dotat.at ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52562 ;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: e70d27f85d21dee83f06c6445b1a828aed3ce0f8f53f262d (good) ;; QUESTION SECTION: ;65536.dotat.at. IN TXT ;; Query time: 0 msec ;; SERVER: 2001:630:212:110::d:7a7#53(2001:630:212:110::d:7a7) ;; WHEN: Fri Jun 08 14:20:10 BST 2018 ;; MSG SIZE rcvd: 71 2. CommunityDNS ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.13.0 <<>> +tcp +norec 65536.dotat.at in txt @ns3.gratisdns.dk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52381 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: Message has 2571 extra bytes at end ;; QUESTION SECTION: ;65536.dotat.at. IN TXT ;; Query time: 24 msec ;; SERVER: 2001:678:5::6#53(2001:678:5::6) ;; WHEN: Fri Jun 08 14:21:10 BST 2018 ;; MSG SIZE rcvd: 2615 Tony. -- f.anthony.n.finch http://dotat.at/ Malin, South Hebrides: Cyclonic 3 or 4. Moderate, occasionally slight later. Fair then thundery showers. Good occasionally poor. From nobody Fri Jun 8 06:38:38 2018 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 B93DA130EA7 for ; Fri, 8 Jun 2018 06:38:36 -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] 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 aRlAbfVnWwBS for ; Fri, 8 Jun 2018 06:38:34 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 A39F5130EA6 for ; Fri, 8 Jun 2018 06:38:34 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39897) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fRHb6-0005NI-gT (Exim 4.91) (return-path ); Fri, 08 Jun 2018 14:38:32 +0100 Date: Fri, 8 Jun 2018 14:38:32 +0100 From: Tony Finch To: Dave Lawrence cc: doh@ietf.org In-Reply-To: <23321.25626.316926.975797@gro.dd.org> Message-ID: References: <23321.25626.316926.975797@gro.dd.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] special meta QTYPEs X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 13:38:37 -0000 Dave Lawrence wrote: > Tony Finch writes: > > I don't think it's possible to fit AXFR or IXFR into > > DoH because their responses involve multiple DNS messages. > > Adding my comment about *XFR from a different thread to this thread > too, for tracking. > > Strictly speaking, that's not fully accurate. I have plenty of zones > that fit in a single DNS/TCP message when sent over AXFR, and > DNS/HTTPS would cover the rest quite easily if left in its current > form. Adding a restriction on message lengths would make this more > complicated. I was speaking in general terms, of course :-) An AXFR client has to be prepared to handle multiple messages in a response, regardless of the size of the zone, so a DoH proxy that tries to support AXFR cannot avoid learning how to cope with multi-message answers from its upstream DNS server. And it isn't always possible to de-fragment an AXFR response: e.g. it will break any TSIG authentication. And as Robert Edmonds pointed out, even if you lift the 64K byte message size limit, there is still a limit of 64K records (the zone contents are transferred using the answer section only), and I have plenty of zones which are bigger than that :-) Tony. -- f.anthony.n.finch http://dotat.at/ North Hebrides: Easterly 4 or 5. Moderate. Fair. Good occasionally moderate. From nobody Fri Jun 8 06:51:55 2018 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 4D855130EB1 for ; Fri, 8 Jun 2018 06:51:53 -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 YiSazS9vI0gM for ; Fri, 8 Jun 2018 06:51:51 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 C53A2130EB0 for ; Fri, 8 Jun 2018 06:51:51 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id i19-v6so15757094otk.10 for ; Fri, 08 Jun 2018 06:51:51 -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=y0cfvLoe6hliN9nBgafOQxi7Gya5vDSC+CUPr6uHcdk=; b=CScfHTlqbcViKMzak7x/Grcguse8YC7FsMitP9cb1mvQUI5kXl8FW0bd0bYpfcPYzL P0NSuM+a1WH6H0OKWg+jjOtafV7oX0nFiLwaVcY818Ii7ymMZ9/7Ph9DvnI/hGVROVVK cH8fuUXmBAvHoXT2mvH7YhrOZS5SRTb9YiDpAPETSrXx3WUz7KNIULRLX7A+1D3dZgBI rku63WsgepKQSC4Mp2nL4+mxhBeGQslcy8sQCDqaIiXf7+sveHCzx4ivT36XP9nrWjG9 bLvDmRs1FFi68/taOBgtlg+7uDt0zefIc8//hw7giG1Iy+/+MloHAHv78P2/zLwO7PWd ++8Q== 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=y0cfvLoe6hliN9nBgafOQxi7Gya5vDSC+CUPr6uHcdk=; b=gUG4h4SmZxRJ8IDQ7tpKAXPtTakgbzinZT4MKZ7fWIqsUMZZtGvN3hwvCgr29K+jz7 MDK2FZMItK7DXjJ2EMdg5dL29dcROgyHgBunmgk34ic6uKY4qHV9cFSYo33kfU3IRRig ocC2sMksoA1wyP+owv62mRhJcDu+o1lC2bMvPMRClYnF8RT5OUzkz7jJwqo+SUmVsdO4 XqiNqVgxsDgkOjrRG0uL+kP95sL/lCIG5gYNnxLCkODvud7JAXNK5M9E/59TyTizv68W /CbbnJowiOE7Z+IQDs60q9J4jOn7H1PQd5jnIOLQdKv4J3Y2qDG2PLIYoARUuWSXckH3 RRIQ== X-Gm-Message-State: APt69E2k4yRRQTkZB3+jJ+Q3QfUNjZPwDp8GLV+NFew7nr1J3ICQqCZd 1uhMVZKBgtlMloVlDSqp7vjkg7nsYRANLPPR+UI= X-Google-Smtp-Source: ADUXVKLRsL1I/q9TrkWU7D1bvAIzmTfPxUEdl1z5GkmgaYDETp+iQ4297E166upmKsY6BLDV2o1WJcmBVwyyf0/leZw= X-Received: by 2002:a9d:3666:: with SMTP id w93-v6mr3504842otb.394.1528465911001; Fri, 08 Jun 2018 06:51:51 -0700 (PDT) MIME-Version: 1.0 References: <23321.25626.316926.975797@gro.dd.org> In-Reply-To: From: Martin Thomson Date: Fri, 8 Jun 2018 15:51:39 +0200 Message-ID: To: Tony Finch Cc: tale@dd.org, DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] special meta QTYPEs X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 13:51:54 -0000 On Fri, Jun 8, 2018 at 3:38 PM Tony Finch wrote: > I was speaking in general terms, of course :-) An AXFR client has to be > prepared to handle multiple messages in a response, regardless of the size > of the zone, so a DoH proxy that tries to support AXFR cannot avoid > learning how to cope with multi-message answers from its upstream DNS > server. And it isn't always possible to de-fragment an AXFR response: e.g. > it will break any TSIG authentication. That's interesting. Are you saying that a multi-message answer that is TSIG authenticated cannot be carried in DOH? I think that's what this means. Would it require the use of something like multipart/related to faithfully carry the answer in that case? From nobody Fri Jun 8 06:56:32 2018 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 43605130EAF for ; Fri, 8 Jun 2018 06:56:30 -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] 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 46XKMnmRC5rt for ; Fri, 8 Jun 2018 06:56:28 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 9D5AB126CC7 for ; Fri, 8 Jun 2018 06:56:28 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:56816) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fRHsQ-000fbc-2e (Exim 4.91) (return-path ); Fri, 08 Jun 2018 14:56:26 +0100 Date: Fri, 8 Jun 2018 14:56:26 +0100 From: Tony Finch To: Martin Thomson cc: DoH WG , tale@dd.org In-Reply-To: Message-ID: References: <23321.25626.316926.975797@gro.dd.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] special meta QTYPEs X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 13:56:31 -0000 Martin Thomson wrote: > On Fri, Jun 8, 2018 at 3:38 PM Tony Finch wrote: > > And it isn't always possible to de-fragment an AXFR response: e.g. > > it will break any TSIG authentication. > > That's interesting. Are you saying that a multi-message answer that > is TSIG authenticated cannot be carried in DOH? I think that's what > this means. Yes, if you try to defragment it into a single DNS message so it fits the definition of application/dns-message. > Would it require the use of something like multipart/related to > faithfully carry the answer in that case? Cunning! I think that could work. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: North, becoming variable, 3 or 4. Slight, occasionally moderate in Forties. Fair. Good occasionally moderate. From nobody Fri Jun 8 10:08:23 2018 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 88E03130F33 for ; Fri, 8 Jun 2018 10:08:21 -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=yitter.info header.b=doxMaTTp; dkim=pass (1024-bit key) header.d=yitter.info header.b=X7X6WdXh 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 i229WtTDWst7 for ; Fri, 8 Jun 2018 10:08:19 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5021130F32 for ; Fri, 8 Jun 2018 10:08:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D42C7BDEF9 for ; Fri, 8 Jun 2018 17:07:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528477668; bh=1JUvvxfEatzn3hDQSIqKl7Gd2xLcnE5vN2Q+q/1NIJ4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=doxMaTTpnATVTOVK4SEv9v+pd3/dBJ/k7YdQdK+I8nt6H2ffumKw1hnnw5svgbVur X+8n5bCckmePdoNlPTvL2BP/ScSKzfFU/O6k/iDYHynNHxjaocb3FQT8Kmg33UjuVp uIfTcH8/4KKIuAngIKJ7H/2wYadglBO17J3ewQgE= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdZ5D4RngFXq for ; Fri, 8 Jun 2018 17:07:47 +0000 (UTC) Date: Fri, 8 Jun 2018 13:07:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528477667; bh=1JUvvxfEatzn3hDQSIqKl7Gd2xLcnE5vN2Q+q/1NIJ4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=X7X6WdXh/xVos2b1wRp7dUT2zMeCcU1u5ZcFUPkU22uOvHrXj5TJqZ4Fv9d0yemtv Hel1znayLDxOLFbSQxUb24NQC9gtim3hPBAWqvwfsbJT6TXcdANo52eLrX89t3xYbG DS+2V1mBH1wGaK2h0NHA8QZwiEgd0zxg0ybBwcp4= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180608170744.GY11227@mx4.yitter.info> References: <20180606093212.GA23880@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180606093212.GA23880@server.ds9a.nl> Archived-At: Subject: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 17:08:22 -0000 Dear colleagues, The discussion of the "DNS Camel" and the worry about max sizes had led me to think about what exactly we think we're doing with DOH. I am not sure we have agreement on a goal, so I thought I'd try to make this explicit. The charter discussion went to some lengths, I thought, to try to constrain the stuff we were doing effectively just to "the DNS we always had, only over HTTPS". I thought that's what this language meant: The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., operating system stub resolvers) and recursive resolvers. To person with a long history in the DNS, anything that says "DNS clients" automatically means, "That vast, tractless wilderness of half-baked implementations that might send a query for DNS and might accept inbound answers." DNS nerds assume, in general, that any condition that has "always been true" is almost certainly deployed somewhere, which is why we still have things like upward referrals, EDNS version numbering failures, and so on. There's even been a flag day announced to try to cope with some of this, but it's anyone's guess whether it'll work. Part of the problem is that the DNS lives in a sort of ambiguous place. In the layer model, it's plainly an application. But it functions as a kind of connectivity infrastructure, which is why it was handled in the INT area for so long. Because it is so old and crufty, and contains no proper versioning or negotiation or anything like that, DNS nerds have always been ultraconservative about operations and deployment. The downstream consumers of DNS data (the OS resolver libraries and so on) were often more than a little primitive, and often turn out to contain assumptions that are not true and that cause trouble. Finally, the DNS is defined in a _lot_ of RFCs, and not always in language that is entirely clear and unsubtle. While the best-known implementations are high quality, some implementers appear to have been give 30 minutes with RFC 1035 and half a day of allotted coding time. HTTPS is, of course, much more modern, and HTTP 2 has been recently gone over with a great deal of care. It is reasonable, therefore, to make assumptions about what an HTTP 2-implementing system will do. So, we might think that the right boundary to be drawing is around the DNS subsystems in a few code bases, plus the transport to be used. Anyone who is going to implement a DNS API client is going to follow the rules and do things in a clean and modern way. I think the disconnect with some people with a lot of experience in DNS is that this boundary is too tight: the dependent systems will actually not expect whatever the RFCs say, but instead what they're used to expecting based on three things they found in Google plus some code from 1993 that they inherited and don't understand. I don't have any trouble saying, "We are actually just going to insist on assuming a clean, modern architecture; things that make assumptions not justified by the letter of the RFCs -- including assumptions about transport -- are going to be broken." But I think that's the sort of principle that really does need to be written down somewhere. At the moment, the I-D is too cute about this: The integration with HTTP provides a transport suitable for both existing DNS clients and native web applications seeking access to the DNS. As several posters have already pointed out, this is only true if you accept a somewhat unusual meaning of "existing DNS clients". Those clients are going to have assumptions in them, and they are assumptions that are based on more than 30 years of deployment -- an eternity on the Internet. Architecture inheres not only in how the elements of the thing fit together, but also how the thing fits with everything else. In this case, we have to fit with the deployed Internet systems. It is perfectly fine to decide that 64k is not enough for anybody. But if that's an assumption we're going to modify, then I think we are in fact specifying a new architecture for the DNS, and we need to be less glib about that. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jun 8 13:32:01 2018 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 5CEE7131036 for ; Fri, 8 Jun 2018 13:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 ChZilG2rSdYg for ; Fri, 8 Jun 2018 13:31:56 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 61E58131024 for ; Fri, 8 Jun 2018 13:31:55 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id w7-v6so14548058wrn.6 for ; Fri, 08 Jun 2018 13:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EPSw9mfIV0u8o0cRDclpNlffiLxtoDv2w2oQh3qoCBY=; b=kVigl+tyPEH5zhZ1sSpoO6AgpKT+/l5VAlisLOL3BmPXr7G2WWDF4+B6buYt2sbG5r QRP+Wyzm+tHu9BqSXDRnpHEQOqinx9iC+A4uTVabgTA9jpTVWnfMjWPgyur7ihNGSPdk 23yx0ZdbqDc48gogl6GYs2Q8sL0abt5/B+gLw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EPSw9mfIV0u8o0cRDclpNlffiLxtoDv2w2oQh3qoCBY=; b=tKOtQ8awg7gGEhvyXQAYsnQCm0sQwda2jflgpPpIfdZ9615IBGJL1hRUuOo7AlMKrq vD7+jqMUNdlDBHB+A+CZDaJqUyFsZ2A6Yctm63njUcXvbkUfFSza3kClBvxT8z/tiPxI o+YPHkHVJh+V+ealE6RHc148cPlaWKmZxRAnhcmZjk/T5WXUNNpEuQjUP6wokQgFxYkl EpDP1tScyScrFniWQvfblpASQD/5yRwSWjxMZvY5XIIB0KTVVSt1VHIwBXLHo6aEVXis MaJblKqaP8NABtPUMHL6d9AOsHKRHaEZuhrY4LMK9mK0t3NxPnF6RsSfjP7/JyCvkDVm TGmQ== X-Gm-Message-State: APt69E1N8CpqM8HOsKtCRb/H68BUulqXAM+VThzSOQtv9bjFAz4KfgyG ozpNtM653JzJS4I3SOF8eL4OUFfXB1RWoWWG80Zkwgw5 X-Google-Smtp-Source: ADUXVKKIgiRfAHh18oZtoDPN3Sud2xwo+H2yM68zI3mY3/ZCB9RKwVuCTQOypslNM+C65KYVEXFxOXd3yhEZkGrzyxo= X-Received: by 2002:adf:a645:: with SMTP id k63-v6mr6511283wrc.231.1528489913741; Fri, 08 Jun 2018 13:31:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:af56:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 13:31:53 -0700 (PDT) In-Reply-To: <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Fri, 8 Jun 2018 13:31:53 -0700 Message-ID: To: Mark Nottingham Cc: Patrick McManus , DoH WG , bert hubert , Dave Lawrence Content-Type: multipart/alternative; boundary="0000000000005a04fe056e274a99" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 20:32:00 -0000 --0000000000005a04fe056e274a99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 8, 2018 at 5:46 AM, Mark Nottingham wrote: > AFAICT there are two of situations that might be relevant here: > > 1. A DOH request is gatewayed to "normal" DNS > 2. A DOH response is gatewayed to "normal" DNS > > Could the folks who are concerned about this explain if there are any > others (with detail)? Actually I think what DNS people are concerned about is Query over DNS =3D=3D> DoH =3D=3D> Auth server generates big answer =3D=3D= > Doh Reply =3D> Answer over DNS fails due to size limit. so the fundamental problem is when different transports have different size "limitations" In my mind 64K is fine size and if any entity is STUPID enough to give out 888K answer on DNS port they will learn quickly. The issue with encoding formats is that 1K DNS wire format is not 1K Jason or 1K compressed Jason (not saying which one is going to be the biggest) So if there is any rule needed it that answer should fit in 64K DNS wireformat with Name compression enabled. =3D=3D=3D> from this my assertion is that any given transport format can ha= ve its own limit that reflects the "compactness" of the encoding and compression but a general rule is not possible The guiding light is "do not be stupid" but that does not work in practice ....... so we are stuck with artificial limits. > > For #1, the DOH gateway should know the limitations of the protocol it's > gatewaying (in this case, DNS over UDP), and can generate a 413 or 414 > status code as appropriate (see rfc7231.html#status.413>). That's the correct way to express "that > request is too big" in HTTP. Some non-normative advice in the spec about > DOH servers generating appropriate status codes and clients understanding > them might help here. > +1 > > For #2, it seems like people are claiming that a client library is going > to implement DOH but *not* update itself to take arbitrary-sized response= s. > Is anyone actually saying that's their implementation strategy, or is thi= s > just "what if"-ism? > +1 > > If it's necessary to support those clients, it would be easy enough to > define a preference that allows > them to say "please give me small* responses", and require DOH servers to > honour that preference. > > +1 Olafur Cheers, > > * Where "small" is defined as "able to be expressed in less than N bytes > in the UDP wire format" or similar. Limiting *all* DOH messages using > Content-Length is not what we want to do here. > > > > On 8 Jun 2018, at 11:34 am, Patrick McManus > wrote: > > > > I'm not on board with limiting a 2018 protocol to 64KB variants because > some parser of some some format might have a bug. At the very least we ne= ed > to be more specific so we can assess the scope of the interoperability > issue. DoH opens up new things - that's a good property. Not everything > will be gatewayed back and forth into wireformat, and the wireformat isn'= t > inherently limited to 16bit either. AXFR is an especially interesting cas= e > for DoH because it supports multiplexing and priority between streams, it > might actually be the best way to carry it. > > > > as for other formats they are coming. Paul has an informational draft > that has been sent to the IESG: https://datatracker.ietf.org/ > doc/draft-hoffman-dns-in-json/ and I've heard rumors of others in the > works - even from the dns community :) > > > > If there is a known problem with gatewaying between formats, that's > worth some non normative text to mention - but the notion that 64KB is > enough for anybody is one I want to push back on. Even for that I would > appreciate a citation of where the problem lays - there isn't agreement > that wireformat actually has such a limit (though its existing transports > do and maybe that's what should be noted), and no particular implementati= on > choices, much less widely deployed and hard to upgrade implementations, > have been cited (again - I'm not saying they don't exist.). > > > > -Patrick > > > > On Thu, Jun 7, 2018 at 11:58 PM, bert hubert > wrote: > > On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote: > > > > "Sort of". Wire format itself does not have the limitation. Its u= se > > > > on certain transports does. This distinction needs to keep being > > > > made. > > > tale has convinced me of this point. > > > > In the interest of reaching consensus, can we park this discussion unti= l > > another message type is invented and standardised that is not a DNS > message > > in "wire format"? > > > > Whenever we make life harder on the whole DNS implementation community, > we > > had better have a very good reason for that. > > > > To put it bluntly, a significant part of the DNS implementation communi= ty > > (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit i= s > > here to stay for now, so I don't see a viable consensus for expanding > DNS - > > especially given the lack of concrete usecases. > > > > Finally, I note that the DOH charter contains the following: > > > > "The working group will coordinate with the DNSOP and INTAREA working > groups > > for input on DNS-over-HTTPS's impact on DNS operations and DNS semantic= s, > > respectvely. > > > > In particular, DNSOP will be consulted for guidance on the operational > > impacts that result from traditional host behaviors (i.e., stub-resolve= r > to > > recursive-resolver interaction) being replaced with the specified > mechanism.. > > > > Specification of how DNS-formatted data may be used for use cases beyon= d > > normal DNS queries is out of scope for the working group." > > > > It may be good to point out that 'normal DNS queries' have never involv= ed > > getting >64KB responses. We might also have to consult DNSOP about > changing > > DNS semantics, an activity they aren't stimulated to explore. > > > > Finally, I do really understand how much fun it would be to liberate DN= S > > from its pedestrian 64KB shackles. It is an arbitrary limitation, and > > perhaps one day we'd love to put gigantic post-quantum cryptographical > keys > > in DNS. But given the amount of developer cycles in DNS, please also > > understand my (our) reticence in overhauling this ancient protocol. > > > > Bert > > > > _______________________________________________ > > Doh mailing list > > Doh@ietf.org > > https://www.ietf.org/mailman/listinfo/doh > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --=20 =C3=93lafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com --0000000000005a04fe056e274a99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 8, 2018 at 5:46 AM, Mark Nottingham <<= a href=3D"mailto:mnot@mnot.net" target=3D"_blank">mnot@mnot.net> wrote:
AFAICT there are two of situat= ions that might be relevant here:

1. A DOH request is gatewayed to "normal" DNS
2. A DOH response is gatewayed to "normal" DNS

Could the folks who are concerned about this explain if there are any other= s (with detail)?
Actually I think what DNS people are conc= erned about is=C2=A0
=C2=A0Query over DNS =3D=3D> DoH =3D=3D&g= t; Auth server generates big answer =3D=3D> Doh Reply =3D> Answer ove= r DNS=C2=A0 fails due to size limit.=C2=A0
so the fundamental pro= blem is when different transports have different size "limitations&quo= t;=C2=A0
In my mind 64K is fine size and if any entity is STUPID = enough to give out 888K answer on DNS port they will learn quickly.=C2=A0

The issue with encoding formats is that 1K DNS wire= format is not 1K Jason or 1K compressed Jason (not saying which one is goi= ng to be the biggest)=C2=A0
So if there is any rule needed it tha= t answer should fit in 64K DNS wireformat with Name compression enabled.=C2= =A0
=3D=3D=3D> from this my assertion is that any given transp= ort format can have its own limit that reflects the "compactness"= of the encoding and compression but a general rule is not possible
The guiding light is "do not be stupid" but that does not work= in practice .......=C2=A0

so we are stuck with ar= tificial limits.=C2=A0
=C2=A0

For #1, the DOH gateway should know the limitations of the protocol it'= s gatewaying (in this case, DNS over UDP), and can generate a 413 or 414 st= atus code as appropriate (see <https://httpwg.org= /specs/rfc7231.html#status.413>). That's the correct way to= express "that request is too big" in HTTP. Some non-normative ad= vice in the spec about DOH servers generating appropriate status codes and = clients understanding them might help here.
+1
=C2=A0

For #2, it seems like people are claiming that a client library is going to= implement DOH but *not* update itself to take arbitrary-sized responses. I= s anyone actually saying that's their implementation strategy, or is th= is just "what if"-ism?

+1
=C2=A0

If it's necessary to support those clients, it would be easy enough to = define a preference <https://tools.ietf.org/html/rfc7240<= /a>> that allows them to say "please give me small* responses"= , and require DOH servers to honour that preference.


Cheers,

* Where "small" is defined as "able to be expressed in less = than N bytes in the UDP wire format" or similar. Limiting *all* DOH me= ssages using Content-Length is not what we want to do here.


> On 8 Jun 2018, at 11:34 am, Patrick McManus <pmcmanus@mozilla.com> wrote:
>
> I'm not on board with limiting a 2018 protocol to 64KB variants be= cause some parser of some some format might have a bug. At the very least w= e need to be more specific so we can assess the scope of the interoperabili= ty issue. DoH opens up new things - that's a good property. Not everyth= ing will be gatewayed back and forth into wireformat, and the wireformat is= n't inherently limited to 16bit either. AXFR is an especially interesti= ng case for DoH because it supports multiplexing and priority between strea= ms, it might actually be the best way to carry it.
>
> as for other formats they are coming. Paul has an informational draft = that has been sent to the IESG: https://d= atatracker.ietf.org/doc/draft-hoffman-dns-in-json/ and I've he= ard rumors of others in the works - even from the dns community :)
>
> If there is a known problem with gatewaying between formats, that'= s worth some non normative text to mention - but the notion that 64KB is en= ough for anybody is one I want to push back on. Even for that I would appre= ciate a citation of where the problem lays - there isn't agreement that= wireformat actually has such a limit (though its existing transports do an= d maybe that's what should be noted), and no particular implementation = choices, much less widely deployed and hard to upgrade implementations, hav= e been cited (again - I'm not saying they don't exist.).
>
> -Patrick
>
> On Thu, Jun 7, 2018 at 11:58 PM, bert hubert <bert.hubert@powerdns.com> wrote:
> On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote:
> > > "Sort of".=C2=A0 Wire format itself does not have = the limitation.=C2=A0 Its use
> > > on certain transports does.=C2=A0 This distinction needs to = keep being
> > > made.
> > tale has convinced me of this point.
>
> In the interest of reaching consensus, can we park this discussion unt= il
> another message type is invented and standardised that is not a DNS me= ssage
> in "wire format"?
>
> Whenever we make life harder on the whole DNS implementation community= , we
> had better have a very good reason for that.
>
> To put it bluntly, a significant part of the DNS implementation commun= ity
> (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit = is
> here to stay for now, so I don't see a viable consensus for expand= ing DNS -
> especially given the lack of concrete usecases.
>
> Finally, I note that the DOH charter contains the following:
>
> "The working group will coordinate with the DNSOP and INTAREA wor= king groups
> for input on DNS-over-HTTPS's impact on DNS operations and DNS sem= antics,
> respectvely.
>
> In particular, DNSOP will be consulted for guidance on the operational=
> impacts that result from traditional host behaviors (i.e., stub-resolv= er to
> recursive-resolver interaction) being replaced with the specified mech= anism..
>
> Specification of how DNS-formatted data may be used for use cases beyo= nd
> normal DNS queries is out of scope for the working group."
>
> It may be good to point out that 'normal DNS queries' have nev= er involved
> getting >64KB responses. We might also have to consult DNSOP about = changing
> DNS semantics, an activity they aren't stimulated to explore.
>
> Finally, I do really understand how much fun it would be to liberate D= NS
> from its pedestrian 64KB shackles. It is an arbitrary limitation, and<= br> > perhaps one day we'd love to put gigantic post-quantum cryptograph= ical keys
> in DNS. But given the amount of developer cycles in DNS, please also > understand my (our) reticence in overhauling this ancient protocol. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bert
>
> ____________________________________= ___________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh



--
=
=C3=93lafur Gudmundsson |=C2=A0En= gineering Director=C2=A0
www.cloudflare.com blog.cloudflare.com<= /a>
--0000000000005a04fe056e274a99-- From nobody Fri Jun 8 13:50:35 2018 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 5D319127AC2 for ; Fri, 8 Jun 2018 13:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 JSQLtkhsdWE3 for ; Fri, 8 Jun 2018 13:50:30 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26212F1A5 for ; Fri, 8 Jun 2018 13:50:30 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id C81813A0E9 for ; Fri, 8 Jun 2018 16:50:28 -0400 (EDT) Received: by mail-oi0-f46.google.com with SMTP id b130-v6so12948075oif.12 for ; Fri, 08 Jun 2018 13:50:28 -0700 (PDT) X-Gm-Message-State: APt69E0qE0wbBfd0uwUnwivlN/tEvq3rCq+qjwz0n9o+HGqzG+p8kpkK OkJii03U2fQhSwvGdhQwUWbC5DmSgdktdsJpo0k= X-Google-Smtp-Source: ADUXVKLT8awna5+mN9VXOMcpBjvULV2y59ukpHn4b/eM/2ZcKg7Y2VS4pcx+aRGZ8B56TqF7sn1CmwRcjYGQnIXMH3E= X-Received: by 2002:aca:5a44:: with SMTP id o65-v6mr3792114oib.155.1528491028355; Fri, 08 Jun 2018 13:50:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 13:50:27 -0700 (PDT) In-Reply-To: References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> From: Patrick McManus Date: Fri, 8 Jun 2018 16:50:27 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Cc: Mark Nottingham , Patrick McManus , DoH WG , bert hubert , Dave Lawrence Content-Type: multipart/alternative; boundary="000000000000c9a108056e278ce4" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 20:50:34 -0000 --000000000000c9a108056e278ce4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 8, 2018 at 4:31 PM, =C3=93lafur Gu=C3=B0mundsson wrote: > > > On Fri, Jun 8, 2018 at 5:46 AM, Mark Nottingham wrote: > >> AFAICT there are two of situations that might be relevant here: >> >> 1. A DOH request is gatewayed to "normal" DNS >> 2. A DOH response is gatewayed to "normal" DNS >> >> Could the folks who are concerned about this explain if there are any >> others (with detail)? > > Actually I think what DNS people are concerned about is > Query over DNS =3D=3D> DoH =3D=3D> Auth server generates big answer =3D= =3D> Doh Reply > =3D> Answer over DNS fails due to size limit. > so the fundamental problem is when different transports have different > size "limitations" > In my mind 64K is fine size and if any entity is STUPID enough to give ou= t > 888K answer on DNS port they will learn quickly. > > I'm not 100% sure I understand the illustration. perhaps we don't have a shared understanding of http content negotiation. is the example saying the terminal auth server generates a non-wireformat big answer and that's why its big? A DoH client that was gatewaying from the traditional DNS client wouldn't send an Accept: big-json (or whatever) request header for exactly this reason and the DoH server would recognize that and send the best MTI format it could manage (which is also what the server does if it didn't implement the json type and it did see the accept header) but a DoH client that was natively interpreting the response with its own Json parser would indeed send such a request header. Its effectively an opt in. (the server isn't absolutely prohibited from sending something you didn't opt in to, but you would only do it if you had nothing else.. because the client will probably treat it as an error.. so instead you send whatever version of the MTI you can manage) a gateway that was playing a caching proxy role just has to deal with 2 variants of the URI in that case - that's a normal http cache problem. I think that's all 3 versions of that scenario.. > The issue with encoding formats is that 1K DNS wire format is not 1K Jaso= n > or 1K compressed Jason (not saying which one is going to be the biggest) > So if there is any rule needed it that answer should fit in 64K DNS > wireformat with Name compression enabled. > =3D=3D=3D> from this my assertion is that any given transport format can = have > its own limit that reflects the "compactness" of the encoding and > compression but a general rule is not possible > The guiding light is "do not be stupid" but that does not work in practic= e > ....... > > so we are stuck with artificial limits. > >> > > >> For #1, the DOH gateway should know the limitations of the protocol it's >> gatewaying (in this case, DNS over UDP), and can generate a 413 or 414 >> status code as appropriate (see > 231.html#status.413>). That's the correct way to express "that request >> is too big" in HTTP. Some non-normative advice in the spec about DOH >> servers generating appropriate status codes and clients understanding th= em >> might help here. >> > +1 > > >> >> For #2, it seems like people are claiming that a client library is going >> to implement DOH but *not* update itself to take arbitrary-sized respons= es. >> Is anyone actually saying that's their implementation strategy, or is th= is >> just "what if"-ism? >> > > +1 > > >> >> If it's necessary to support those clients, it would be easy enough to >> define a preference that allows >> them to say "please give me small* responses", and require DOH servers t= o >> honour that preference. >> >> +1 > > Olafur > > Cheers, >> >> * Where "small" is defined as "able to be expressed in less than N bytes >> in the UDP wire format" or similar. Limiting *all* DOH messages using >> Content-Length is not what we want to do here. >> >> >> > On 8 Jun 2018, at 11:34 am, Patrick McManus >> wrote: >> > >> > I'm not on board with limiting a 2018 protocol to 64KB variants becaus= e >> some parser of some some format might have a bug. At the very least we n= eed >> to be more specific so we can assess the scope of the interoperability >> issue. DoH opens up new things - that's a good property. Not everything >> will be gatewayed back and forth into wireformat, and the wireformat isn= 't >> inherently limited to 16bit either. AXFR is an especially interesting ca= se >> for DoH because it supports multiplexing and priority between streams, i= t >> might actually be the best way to carry it. >> > >> > as for other formats they are coming. Paul has an informational draft >> that has been sent to the IESG: https://datatracker.ietf.org/d >> oc/draft-hoffman-dns-in-json/ and I've heard rumors of others in the >> works - even from the dns community :) >> > >> > If there is a known problem with gatewaying between formats, that's >> worth some non normative text to mention - but the notion that 64KB is >> enough for anybody is one I want to push back on. Even for that I would >> appreciate a citation of where the problem lays - there isn't agreement >> that wireformat actually has such a limit (though its existing transport= s >> do and maybe that's what should be noted), and no particular implementat= ion >> choices, much less widely deployed and hard to upgrade implementations, >> have been cited (again - I'm not saying they don't exist.). >> > >> > -Patrick >> > >> > On Thu, Jun 7, 2018 at 11:58 PM, bert hubert >> wrote: >> > On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote: >> > > > "Sort of". Wire format itself does not have the limitation. Its >> use >> > > > on certain transports does. This distinction needs to keep being >> > > > made. >> > > tale has convinced me of this point. >> > >> > In the interest of reaching consensus, can we park this discussion unt= il >> > another message type is invented and standardised that is not a DNS >> message >> > in "wire format"? >> > >> > Whenever we make life harder on the whole DNS implementation community= , >> we >> > had better have a very good reason for that. >> > >> > To put it bluntly, a significant part of the DNS implementation >> community >> > (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit = is >> > here to stay for now, so I don't see a viable consensus for expanding >> DNS - >> > especially given the lack of concrete usecases. >> > >> > Finally, I note that the DOH charter contains the following: >> > >> > "The working group will coordinate with the DNSOP and INTAREA working >> groups >> > for input on DNS-over-HTTPS's impact on DNS operations and DNS >> semantics, >> > respectvely. >> > >> > In particular, DNSOP will be consulted for guidance on the operational >> > impacts that result from traditional host behaviors (i.e., >> stub-resolver to >> > recursive-resolver interaction) being replaced with the specified >> mechanism.. >> > >> > Specification of how DNS-formatted data may be used for use cases beyo= nd >> > normal DNS queries is out of scope for the working group." >> > >> > It may be good to point out that 'normal DNS queries' have never >> involved >> > getting >64KB responses. We might also have to consult DNSOP about >> changing >> > DNS semantics, an activity they aren't stimulated to explore. >> > >> > Finally, I do really understand how much fun it would be to liberate D= NS >> > from its pedestrian 64KB shackles. It is an arbitrary limitation, and >> > perhaps one day we'd love to put gigantic post-quantum cryptographical >> keys >> > in DNS. But given the amount of developer cycles in DNS, please also >> > understand my (our) reticence in overhauling this ancient protocol. >> > >> > Bert >> > >> > _______________________________________________ >> > Doh mailing list >> > Doh@ietf.org >> > https://www.ietf.org/mailman/listinfo/doh >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > > > > -- > =C3=93lafur Gudmundsson | Engineering Director > www.cloudflare.com blog.cloudflare.com > --000000000000c9a108056e278ce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 8, 2018 at 4:31 PM, =C3=93lafur Gu=C3=B0mundsson <ola= fur@cloudflare.com> wrote:
=


On Fri, Jun 8, 2018 at 5:46 AM, Mark Nottingham <mnot@mno= t.net> wrote:
AFAICT there = are two of situations that might be relevant here:

1. A DOH request is gatewayed to "normal" DNS
2. A DOH response is gatewayed to "normal" DNS

Could the folks who are concerned about this explain if there are any other= s (with detail)?
Actually I think what DNS people a= re concerned about is=C2=A0
=C2=A0Query over DNS =3D=3D> DoH = =3D=3D> Auth server generates big answer =3D=3D> Doh Reply =3D> An= swer over DNS=C2=A0 fails due to size limit.=C2=A0
so the fundame= ntal problem is when different transports have different size "limitat= ions"=C2=A0
In my mind 64K is fine size and if any entity is= STUPID enough to give out 888K answer on DNS port they will learn quickly.= =C2=A0


I'm not 100% sure I understand the illustration. perhaps we don'= t have a shared understanding of http content negotiation. is the example s= aying the terminal auth server generates a non-wireformat big answer and th= at's why its big?

A DoH client that was ga= tewaying from the traditional DNS client wouldn't send an Accept: big-j= son (or whatever) request header for exactly this reason and the DoH server= would recognize that and send the best MTI format it could manage (which i= s also what the server does if it didn't implement the json type and it= did see the accept header)

but a DoH client t= hat was natively interpreting the response with its own Json parser would i= ndeed send such a request header. Its effectively an opt in. (the server is= n't absolutely prohibited from sending something you didn't opt in = to, but you would only do it if you had nothing else.. because the client w= ill probably treat it as an error.. so instead you send whatever version of= the MTI you can manage)

a gateway that was pl= aying a caching proxy role just has to deal with 2 variants of the URI in t= hat case - that's a normal http cache problem.

I think that's all 3 versions of that scenario..




=C2=A0
The issue with encoding formats is that 1K= DNS wire format is not 1K Jason or 1K compressed Jason (not saying which o= ne is going to be the biggest)=C2=A0
So if there is any rule need= ed it that answer should fit in 64K DNS wireformat with Name compression en= abled.=C2=A0
=3D=3D=3D> from this my assertion is that any giv= en transport format can have its own limit that reflects the "compactn= ess" of the encoding and compression but a general rule is not possibl= e
The guiding light is "do not be stupid" but that does= not work in practice .......=C2=A0

so we are stuc= k with artificial limits.=C2=A0
=C2=A0

For #1, the DOH gateway should know the limitations of the protocol it'= s gatewaying (in this case, DNS over UDP), and can generate a 413 or 414 st= atus code as appropriate (see <https://httpwg.org= /specs/rfc7231.html#status.413>). That's the correct way to= express "that request is too big" in HTTP. Some non-normative ad= vice in the spec about DOH servers generating appropriate status codes and = clients understanding them might help here.
+1<= /div>
=C2=A0

For #2, it seems like people are claiming that a client library is going to= implement DOH but *not* update itself to take arbitrary-sized responses. I= s anyone actually saying that's their implementation strategy, or is th= is just "what if"-ism?

+1
=C2=A0

If it's necessary to support those clients, it would be easy enough to = define a preference <https://tools.ietf.org/html/rfc7240<= /a>> that allows them to say "please give me small* responses"= , and require DOH servers to honour that preference.


Cheers,

* Where "small" is defined as "able to be expressed in less = than N bytes in the UDP wire format" or similar. Limiting *all* DOH me= ssages using Content-Length is not what we want to do here.


> On 8 Jun 2018, at 11:34 am, Patrick McManus <pmcmanus@mozilla.com> wrote:
>
> I'm not on board with limiting a 2018 protocol to 64KB variants be= cause some parser of some some format might have a bug. At the very least w= e need to be more specific so we can assess the scope of the interoperabili= ty issue. DoH opens up new things - that's a good property. Not everyth= ing will be gatewayed back and forth into wireformat, and the wireformat is= n't inherently limited to 16bit either. AXFR is an especially interesti= ng case for DoH because it supports multiplexing and priority between strea= ms, it might actually be the best way to carry it.
>
> as for other formats they are coming. Paul has an informational draft = that has been sent to the IESG: https://d= atatracker.ietf.org/doc/draft-hoffman-dns-in-json/ and I've he= ard rumors of others in the works - even from the dns community :)
>
> If there is a known problem with gatewaying between formats, that'= s worth some non normative text to mention - but the notion that 64KB is en= ough for anybody is one I want to push back on. Even for that I would appre= ciate a citation of where the problem lays - there isn't agreement that= wireformat actually has such a limit (though its existing transports do an= d maybe that's what should be noted), and no particular implementation = choices, much less widely deployed and hard to upgrade implementations, hav= e been cited (again - I'm not saying they don't exist.).
>
> -Patrick
>
> On Thu, Jun 7, 2018 at 11:58 PM, bert hubert <bert.hubert@powerdns.com> w= rote:
> On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote:
> > > "Sort of".=C2=A0 Wire format itself does not have = the limitation.=C2=A0 Its use
> > > on certain transports does.=C2=A0 This distinction needs to = keep being
> > > made.
> > tale has convinced me of this point.
>
> In the interest of reaching consensus, can we park this discussion unt= il
> another message type is invented and standardised that is not a DNS me= ssage
> in "wire format"?
>
> Whenever we make life harder on the whole DNS implementation community= , we
> had better have a very good reason for that.
>
> To put it bluntly, a significant part of the DNS implementation commun= ity
> (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit = is
> here to stay for now, so I don't see a viable consensus for expand= ing DNS -
> especially given the lack of concrete usecases.
>
> Finally, I note that the DOH charter contains the following:
>
> "The working group will coordinate with the DNSOP and INTAREA wor= king groups
> for input on DNS-over-HTTPS's impact on DNS operations and DNS sem= antics,
> respectvely.
>
> In particular, DNSOP will be consulted for guidance on the operational=
> impacts that result from traditional host behaviors (i.e., stub-resolv= er to
> recursive-resolver interaction) being replaced with the specified mech= anism..
>
> Specification of how DNS-formatted data may be used for use cases beyo= nd
> normal DNS queries is out of scope for the working group."
>
> It may be good to point out that 'normal DNS queries' have nev= er involved
> getting >64KB responses. We might also have to consult DNSOP about = changing
> DNS semantics, an activity they aren't stimulated to explore.
>
> Finally, I do really understand how much fun it would be to liberate D= NS
> from its pedestrian 64KB shackles. It is an arbitrary limitation, and<= br> > perhaps one day we'd love to put gigantic post-quantum cryptograph= ical keys
> in DNS. But given the amount of developer cycles in DNS, please also > understand my (our) reticence in overhauling this ancient protocol. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bert
>
> _______________________________________________=
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh



--
=C3=93lafur Gudmundsson |=C2=A0Engineering Director=C2=A0
<= a href=3D"http://www.cloudflare.com" target=3D"_blank">www.cloudflare.com blog.cloudflare= .com

--000000000000c9a108056e278ce4-- From nobody Fri Jun 8 14:31:29 2018 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 610F9131048 for ; Fri, 8 Jun 2018 14:31:27 -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 fGEHK9K4zpg4 for ; Fri, 8 Jun 2018 14:31:25 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E630131047 for ; Fri, 8 Jun 2018 14:31:25 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 42A6823E96; Fri, 8 Jun 2018 17:31:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23322.62892.251560.128565@gro.dd.org> Date: Fri, 8 Jun 2018 17:31:24 -0400 From: Dave Lawrence To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: Mark Nottingham , Patrick McManus , DoH WG , bert hubert In-Reply-To: References: <20180606093212.GA23880@server.ds9a.nl> <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 21:31:28 -0000 =D3lafur Gu=F0mundsson writes: > Actually I think what DNS people are concerned about is: > Query over DNS =3D=3D> DoH =3D=3D> Auth server generates big answer = =3D=3D> Doh > Reply =3D> Answer over DNS fails due to size limit. I'm a DNS person and I don't have a concern about this. The software that gets an answer over HTTPS that is too big for the implementer to want to handle, whether for technical or philosophical reasons, is free to just not handle it. Any software that is taking a DoH answer from an HTTPS channel is brand new software, not some legacy problem that we have to worry about. If it imposes size limits before passing it on to whatever legacy code it wants to pass it on to, so be it. The new software shouldn't be just blindly passing whatever data it gets into some legacy parser anyway, especially if the draft comes with an admonishment to be wary of that very thing. The DoH recipient will of course be fundamentally incapable of turning a > 64k DNS/HTTPS answer into a > 64k answer on DNS/UDP or DNS/TCP, so nothing on the other end of DNS/UDP and DNS/TCP will be dealing with any new problem. In the end, what onerous "fails due to size limit" problem is there=3F We've already had a demonstration on the list today of a DNS server, with no HTTPS involved at all, having a zone with a > 64k RRset that it can't send over faithfully DNS/UDP or DNS/TCP. Clearly some legacy software is already cognizant of things that should be representable in DNS wire format but just can't be because of a legacy transport limit. All it means is that the client that wants the data can't get it in a pre-DoH world, but the world keeps revolving nonetheless. From nobody Fri Jun 8 14:58:49 2018 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 1F225130DC2 for ; Fri, 8 Jun 2018 14:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 DKi0HVLWbcuO for ; Fri, 8 Jun 2018 14:58:45 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776CE130DC1 for ; Fri, 8 Jun 2018 14:58:44 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 5B9719FB55; Fri, 8 Jun 2018 21:58:41 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id CB321AC102C; Fri, 8 Jun 2018 23:58:41 +0200 (CEST) Date: Fri, 8 Jun 2018 23:58:41 +0200 From: bert hubert To: Dave Lawrence Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , Mark Nottingham , DoH WG , Patrick McManus Message-ID: <20180608215841.GA20830@server.ds9a.nl> References: <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23322.62892.251560.128565@gro.dd.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 21:58:48 -0000 On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote: > lafur Gumundsson writes: > > Actually I think what DNS people are concerned about is: > > Query over DNS ==> DoH ==> Auth server generates big answer ==> Doh > > Reply => Answer over DNS fails due to size limit. > > I'm a DNS person and I don't have a concern about this. The software First, we should be clear no one has identified a usecase for "megabyte size DNS messages" that can't be solved today already. So the question is, for no identified upside, what is the downside? The downside is that if we do this, "large DNS messages" are a thing. They can happen over DOH transport. Please realize nothing in the draft says anything about this being restricted to resolvers. Authoritative Servers can start talking DOH, and they well might. Resolvers can then speak it to them. DNS has fundamentally changed. And legally, auths can emit these 32 bit sized DNS messages now, so we'll have to be able to store them in resolvers, and also serve them up when requested. Next up, someone writes a testsuite for this and complains to all resolvers and authoritative servers that they are not compliant. Anyone implementing a DOH-proxy (which seems to be common) is now also stymied since resolvers can't communicate 32 bit sized DNS messages over any transport they do support. Whenever someone creates a new DNS feature, it turns into a requirement. And it starts showing up in RFPs and mandatory feature lists. And we all have to do it, or spend valuable time arguing with users and customers why they don't actually need this. So with one sentence in a draft about a new transport format, for a feature no one has yet found a usecase for, all DNS implementations will eventually have to change or spend time arguing with their users. Next up, we will have standards action work to determine the semantics of TC on TCP/IP, because this will start to happen once authoritative servers emit megabyte sized answers. This requires another new RFC and all resolvers and stubs will have to learn how to deal with this. We may also have to write a 32-bit TCP protocol perhaps so we at least have a lightweight way of sharing large DNS answers. Dave, you mention you aren't worried over this change. I assume this means a strong commitment to implementing the changes in your software and working on the drafts that specify the TC behaviour on TCP? Finally, I want to echo the remarks of Andrew that if we are going to change 30 years of DNS, it is a big thing. And it should not come out of a privacy enhancing transport format that is being rushed into service. And frankly, for the people that do want to see a DOH RFC in 2018, I would strongly suggest sticking to being a transport format that does not change the rest of DNS. Because I expect we'll be working on this well into 2019 if this WG wants to overhaul DNS as part of DOH. Bert From nobody Fri Jun 8 15:17:10 2018 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 2B966130EC7 for ; Fri, 8 Jun 2018 15:17:08 -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=yitter.info header.b=LFp1oPno; dkim=pass (1024-bit key) header.d=yitter.info header.b=mfQ13yAV 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 8_ByOo92Nz-8 for ; Fri, 8 Jun 2018 15:17:06 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99655130DC1 for ; Fri, 8 Jun 2018 15:17:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 38382BDEF9 for ; Fri, 8 Jun 2018 22:17:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528496225; bh=FRcOHXonWwBTL5OoJuvqz1thYHQ/yfog83Z7ACxHxAU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LFp1oPnoX7qJLYLJDOQIyl7L5VVQUNeA6uXcqerlYhOs24Lt1nQmBLShS65H68j7a hfchHAoVqaKoakgiaGWoU1qSa5++CD2ds4ivg8dgXAQ9lVXNv2GSE2h12xST8OWSsJ Yh9eKjd1rIYI3mQXL4cH7Fy6C2eTCGpfbCcpkKys= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syfYvZT8pHMK for ; Fri, 8 Jun 2018 22:17:04 +0000 (UTC) Date: Fri, 8 Jun 2018 18:17:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528496223; bh=FRcOHXonWwBTL5OoJuvqz1thYHQ/yfog83Z7ACxHxAU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=mfQ13yAVh3Ld7GHI73M+fi1QGNJhfx2sdBcdXx298KiawEUKILcWfNCDuCDOnNsn1 K1CvfZmJ+4rvzRSiVtHbo98dwivQPsymdMcABOKuN6FpU+DY/VPXhN85qrjZCJ63i3 UF41CoAg0/c4dMROvg8WqTnuZguO0OLurKz8nGmk= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180608221700.GC8515@mx4.yitter.info> References: <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23322.62892.251560.128565@gro.dd.org> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 22:17:08 -0000 On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote: > I'm a DNS person … > Any software that is taking a DoH answer from an HTTPS channel is > brand new software, not some legacy problem that we have to worry > about. I am surprised to see those two claims in the same email. It is certainly true that the part of the software that is talking to the HTTPS channel is new. I am way less convinced that the rest of it will be, particularly when the draft explicitly says, "The integration with HTTP provides a transport suitable for both existing DNS clients…." > If it imposes size limits before passing it on to whatever > legacy code it wants to pass it on to, so be it. The new software > shouldn't be just blindly passing whatever data it gets into some > legacy parser anyway, especially if the draft comes with an > admonishment to be wary of that very thing. Yeah, I'd be much less concerned about if the draft gave those warnings. But I also think such warnings will give the lie to the claim I quoted above. > it can't send over faithfully DNS/UDP or DNS/TCP. Clearly some legacy > software is already cognizant of things that should be representable > in DNS wire format but just can't be because of a legacy transport > limit. Sure. And some legacy software deals with EDNS version numbers correctly, but some does not. And some legacy software checks for poison, and some does not. And some legacy software spits up on well-formed RRTYPEs it does not know about, and some does not. We have _a lot_ of stuff in the DNS that we have worked around because it's basic infrastructure of the Internet. I am by no means opposed to this WG saying, "We're the new transport, and we're Doing It Right, and broken stuff can all be broken." But we need to carry that bag in through the front door. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jun 8 16:47:01 2018 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 07394130DE0 for ; Fri, 8 Jun 2018 16:47:00 -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 6nWKIt_Ry0CJ for ; Fri, 8 Jun 2018 16:46:58 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E59130DC0 for ; Fri, 8 Jun 2018 16:46:58 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id E673C23F06; Fri, 8 Jun 2018 19:46:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23323.5488.915402.337488@gro.dd.org> Date: Fri, 8 Jun 2018 19:46:56 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <20180608221700.GC8515@mx4.yitter.info> References: <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> <20180608221700.GC8515@mx4.yitter.info> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 23:47:01 -0000 Andrew Sullivan writes: > On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote: > > I'm a DNS person >=20 > =E2=80=A6 You're questioning that assertion=3F > > Any software that is taking a DoH answer from an HTTPS channel is > > brand new software, not some legacy problem that we have to worry > > about. >=20 > I am surprised to see those two claims in the same email. It is > certainly true that the part of the software that is talking to the > HTTPS channel is new. I am way less convinced that the rest of it > will be, particularly when the draft explicitly says, "The integratio= n > with HTTP provides a transport suitable for both existing DNS > clients=E2=80=A6."=20 It does provide a transport suitable for existing DNS clients. DNS/HTTPS carries messages that are usable with existing clients. The possibility of a DNS/HTTPS message being bigger than a DNS/UDP or DNS/TCP client wants to deal with doesn't invalidate that. It means that when interfacing from one transport to the other, you have to be mindful of the difference between them. You *already* have to be mindful of the difference between TCP and UDP. DNS servers can *already* store data that is too big for the largest possible DNS/TCP message. When writing new code *of course* you have to be mindful of the differences between the transports. > Yeah, I'd be much less concerned about if the draft gave those > warnings. Completely agree. So if Patrick and Paul add the warning, you're on board=3F > I am by no means opposed to this WG saying, "We're the new > transport, and we're Doing It Right, and broken stuff can all be > broken." But we need to carry that bag in through the front door. I'm on board with this. Especially since it hasn't been demonstrated that this would break stuff that any competent programmer writing new code should be able to avoid. If someone is writing DoH code and concerned that they might be pumping a message longer than 64k directly into a API that you are even a little unsure of its ability to handle messages of that size, then don't do that. This is not hard. Especially since if the limits are put in they have to do the check anyway. From nobody Fri Jun 8 17:02:01 2018 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 CB19C130DC0 for ; Fri, 8 Jun 2018 17:01:59 -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 lSUf36GmID4c for ; Fri, 8 Jun 2018 17:01:58 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5102D130DE5 for ; Fri, 8 Jun 2018 17:01:58 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9D12223F10; Fri, 8 Jun 2018 20:01:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23323.6389.617603.20210@gro.dd.org> Date: Fri, 8 Jun 2018 20:01:57 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <20180608215841.GA20830@server.ds9a.nl> References: <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> <20180608215841.GA20830@server.ds9a.nl> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 00:02:00 -0000 bert hubert writes: > First, we should be clear no one has identified a usecase for > "megabyte size DNS messages" that can't be solved today already. So > the question is, for no identified upside, what is the downside? First we should be clear that we have identified a use case of zone transfers, and if you want to refute it then please be more clear on what your objection to that use case is that makes it not legitimate. Just hand-waving it away with "can be solved already" isn't really an answer, since there are lots of ways we can solve problems but that doesn't make them necessarily better. It just means we're adaptable in the face of adversity. That rebuttal doesn't even yet have to address other potential use cases that have been mentioned like increased cryptographic information in messages, which could also benefit from not being limited to 64k. > Dave, you mention you aren't worried over this change. I assume this > means a strong commitment to implementing the changes in your > software and working on the drafts that specify the TC behaviour on > TCP? Sure, you bet. Since existing software will already emit TC over DNS/TCP you are absolutely correct that we should address that in dnsop. I look forward to working with you on that. While you're here, can you please tell us what problems your code is going to have with a > 64k message that you can't solve if there is no defined limit on message size but that you could solve if there were? From nobody Sat Jun 9 01:19:09 2018 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 444BB130E1C for ; Sat, 9 Jun 2018 01:19:06 -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 Uvzz8u7Ai1Vc for ; Sat, 9 Jun 2018 01:19:04 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59812777C for ; Sat, 9 Jun 2018 01:19:03 -0700 (PDT) Received: from jurassic (unknown [14.194.233.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id DAE6C32C09D5; Sat, 9 Jun 2018 08:18:59 +0000 (UTC) Date: Sat, 9 Jun 2018 13:48:52 +0530 From: Mukund Sivaraman To: Dave Lawrence Cc: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , Mark Nottingham , DoH WG , Patrick McManus , bert hubert Message-ID: <20180609081852.GA21347@jurassic> References: <20180607093647.GB32326@server.ds9a.nl> <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23322.62892.251560.128565@gro.dd.org> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 08:19:07 -0000 On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote: > Any software that is taking a DoH answer from an HTTPS channel is > brand new software, not some legacy problem that we have to worry > about. If it imposes size limits before passing it on to whatever > legacy code it wants to pass it on to, so be it. The new software > shouldn't be just blindly passing whatever data it gets into some > legacy parser anyway, especially if the draft comes with an > admonishment to be wary of that very thing. Dave, I don't understand all the ways DoH will be used yet. I have concerns about use of messages that come via this transport into traditional DNS software [let's not call it legacy yet ;)]. There are current implementations that will parse a single message as a "whole" in memory (i.e., not as a stream, in parts). With a 64k message limit, there is an upper limit on derived objects from a single message. Such code will have to be reviewed and rewritten when messages are several megabytes or even gigabytes in size (such as a whole AXFR). I understand that the >64kB message sizes need not apply to traditional DNS software, but if we're retrofitting support for DoH into such products, programmers are going to try to re-use a lot of the existing code. This code is written with assumptions for traditional DNS, and it may be very hard to do this based on the design. On retrofitting, I'll give you an example - take pipelining (and out of order processing) of queries over TCP. It is a *simple* concept to describe, requiring not more than a page of text. But if you wanted to fit it into existing designs of resolvers (their client-side to auth code) and authoritative servers, it takes a large amount of effort due to the design. E.g., I know of a popular resolver that even now doesn't implement pipelining completely. Sometimes the benefits outweigh the effort, but as you say for the opposing opinion, we should not hand wave it in as the effort has a cost. A DoH intermediate may not be able to split up a single large message into multiple pieces, esp. when things like TSIG are involved, e.g., for a large single AXFR message. It may also not be able to combine several small ones into a large message. Do you envision such a large-message AXFR to travel exclusively over DoH? I'm all for a new protocol if the goal is to not worry about backwards compatibility and work on something for the current age. Is this the goal? If so, why even bother with the suboptimal DNS message format? Mukund From nobody Sat Jun 9 06:08:00 2018 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 B19F612785F for ; Sat, 9 Jun 2018 06:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[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=mnot.net header.b=Wgi40D6i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=htfkYP11 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 QhIrltQr2WA3 for ; Sat, 9 Jun 2018 06:07:57 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062A8127148 for ; Sat, 9 Jun 2018 06:07:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 104E920B52; Sat, 9 Jun 2018 09:07:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 09 Jun 2018 09:07:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=yCHlI9DVVZFMLxz3RwuT8/k5hEiaW PGshH8SZiNWgLQ=; b=Wgi40D6ib8gaq2wGazRDcHgbCVi1kflB50dcyhYpxAaTv bYoBBwrfFdSUxyWMmRITs/AXRXOoYGMKuOUEdBTAU/2XjQ/J722e1S6ix5sYvie/ FPed9ONkW0r+JBMk//JfLEx36d0uC0uwuA6LWpABr7L99sHl2AXtC0RiXZmquzQ/ RhbtFc1j6lqBROzMAFml7AvOFbsuIbk/DApLjfjBuM0sJWIVSofYruCghFVW0jRB TCndPE2hoC9vEqI5BEJtXst4Rt2AU0xqxHFfM0RKTa/TrRhFb9NCCU1fzk924Gpg 7qYqQW+lXbRzUlQm4+36y/vlCdUDrqlllvVMrTb+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yCHlI9 DVVZFMLxz3RwuT8/k5hEiaWPGshH8SZiNWgLQ=; b=htfkYP11nUsh9JyYhFjr06 ehTNB+mgaQddW57hmsvzWHjd3tfp0rzckPB+lypUwB521WDAhph1XxjpYWQeMWmE fcBbc6NjGq6GE+CKSk0/WiqWpiSGUlXIB1UKvFCaMEWNpdQrStl3G3a1u2m8vdQT 7KvsmZ/nvK05W/eIS0wcPGXMuFWoEhO3T3YPuXCJXTWM26P2ShOHyrIsVy8YsVfl k8RWVIh4Pu5DFDjtHsIjQwExH9dwuasJPqUdhznz3H4KK94/1xONNhO+cVltcgZt SWoCFMmbFRwT6s+xbh/qFk0e3JsvaQT/rNmGKDKXm0pXs50HW3NJ3tdYmEk2fDiw == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from [10.130.1.189] (66.211.241.83.in-addr.dgcsystems.net [83.241.211.66]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B92AE464A; Sat, 9 Jun 2018 09:07:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: <20180608170744.GY11227@mx4.yitter.info> Date: Sat, 9 Jun 2018 15:07:53 +0200 Cc: doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 13:07:59 -0000 Hi Andrew, > On 8 Jun 2018, at 7:07 pm, Andrew Sullivan = wrote: >=20 > I don't have any trouble saying, "We are actually just going to insist > on assuming a clean, modern architecture; things that make assumptions > not justified by the letter of the RFCs -- including assumptions about > transport -- are going to be broken." But I think that's the sort of > principle that really does need to be written down somewhere. At the > moment, the I-D is too cute about this: "Cute" is a very loaded term. > The integration with HTTP provides a transport suitable for both > existing DNS clients and native web applications seeking access to > the DNS. >=20 > As several posters have already pointed out, this is only true if you > accept a somewhat unusual meaning of "existing DNS clients". Those > clients are going to have assumptions in them, and they are > assumptions that are based on more than 30 years of deployment -- an > eternity on the Internet. >=20 > Architecture inheres not only in how the elements of the thing fit > together, but also how the thing fits with everything else. In this > case, we have to fit with the deployed Internet systems. It is > perfectly fine to decide that 64k is not enough for anybody. But if > that's an assumption we're going to modify, then I think we are in > fact specifying a new architecture for the DNS, and we need to be less > glib about that. Or we could just change "clients" to "client use cases," thereby = removing the implication that it'll work when dropped in front of any = existing client library (which isn't terribly interesting anyway, IMO). DNS may very well need a new architecture, but loading this = responsibility onto DOH post-WGLC is asking too much of it, and is = unfair to the folks who brought this work to the IETF in good faith. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jun 9 17:29:27 2018 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 6FC8D130DDB for ; Sat, 9 Jun 2018 17:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 JVfUhKs7YV7V for ; Sat, 9 Jun 2018 17:29:24 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47529130DD2 for ; Sat, 9 Jun 2018 17:29:24 -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; Sat, 9 Jun 2018 17:29:22 -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; Sat, 9 Jun 2018 17:29:22 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: Proposal to close off these threads Thread-Index: AQHUAFITEsaYwCV0QEGG1e9nonKrxw== Date: Sun, 10 Jun 2018 00:29:20 +0000 Message-ID: <1D917C05-2B74-4607-9EE2-55D367FF48B5@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: <143A53130066014693DE7B19AB41AF42@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 00:29:26 -0000 Greetings. Yeah, this one is difficult. Well-intentioned folks with decades= of experience disagree, and yet we need to move forward. It would be good = to do so using definitive language that does not presuppose particular unde= rstanding of the DNS protocols. The best way to do this is to make changes = to the specific media type defined in this document, not to the entire prot= ocol. (We were sometimes sloppy in the draft about differentiating the prot= ocol from this specific media type.) Proposal: 7. Definition of the application/dns-message media type The data payload in this media type is the DNS on-the-wire format define= d in [RFC1035]. The format is for DNS over UDP. Although [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", that was later updated by [RFC6891]. This media type restricts the size of the DNS message to 65535 bytes. Note that the wire format used in this media typ= e is different than the wire format used in [RFC7858]. DNS API clients using this media type MAY have one or more EDNS options [RFC6891] in the request. DNS API servers using this media type MUST ign= ore the value given for the EDNS UDP payload size in DNS requests. The use of the AXFR and IXFR QTYPEs with this media type is not yet defined. When using the GET method, the data payload for this media type MUST be encoded with base64url [RFC4648] and then provided as a variable named "dns" to the URI Template expansion. Padding characters for base64url MU= ST NOT be included. When using the POST method, the data payload for this media type MUST NO= T be encoded and is used directly as the HTTP message body. People can later define new media types, such as to handle larger DNS messa= ges, to handle new QTYPEs or Meta-TYPEs, and so on. People can also later u= pdate this media type to define how to use AXFR and/or IXFR in a predictabl= e and interoperable fashion. --Paul Hoffman= From nobody Sun Jun 10 09:16:51 2018 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 F37E9130E74 for ; Sun, 10 Jun 2018 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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=yitter.info header.b=KKfnjR5G; dkim=pass (1024-bit key) header.d=yitter.info header.b=ArhGL4+c 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 QEstdNLynocV for ; Sun, 10 Jun 2018 09:16:48 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9DC130E32 for ; Sun, 10 Jun 2018 09:16:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A68A0BDEF9 for ; Sun, 10 Jun 2018 16:16:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528647406; bh=kzNULsb7RzpRVY0BtB5Y3orhUPBnn13svQITfxaE24E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KKfnjR5G9N8IP6His0C00HwTm1lbjeNYW/0NsiyZq9aKzPM30x3IcVQt8t17CIbIh MWaa1j2F6oFey+VZSVz2jgcokYBNR2AaILbwUGMGbk3b/x73KsDRx7NqL6A8Bboi2X vcGePDYxKCEtu3CP0I/g/Fj5YpJv6E9b/FN/2GLM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOC3N1u0sPKp for ; Sun, 10 Jun 2018 16:16:45 +0000 (UTC) Date: Sun, 10 Jun 2018 12:16:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528647405; bh=kzNULsb7RzpRVY0BtB5Y3orhUPBnn13svQITfxaE24E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ArhGL4+cOegmvgKYjf5vDU7JnhDyZCCDqOEEPCmpPSd8yimvQO24EKPg2n9zQ1pMy LRZD4JOTmQs9zvMpDz50dewAzrlzMU4DhTKwmuVHnEx9al8rMNMDcPBH39rs7UjVQR svGy01hsFw8oEP0ZrzvTgm36qykoeIlvAo/Amsq8= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180610161645.GF8515@mx4.yitter.info> References: <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> <20180608221700.GC8515@mx4.yitter.info> <23323.5488.915402.337488@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23323.5488.915402.337488@gro.dd.org> Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 16:16:50 -0000 On Fri, Jun 08, 2018 at 07:46:56PM -0400, Dave Lawrence wrote: > Andrew Sullivan writes: > > On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote: > > > I'm a DNS person > > > > … > > You're questioning that assertion? Certainly not! That was very much my point -- that you have a lot of experience with the protocol and know how far it sometimes is in practice from what the documents say. > Completely agree. So if Patrick and Paul add the warning, you're on > board? I think if we can come up with the right words, then it'll make things less risky, but I also worry about the deployment story unless we can figure out what to do if something in the pipeline can't take the "jumbo" messages. > code should be able to avoid. If someone is writing DoH code and > concerned that they might be pumping a message longer than 64k > directly into a API that you are even a little unsure of its ability > to handle messages of that size, then don't do that. That's the kind of risk I would rather not take: IMO the protocol needs to say what happens in case something can't take these new-fangled messages, I think. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Jun 10 09:33:00 2018 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 BA6CE130E81 for ; Sun, 10 Jun 2018 09:32:58 -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=yitter.info header.b=nlDQsrL2; dkim=pass (1024-bit key) header.d=yitter.info header.b=RkK8A+qt 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 n9fq6gdhbTBo for ; Sun, 10 Jun 2018 09:32:57 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2500A130E7C for ; Sun, 10 Jun 2018 09:32:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 7A2EDBDEF9 for ; Sun, 10 Jun 2018 16:32:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528648376; bh=gW+PjnpS1GMyi9TXDoSyZutfuwjkeTjUB9V9BLpXCLk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nlDQsrL2mPKssq6VxtiNm/1DsivJwsLwMUyjzuCShNAOOdAkMs3/gbZ3aiV5TSAME wgEgE1wWJ4Zis+Y3ftUfKI3VJXKq/B2KBy/KoRvk2L/mcPvq1u7j4AWo9WVdciiRHr q6EiMGXeQRIIKiYowy+d/nMervmJskyJ/8NqNi+8= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PGWgaG-nQwg for ; Sun, 10 Jun 2018 16:32:55 +0000 (UTC) Date: Sun, 10 Jun 2018 12:32:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528648375; bh=gW+PjnpS1GMyi9TXDoSyZutfuwjkeTjUB9V9BLpXCLk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RkK8A+qtn+4SQzBo4Mz5EoJqGs/CEb/oj0IqTeMJF/0ZU5+rmc56hYgDRguHUY8u1 9KU4x+aEqP/QOyybCh5wLvoy2RH24ggp4rmGIZ8vc1Btij5qwCDWx5J1xabTR5qzO+ k2Nz0eIsnleD59DvqT/LGBc22NjheSgtNl0+5EQo= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180610163253.GG8515@mx4.yitter.info> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> Archived-At: Subject: Re: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 16:32:59 -0000 Hi, On Sat, Jun 09, 2018 at 03:07:53PM +0200, Mark Nottingham wrote: > > "Cute" is a very loaded term. Apologies; I didn't mean to be loaded. I just mean that the claim is either true in a pretty unusual way, or it isn't really true. > Or we could just change "clients" to "client use cases," thereby removing the implication that it'll work when dropped in front of any existing client library (which isn't terribly interesting anyway, IMO). > Well, you might not find it interesting, but people who have been struggling with the limitations of DNS for a long time might find it interesting and might try to plumb their bog-standard DNS systems through this new transport -- especially if the document says that it's suitable for such use. > DNS may very well need a new architecture, but loading this responsibility onto DOH post-WGLC is asking too much of it, and is unfair to the folks who brought this work to the IETF in good faith. > If that is true, then it is illegitimate in the IETF context to notice a technical issue late in any document's life cycle and raise it. I don't think that's how the IETF works, and I think it would be an abuse of rough consensus to insist that, because a problem shows up late it shouldn't be taken into consideration since people brought work to the IETF in good faith and had been working on it. But in any case, my point is just that, whether we like it or don't, we are _in fact_ making a new architecture in this effort, and we're doing it with assumptions that appear not to line up correctly across the sub-communities who are working on the problem. That ought not to be too surprising: these are two important protocols that work in quite different ways, and the people who have worked on them over time, unsurprisingly, have developed different intuitions about what to expect. If we put them together, we're gong to find differences. It takes time to draw those out, and now we have drawn out an expectation that some people have because people have attempted to work through what the I-D will mean in practice. We ought to be pleased that we discover these corners now. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Jun 10 15:08:48 2018 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 ABAFC128CF3 for ; Sun, 10 Jun 2018 15:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 zkgwRLpRuFsF for ; Sun, 10 Jun 2018 15:08:44 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F5A1277CC for ; Sun, 10 Jun 2018 15:08:43 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 842D89FB55 for ; Sun, 10 Jun 2018 22:08:41 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 44074AC61CC; Mon, 11 Jun 2018 00:08:41 +0200 (CEST) Date: Mon, 11 Jun 2018 00:08:41 +0200 From: bert hubert To: DoH WG Message-ID: <20180610220841.GB16671@server.ds9a.nl> References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 22:08:46 -0000 On Sun, Jun 10, 2018 at 12:29:20AM +0000, Paul Hoffman wrote: > particular understanding of the DNS protocols. The best way to do this is > to make changes to the specific media type defined in this document, not > to the entire protocol. (We were sometimes sloppy in the draft about > differentiating the protocol from this specific media type.) While I understand it will not make everyone happy, I heartily support the wording below, especially in the interest of getting this transfer method for DNS out there in 2018. Bert From nobody Sun Jun 10 16:10:25 2018 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 37970130F28 for ; Sun, 10 Jun 2018 16:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 MpCuECD4f-CA for ; Sun, 10 Jun 2018 16:10:21 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 580C8130EDE for ; Sun, 10 Jun 2018 16:10:21 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 271F83A019 for ; Sun, 10 Jun 2018 19:10:20 -0400 (EDT) Received: by mail-oi0-f41.google.com with SMTP id 188-v6so2952871oid.12 for ; Sun, 10 Jun 2018 16:10:20 -0700 (PDT) X-Gm-Message-State: APt69E02JWPASgK9b+t/3hHStobuH1JHN53h1mLxCTtszv2uCSO2e2WN MFBbzHixG+v34XzzFfgnAP3AhALi0La7TMmHm+0= X-Google-Smtp-Source: ADUXVKJ3eatE/OiqnqQsgFKWdZTLxoWfdO4ILPXNlmGnwQm+hV9oKTvCWmBS4IwGV2TyE8ibOr8WbuF91rmoJLWikhw= X-Received: by 2002:aca:a88b:: with SMTP id r133-v6mr7784355oie.213.1528672219842; Sun, 10 Jun 2018 16:10:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 16:10:18 -0700 (PDT) In-Reply-To: <20180610161645.GF8515@mx4.yitter.info> References: <23321.27027.73356.94056@gro.dd.org> <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> <20180608221700.GC8515@mx4.yitter.info> <23323.5488.915402.337488@gro.dd.org> <20180610161645.GF8515@mx4.yitter.info> From: Patrick McManus Date: Sun, 10 Jun 2018 19:10:18 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000a45137056e51bc6f" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 23:10:24 -0000 --000000000000a45137056e51bc6f Content-Type: text/plain; charset="UTF-8" On Sun, Jun 10, 2018 at 12:16 PM, Andrew Sullivan wrote: > > I think if we can come up with the right words, then it'll make things > less risky, but I also worry about the deployment story unless we can > figure out what to do if something in the pipeline can't take the > "jumbo" messages. > > After having re-read the related threads, I think it might be helpful to talk about how content negotiation works in the http pipeline. let's assume we have 2 message formats - wireformat-64 and traditional wireformat. And that we define traditional wireformat to be limited to 16 bits (its not clear to me whether or not that is really true in practice, but let's say we determine that it is.). I believe the concern is "traditional -> doh -> doh" where the doh -> doh link could use wireformat-64 and then the initial traditional client cannot consume wireformat-64 but ends up with it anyhow. Is that right? That shouldn't happen. The middle node realizes it is a gateway for a traditional client and only indicates to the final server that it knows how to speak traditional wireformat for the request it is making. The fact that it is over DoH does not add new media types to the request by default, the middle node needs to (essentially) opt-in to that via the Accept: request header and it wouldn't do that here. making the middle node a doh http cache makes things a little more complicated for the cache, but not in a way that is unusual for an http cache. If in that scenario it had previously done a transaction for a doh client that supported wireformat-64 it could certainly cache that (modulo all the other caching rules) and then when the traditional client came along, the cache just needs to recognize that the variant it has in cache is not one that the client recognizes. At which point it makes a new upstream request for traditional-wireformat-only. This works ok even if there is a non-doh aware http cache in the chain as long as the server marks the response "Vary: Accept" (which it should do if it creates different variants based on the accept header.. that's not something DoH needs to specify, 723x has it covered - pure http behavior). So if traditional wireformat consumers are limited to 16 bit sizes we definitely should document that as part of the wireformat definition. The next question is are they, or are we just at a point where we are concerned they might be? I'm really not sure on that one. in either case, I don't see a reason to restrict protocol beyond the wireformat definition. --000000000000a45137056e51bc6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 10, 2018 at 12:16 PM, Andrew Sullivan <ajs@anvilwalrusden.com= > wrote:
<= br> I think if we can come up with the right words, then it'll make = things
less risky, but I also worry about the deployment story unless we can
figure out what to do if something in the pipeline can't take the
"jumbo" messages.


After having r= e-read the related threads, I think it might be helpful to talk about how c= ontent negotiation works in the http pipeline.

let= 's assume we have 2 message formats - wireformat-64 and traditional wir= eformat. And that we define traditional wireformat to be limited to 16 bits= (its not clear to me whether or not that is really true in practice, but l= et's say we determine that it is.).

I believe = the concern is "traditional -> doh -> doh" where the doh -&= gt; doh link could use wireformat-64 and then the initial traditional clien= t cannot consume wireformat-64 but ends up with it anyhow. Is that right?

That shouldn't happen. The middle node realizes= it is a gateway for a traditional client and only indicates to the final s= erver that it knows how to speak traditional wireformat for the request it = is making. The fact that it is over DoH does not add new media types to the= request by default, the middle node needs to (essentially) opt-in to that = via the Accept: request header and it wouldn't do that here.
<= div>
making the middle node a doh http cache makes things a l= ittle more complicated for the cache, but not in a way that is unusual for = an http cache. If in that scenario it had previously done a transaction for= a doh client that supported wireformat-64 it could certainly cache that (m= odulo all the other caching rules) and then when the traditional client cam= e along, the cache just needs to recognize that the variant it has in cache= is not one that the client recognizes. At which point it makes a new upstr= eam request for traditional-wireformat-only. This works ok even if there is= a non-doh aware http cache in the chain as long as the server marks the re= sponse "Vary: Accept" (which it should do if it creates different= variants based on the accept header.. that's not something DoH needs t= o specify, 723x has it covered - pure http behavior).

<= div>So if traditional wireformat consumers are limited to 16 bit sizes we d= efinitely should document that as part of the wireformat definition. The ne= xt question is are they, or are we just at a point where we are concerned t= hey might be? I'm really not sure on that one.

in either case, I don't see a reason to restrict protocol beyond the w= ireformat definition.


=C2=A0

--000000000000a45137056e51bc6f-- From nobody Sun Jun 10 16:17:43 2018 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 1E267130F28 for ; Sun, 10 Jun 2018 16:17:41 -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=yitter.info header.b=fbLf9Lq6; dkim=pass (1024-bit key) header.d=yitter.info header.b=Al2QC0ul 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 fpxz1lE_eOt4 for ; Sun, 10 Jun 2018 16:17:39 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF18D130EDE for ; Sun, 10 Jun 2018 16:17:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 00019BDEF9 for ; Sun, 10 Jun 2018 23:17:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528672629; bh=njhtp63IJx60WldY0wltnguESKTkQ+9Jhy5O7SwJ6o4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fbLf9Lq699ngpfyWHvh6XvKvmeGfs00lYs8j+EuWhzEDKv7IlCK/pzokOF+S7xzBD xYOoTo7M1E9qsTRSrCTr0HoztHUqNKBmaAt0gSOLCcP/x8awTXPm6FzVxB+MLy5sQS VBPBS15G3MeXU99rnAUaxAWVxaKW8PTaVp5PtlO8= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze0MZHsTPWJZ for ; Sun, 10 Jun 2018 23:17:07 +0000 (UTC) Date: Sun, 10 Jun 2018 19:17:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1528672627; bh=njhtp63IJx60WldY0wltnguESKTkQ+9Jhy5O7SwJ6o4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Al2QC0ul9JMs0l4VksrR7HOmXhPxbtTsnX6OxePsef6M6+9cmzLNoNhFBV1AUTTn5 hkeH+uiSswiEd/1VaJ/sdljf5+GawXGcPaA3EdT9cFeQbmFMBbqoF8vRhYlVoldDgQ 2SS9zHG8EiKyAbopNq+2UI2PIAVIlwvXql+ENa2w= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180610231704.GB18326@mx4.yitter.info> References: <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> <20180608221700.GC8515@mx4.yitter.info> <23323.5488.915402.337488@gro.dd.org> <20180610161645.GF8515@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 23:17:42 -0000 On Sun, Jun 10, 2018 at 07:10:18PM -0400, Patrick McManus wrote: > I believe the concern is "traditional -> doh -> doh" where the doh -> doh link > could use wireformat-64 and then the initial traditional client cannot consume > wireformat-64 but ends up with it anyhow. Is that right? > > That shouldn't happen. The middle node realizes it is a gateway for a > traditional client It's the part where the middle node _doesn't know_ it's a gateway for a "traditional client" that I've been worried about, because someone takes their existing code, plops an HTTPS transit on it, and thinks they're golden. I know Tale thinks I'm worrying about something that Shouldn't Happen, but I think experience tells us this kind of thing happens _all the time_ in poorly-constructed DNS implementations. In any case, I haven't read it carefully but my quick scan of what Paul sent to the list makes me think it's enough to prevent that naïve sort of implementation (or anyway, at least the document will have said it so that if you do the wrong thing it's obviously your own fault). A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Jun 10 16:21:48 2018 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 AE966130F29 for ; Sun, 10 Jun 2018 16:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 zG9M0msPOokx for ; Sun, 10 Jun 2018 16:21:43 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8B436130EDE for ; Sun, 10 Jun 2018 16:21:43 -0700 (PDT) Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3C9073A019 for ; Sun, 10 Jun 2018 19:21:43 -0400 (EDT) Received: by mail-ot0-f182.google.com with SMTP id w9-v6so16240635otj.7 for ; Sun, 10 Jun 2018 16:21:43 -0700 (PDT) X-Gm-Message-State: APt69E1StOnr1cwbrxl900MNOL88y4QMyjsYczJCpkwVmMlykKSwioJ+ uwEIiYY8xYay4JSenTWxa1Hm0z/Z+B9ko+sqslU= X-Google-Smtp-Source: ADUXVKLY5DtmcYBJqjNQPP/NSTbN1l5f1ovuG7HzoLc0H4aYsZzohwYAgfEdv6bjOW/mdVsIHH1SzwVOJopYqdepcj4= X-Received: by 2002:a9d:1142:: with SMTP id p2-v6mr8243882otp.110.1528672902934; Sun, 10 Jun 2018 16:21:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 16:21:42 -0700 (PDT) In-Reply-To: <20180610231704.GB18326@mx4.yitter.info> References: <20180607215851.GA32738@server.ds9a.nl> <9381B529-B2F4-459A-88EB-4410A4C4DB6F@mnot.net> <23322.62892.251560.128565@gro.dd.org> <20180608221700.GC8515@mx4.yitter.info> <23323.5488.915402.337488@gro.dd.org> <20180610161645.GF8515@mx4.yitter.info> <20180610231704.GB18326@mx4.yitter.info> From: Patrick McManus Date: Sun, 10 Jun 2018 19:21:42 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000005b7847056e51e522" Archived-At: Subject: Re: [Doh] [Ext] DNS Camel thoughts: TC and message size X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 23:21:46 -0000 --0000000000005b7847056e51e522 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 10, 2018 at 7:17 PM, Andrew Sullivan wrote: > On Sun, Jun 10, 2018 at 07:10:18PM -0400, Patrick McManus wrote: > > I believe the concern is "traditional -> doh -> doh" where the doh -> > doh link > > could use wireformat-64 and then the initial traditional client cannot > consume > > wireformat-64 but ends up with it anyhow. Is that right? > > > > That shouldn't happen. The middle node realizes it is a gateway for a > > traditional client > > It's the part where the middle node _doesn't know_ it's a gateway for > a "traditional client" that I've been worried about, because someone > takes their existing code, plops an HTTPS transit on it, and thinks > they're golden. so that's a doh client, not a traditional client. And they would have to opt into the wireformat-64 bits in my example explicitly with a request header for a non default media type. At some point you have to give them what they ask for :) > I know Tale thinks I'm worrying about something that > Shouldn't Happen, but I think experience tells us this kind of thing > happens _all the time_ in poorly-constructed DNS implementations. > > In any case, I haven't read it carefully but my quick scan of what > Paul sent to the list makes me think it's enough to prevent that na=C3=AF= ve > sort of implementation (or anyway, at least the document will have > said it so that if you do the wrong thing it's obviously your own > fault). > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000005b7847056e51e522 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jun 10, 2018 at 7:17 PM, Andrew Sullivan <= ajs@anvilwalrus= den.com> wrote:
On Sun, Jun 10, 2018 at 07:10:18PM -0400, Patrick McManus wrote:
> I believe the concern is "traditional -> doh -> doh" w= here the doh -> doh link
> could use wireformat-64 and then the initial traditional client cannot= consume
> wireformat-64 but ends up with it anyhow. Is that right?
>
> That shouldn't happen. The middle node realizes it is a gateway fo= r a
> traditional client

It's the part where the middle node _doesn't know_ it's = a gateway for
a "traditional client" that I've been worried about, because = someone
takes their existing code, plops an HTTPS transit on it, and thinks
they're golden.=C2=A0

so that's a d= oh client, not a traditional client. And they would have to opt into the wi= reformat-64 bits in my example explicitly with a request header for a non d= efault media type. At some point you have to give them what they ask for :)=

=C2=A0
I= know Tale thinks I'm worrying about something that
Shouldn't Happen, but I think experience tells us this kind of thing happens _all the time_ in poorly-constructed DNS implementations.

In any case, I haven't read it carefully but my quick scan of what
Paul sent to the list makes me think it's enough to prevent that na=C3= =AFve
sort of implementation (or anyway, at least the document will have
said it so that if you do the wrong thing it's obviously your own
fault).

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--0000000000005b7847056e51e522-- From nobody Sun Jun 10 16:31:12 2018 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 8541F130F28 for ; Sun, 10 Jun 2018 16:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 NkAsLAuJipTF for ; Sun, 10 Jun 2018 16:31:08 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id AA5E3130EDE for ; Sun, 10 Jun 2018 16:31:08 -0700 (PDT) Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com [74.125.82.172]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5AFD23A01E for ; Sun, 10 Jun 2018 19:31:08 -0400 (EDT) Received: by mail-ot0-f172.google.com with SMTP id h6-v6so21771819otj.0 for ; Sun, 10 Jun 2018 16:31:08 -0700 (PDT) X-Gm-Message-State: APt69E1f+XvpvmJGXjKjo8i/ZpZzJnClF49ZcUpsxu5aNimd5qDqgiEI R6WW/5fmG1LlGDtv4Rhu7sFRsXPgG8gPzcGxhjk= X-Google-Smtp-Source: ADUXVKJNYTo4is3+Gm3UoZI92c9LlUyjL0s//SX9u0bVwsOUXYGwFE0XrmAUoNJi15SLXoi7Im9jE0GIQs2TLChvYyg= X-Received: by 2002:a9d:1142:: with SMTP id p2-v6mr8253999otp.110.1528673468089; Sun, 10 Jun 2018 16:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 16:31:07 -0700 (PDT) In-Reply-To: <20180610220841.GB16671@server.ds9a.nl> References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> From: Patrick McManus Date: Sun, 10 Jun 2018 19:31:07 -0400 X-Gmail-Original-Message-ID: Message-ID: To: bert hubert Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000000b08e8056e5207ef" Archived-At: Subject: Re: [Doh] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 23:31:11 -0000 --0000000000000b08e8056e5207ef Content-Type: text/plain; charset="UTF-8" I think we can make progress here. I'm pleased to see the text restricted to the media type. I don't think it should explicitly restrict axfr, but rather be about size. This both makes the reasoning clearer and hits the target more accurately in edge cases (doesn't apply to small axfr and does apply to a huge rr set of key types and txt records or something). I'm happy if we also mention many [ai]xfr require more than one traditional wireformat message and so won't fit in this media type. Its good to note, non-normatively, that a server that cannot satisfy a request because of this media type's size restriction can use 413 to signal that. make sense? On Sun, Jun 10, 2018 at 6:08 PM, bert hubert wrote: > On Sun, Jun 10, 2018 at 12:29:20AM +0000, Paul Hoffman wrote: > > particular understanding of the DNS protocols. The best way to do this > is > > to make changes to the specific media type defined in this document, not > > to the entire protocol. (We were sometimes sloppy in the draft about > > differentiating the protocol from this specific media type.) > > While I understand it will not make everyone happy, I heartily support the > wording below, especially in the interest of getting this transfer method > for DNS out there in 2018. > > Bert > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000000b08e8056e5207ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we can make progress here. I'm pleased to= see the text restricted to the media type. I don't think it should exp= licitly restrict axfr, but rather be about size.

This both makes the reasoning clearer and hits the target more accuratel= y in edge cases (doesn't apply to small axfr and does apply to a huge r= r set of key types and txt records or something). I'm happy if we also = mention many [ai]xfr require more than one traditional wireformat message a= nd so won't fit in this media type. Its good to note, non-normatively, = that a server that cannot satisfy a request because of this media type'= s size restriction can use 413 to signal that.

make sense?



On Sun, Jun 10, 2018 at 6:08 PM, bert hu= bert <bert.hubert@powerdns.com> wrote:
On Sun, Jun 10, 2018 at 12:29:20AM +0000, Paul Ho= ffman wrote:
> particular understanding of the DNS protocols.=C2=A0 The best way to d= o this is
> to make changes to the specific media type defined in this document, n= ot
> to the entire protocol.=C2=A0 (We were sometimes sloppy in the draft a= bout
> differentiating the protocol from this specific media type.)

While I understand it will not make everyone happy, I heartily suppo= rt the
wording below, especially in the interest of getting this transfer method for DNS out there in 2018.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bert

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--0000000000000b08e8056e5207ef-- From nobody Sun Jun 10 16:53:20 2018 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 7EE13130F29 for ; Sun, 10 Jun 2018 16:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Hlv02hPd04cg for ; Sun, 10 Jun 2018 16:53:17 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E06D130DCC for ; Sun, 10 Jun 2018 16:53:17 -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; Sun, 10 Jun 2018 16:53:15 -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; Sun, 10 Jun 2018 16:53:15 -0700 From: Paul Hoffman To: Patrick McManus CC: DoH WG Thread-Topic: [Ext] [Doh] Proposal to close off these threads Thread-Index: AQHUARYytWA6Pi1qTE+ZJhzr/XL78A== Date: Sun, 10 Jun 2018 23:53:15 +0000 Message-ID: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> In-Reply-To: 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: <4ECB212E740C05468861E6B215F917EA@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 23:53:19 -0000 On Jun 10, 2018, at 4:31 PM, Patrick McManus wrote: >=20 > I think we can make progress here. I'm pleased to see the text restricted= to the media type. I don't think it should explicitly restrict axfr, but r= ather be about size. >=20 > This both makes the reasoning clearer and hits the target more accurately= in edge cases (doesn't apply to small axfr and does apply to a huge rr set= of key types and txt records or something). I'm happy if we also mention m= any [ai]xfr require more than one traditional wireformat message and so won= 't fit in this media type. I would rather not mention stuff we can't back up. If a developer wants to = do ?XFR over this transport and have others interoperate with them, it will= probably take much less time for them to write the (hopefully very short) = Internet Draft than it will for them to eventually have to debug and patch = their code when someone else makes different assumptions. > Its good to note, non-normatively, that a server that cannot satisfy a re= quest because of this media type's size restriction can use 413 to signal t= hat. "can use"? "SHOULD use" except in situation X? "MUST use"? --Paul Hoffman (PS: The above proves that the document authors are not carefully coordinat= ing their responses off-list...)= From nobody Sun Jun 10 17:08:40 2018 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 38AAA130DC2 for ; Sun, 10 Jun 2018 17:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 YrTuHtkPpeWV for ; Sun, 10 Jun 2018 17:08:36 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB612D7F8 for ; Sun, 10 Jun 2018 17:08:36 -0700 (PDT) Received: from mail-ot0-f181.google.com (mail-ot0-f181.google.com [74.125.82.181]) by linode64.ducksong.com (Postfix) with ESMTPSA id C4D0C3A01E for ; Sun, 10 Jun 2018 20:08:35 -0400 (EDT) Received: by mail-ot0-f181.google.com with SMTP id 101-v6so21805854oth.4 for ; Sun, 10 Jun 2018 17:08:35 -0700 (PDT) X-Gm-Message-State: APt69E0hDZJevoKae0qEQQ2KoIyf8yKFgcT7g2/sk9CFyn212scN8EXW u4XwUZmFyi7ZoMYk6E14NwKgylhmMNtBV1pSHd0= X-Google-Smtp-Source: ADUXVKJm+dieuNqorBFywekuM3awPyjCXEePZf9lWzZqm+HsTXpxjHX+cLqt/74EpXDoRI7k+QP3bXmQKz5C7NQwZj4= X-Received: by 2002:a9d:2c41:: with SMTP id f59-v6mr8217355otb.263.1528675715501; Sun, 10 Jun 2018 17:08:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 17:08:35 -0700 (PDT) In-Reply-To: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> From: Patrick McManus Date: Sun, 10 Jun 2018 19:08:35 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: Patrick McManus , DoH WG Content-Type: multipart/alternative; boundary="000000000000ffd5e4056e528ce0" Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 00:08:39 -0000 --000000000000ffd5e4056e528ce0 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 10, 2018 at 6:53 PM, Paul Hoffman wrote: > On Jun 10, 2018, at 4:31 PM, Patrick McManus wrote: > > > > I think we can make progress here. I'm pleased to see the text > restricted to the media type. I don't think it should explicitly restrict > axfr, but rather be about size. > > > > This both makes the reasoning clearer and hits the target more > accurately in edge cases (doesn't apply to small axfr and does apply to a > huge rr set of key types and txt records or something). I'm happy if we > also mention many [ai]xfr require more than one traditional wireformat > message and so won't fit in this media type. > > I would rather not mention stuff we can't back up. If a developer wants to > do ?XFR over this transport and have others interoperate with them, it will > probably take much less time for them to write the (hopefully very short) > Internet Draft than it will for them to eventually have to debug and patch > their code when someone else makes different assumptions. > > I'm working very hard to keep this in the realm of concrete. There has a been a convincing case that a > 64KB axfr responses uses 2 wireformat records in TCP today and therefore won't fit in the DoH MTI wireformat media type. AIUI that's not because its AXFR, but because it is >64KB, right? At the same time tale convincingly argues he has plenty of <64KB zones that only use one message and match our MTI fine. There are also, admittedly fringe, cases where you can create > 64KB responses not using ?XFR at all. Therefore, match the restriction to what the problem is.. in other words the problem is that the MTI wireformat can only carry 64KB. And then, as I mentioned, its useful to have non-normative text mentioning that ?XFR is of particular concern here. > > Its good to note, non-normatively, that a server that cannot satisfy a > request because of this media type's size restriction can use 413 to signal > that. > > "can use"? "SHOULD use" except in situation X? "MUST use"? > > sorry about suggesting 413 - that's wrong as it is meant to apply to request bodies. We're looking for 406. "HTTP defines status code 406 for cases where the server cannot generate a representation suitable for the client". We can probably just say that. > --Paul Hoffman > > (PS: The above proves that the document authors are not carefully > coordinating their responses off-list...) --000000000000ffd5e4056e528ce0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 10, 2018 at 6:53 PM, Paul Hoffman <paul.hoffman@icann.org= > wrote:
On Jun 10, 2018,= at 4:31 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
>
> I think we can make progress here. I'm pleased to see the text res= tricted to the media type. I don't think it should explicitly restrict = axfr, but rather be about size.
>
> This both makes the reasoning clearer and hits the target more accurat= ely in edge cases (doesn't apply to small axfr and does apply to a huge= rr set of key types and txt records or something). I'm happy if we als= o mention many [ai]xfr require more than one traditional wireformat message= and so won't fit in this media type.

I would rather not mention stuff we can't back up. If a develope= r wants to do ?XFR over this transport and have others interoperate with th= em, it will probably take much less time for them to write the (hopefully v= ery short) Internet Draft than it will for them to eventually have to debug= and patch their code when someone else makes different assumptions.


I'm working very hard= to keep this in the realm of concrete.

There has = a been a convincing case that a > 64KB axfr responses uses 2 wireformat = records in TCP today and therefore won't fit in the DoH MTI wireformat = media type. AIUI that's not because its AXFR, but because it is >64K= B, right? At the same time tale convincingly argues he has plenty of <64= KB zones that only use one message and match our MTI fine.

There are also, admittedly fringe, cases where you can create >= 64KB responses not using ?XFR at all.

Therefore, = match the restriction to what the problem is.. in other words the problem i= s that the MTI wireformat can only carry 64KB.

And then, as I mentioned, its useful to have non-normative text mentioning= that ?XFR is of particular concern here.

=C2= =A0
> Its good to note, non-normatively, that a server that cannot satisfy a= request because of this media type's size restriction can use 413 to s= ignal that.

"can use"? "SHOULD use" except in situation X? &= quot;MUST use"?


sorry about suggesting 413 - that'= s wrong as it is meant to apply to request bodies. We're looking for 40= 6.

"HTTP defines status code 406 for cases wh= ere the server cannot generate a representation suitable for the client&quo= t;. We can probably just say that.


<= div>

=C2=A0
takes their existing code, plops an HTTPS transit on it, and thinks > they're golden. I know Tale thinks I'm worrying about something that > Shouldn't Happen, but I think experience tells us this kind of thing > happens _all the time_ in poorly-constructed DNS implementations. To be clear, I am not saying people don't write bugs. People screw up our modern specs all the time. My point is that I don't see any practical way with unlimited-DoH that legacy DNS software ends up having to deal with wire format over 64k without someone taking an new, affirmative step to code that. If they take that step and are passing it into a function that's ill-equipped to handle it, despite the standard that they're coding against warning them of that very thing, that's a programmer error, not a specification fault. You just said it yourself. Poorly-constructed. Just how much accommodation do we have to make for as-yet-unwritten bad software? From nobody Sun Jun 10 22:15:40 2018 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 8420D130EDF for ; Sun, 10 Jun 2018 22:15:38 -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 uIdXvh85IjUL for ; Sun, 10 Jun 2018 22:15:37 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE3E12F1AC for ; Sun, 10 Jun 2018 22:15:37 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id E3D342AFE5; Mon, 11 Jun 2018 01:15:36 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23326.1400.909022.763497@gro.dd.org> Date: Mon, 11 Jun 2018 01:15:36 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 05:15:39 -0000 Patrick McManus writes: > Therefore, match the restriction to what the problem is.. in other words the > problem is that the MTI wireformat can only carry 64KB. Spit-balling here, but what about two mandatory-to-implement wire format types, with the only difference being that one, dns-message-64k puts a hard cap at 64k, while the other, dns-message(-unlimited)?, has basically a soft cap at 64k for people who are fronting legacy handlers, until such time as that code is, if ever, updated. Yeah I don't expect that to make the people who want the limit very happy either, but there it is. I'm not in love with it, but that seems like the closest thing to a compromise on the issue that I can envision at the moment if a limit really has to be hung on a media type. From nobody Mon Jun 11 02:59:23 2018 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 A5F561292F1 for ; Mon, 11 Jun 2018 02:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 HZNDgoP4Uiy8 for ; Mon, 11 Jun 2018 02:59:19 -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 291BC12777C for ; Mon, 11 Jun 2018 02:59:19 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2AFF528017C; Mon, 11 Jun 2018 11:59:17 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 255EE28051E; Mon, 11 Jun 2018 11:59:17 +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 1E44028017C; Mon, 11 Jun 2018 11:59:17 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 1B2CB6423524; Mon, 11 Jun 2018 11:59:17 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 12E1E401AE; Mon, 11 Jun 2018 11:59:17 +0200 (CEST) Date: Mon, 11 Jun 2018 11:59:17 +0200 From: Stephane Bortzmeyer To: Paul Hoffman Cc: DoH WG Message-ID: <20180611095917.uqylyvcjb54rjc6u@nic.fr> References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> X-Operating-System: Debian GNU/Linux 9.4 X-Kernel: Linux 4.9.0-6-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.000096, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.6.11.94516 Archived-At: Subject: Re: [Doh] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 09:59:22 -0000 On Sun, Jun 10, 2018 at 12:29:20AM +0000, Paul Hoffman wrote a message of 36 lines which said: > Proposal: Alternate proposal, because the original one was not clear to me: 7. Definition of the application/dns-message media type The data payload in this media type is the DNS on-the-wire format defined in section 4.2.1 of [RFC1035]. The format was for DNS over UDP. Although [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", that was later updated by [RFC6891]. This media type restricts the size of the DNS message to 65535 bytes. Note that the wire format used in this media type is different than the wire format used in [RFC7858] (which uses the format defined in section 4.2.2 of [RFC1035]). From nobody Mon Jun 11 07:00:45 2018 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 68411130FF9 for ; Mon, 11 Jun 2018 07:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 Ch5pvg-CBzUH for ; Mon, 11 Jun 2018 07:00:23 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 5CE65130E59 for ; Mon, 11 Jun 2018 07:00:23 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 11 Jun 2018 07:00:21 -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; Mon, 11 Jun 2018 07:00:20 -0700 From: Paul Hoffman To: Stephane Bortzmeyer CC: DoH WG Thread-Topic: [Ext] Re: [Doh] Proposal to close off these threads Thread-Index: AQHUAFITXFbpGMYN9E+e8JcdasUgMqRbSmyAgABDWQA= Date: Mon, 11 Jun 2018 14:00:20 +0000 Message-ID: <49788018-0811-4D95-AB9E-6D96FB603A1F@icann.org> References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180611095917.uqylyvcjb54rjc6u@nic.fr> In-Reply-To: <20180611095917.uqylyvcjb54rjc6u@nic.fr> 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: <68298B8807ECE24DB9FA35C31B7234E8@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Re: Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 14:00:37 -0000 On Jun 11, 2018, at 2:59 AM, Stephane Bortzmeyer wrote: >=20 > On Sun, Jun 10, 2018 at 12:29:20AM +0000, > Paul Hoffman wrote=20 > a message of 36 lines which said: >=20 >> Proposal: >=20 > Alternate proposal, because the original one was not clear to me: >=20 > 7. Definition of the application/dns-message media type >=20 > The data payload in this media type is the DNS on-the-wire format defi= ned > in section 4.2.1 of [RFC1035]. The format was for DNS over UDP. > Although [RFC1035] says > "Messages carried by UDP are restricted to 512 bytes", that was later > updated by [RFC6891]. This media type restricts the size of the DNS > message to 65535 bytes. Note that the wire format used in this media t= ype > is different than the wire format used in [RFC7858] (which uses > the format defined in section 4.2.2 of [RFC1035]). Thanks, this is clearer than what I wrote. --Paul Hoffman= From nobody Mon Jun 11 08:26:08 2018 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 4EE0C130F3A for ; Mon, 11 Jun 2018 08:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 gAzZLowibPfp for ; Mon, 11 Jun 2018 08:26:03 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 E15311277BB for ; Mon, 11 Jun 2018 08:26:03 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 11 Jun 2018 08:26:01 -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; Mon, 11 Jun 2018 08:26:01 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: [Ext] [Doh] Proposal to close off these threads Thread-Index: AQHUAZiAoAyVQiyCOk6ZyfgEqlmFEg== Date: Mon, 11 Jun 2018 15:26:00 +0000 Message-ID: <8E5D4626-6DB3-4168-87E8-717F2CA1DB5D@icann.org> References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <23325.65421.902726.322697@gro.dd.org> In-Reply-To: <23325.65421.902726.322697@gro.dd.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: <7AB3738071171942A7B574C724FFCD64@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:26:07 -0000 Cherry-picking some places to respond to this... > On Jun 10, 2018, at 9:50 PM, Dave Lawrence wrote: >=20 > It's trying to address a legacy issue that hasn't been > demonstrated This feels dismissive of the other developers in the WG who said that they = do see the issue in the code they are writing. You might not see it in the = code you are writing, but that doesn't mean it hasn't been seen. > and instead introduces a new one. It does not introduce a legacy issue: it introduces a restriction for a com= pletely new media type. > DoH is a new tool though that changes nothing at all that happens on > DNS/UDP or DNS/TCP. There is no good reason why legacy code should > end up dealing accidentally with wire format messages larger than 64k > because it doesn't have any standard way of getting them that isn't > the result of new code. Multiple developers on the list have talked about creating gateways. You ar= e correct that there is no standard way to create a DNS transport gateway, = but that's true of nearly every protocol gateway used across the Internet. = The times that the IETF has tried to create standards for gateways have oft= en ended up pretty terribly; ample data is available by looking in the arch= ives of the MIXER and IPP WGs. > A message greater than 64k wouldn't be representable on DNS/UDP or > DNS/TCP? This is an issue that goes back the founding of the DNS; > there's always been the potential for a message to only be fully > available on one transport. Not a new problem. Yes, it is. There were two transports defined with no explicit provision fo= r more. This WG has created a new problem. > Setting a limit on DoH, even constrained to one particular media type, > creates a new legacy problem because if larger messages are eventually > deemed acceptable then you'll have an installed base that all wrote in > a limit per this standard. I posit that even despite Paul's attempt to > make more clear the media type versus the substrate, the chances that > the limit is incorrectly associated as a property of https versus a > property of the media type are high. Developers of other data formats have successfully dealt with differing med= ia types for 25 years. If the DNS folks screw this up worse than everyone e= lse, well, there is nothing we can do about that. I would prefer to think t= hat we can learn from them. > We already expect a new media type, JSON, that will not have natively > have any sense of the size of a DNS wire format encoding by which to > adjudge the propriety of its own encoding. No, we absolutely do not expect a JSON format that has the same capabilitie= s of the wire format. I have tried repeatedly for many years to get interes= t in standardizing one, and there was a complete lack of interest in anythi= ng other than a small subset of DNS messaging. This is well-documented in t= he DNSOP WG archives. > Are we going to hamstring > that too? If not, why not? Because, if it exists, it will be an new media type. Each media type has it= s own rules. There is nothing in current DOH spec that limits what a media = type can do. --Paul Hoffman= From nobody Mon Jun 11 08:54:25 2018 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 6787E130E5F for ; Mon, 11 Jun 2018 08:54:24 -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] 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 dPm81_pgVxKW for ; Mon, 11 Jun 2018 08:54:22 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 0D796130E3B for ; Mon, 11 Jun 2018 08:54:22 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:45172) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fSP98-000giZ-2Z (Exim 4.91) (return-path ); Mon, 11 Jun 2018 16:54:18 +0100 Date: Mon, 11 Jun 2018 16:54:18 +0100 From: Tony Finch To: Patrick McManus cc: Paul Hoffman , DoH WG In-Reply-To: Message-ID: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:54:24 -0000 Patrick McManus wrote: > > There has a been a convincing case that a > 64KB axfr responses uses 2 > wireformat records in TCP today and therefore won't fit in the DoH MTI > wireformat media type. AIUI that's not because its AXFR, but because it is > >64KB, right? At the same time tale convincingly argues he has plenty of > <64KB zones that only use one message and match our MTI fine. It's more complicated than that :-) Small zones can be transferred using multiple messages too. A DoH proxy might be able to defragment a small multi-message transfer, provided there isn't any TSIG authentication. Large zones with more than 64K records must use multiple messages, not because of the 2 byte message size, but because of the 2 byte ANCOUNT. > "HTTP defines status code 406 for cases where the server cannot generate a > representation suitable for the client". We can probably just say that. My DoH server sends a 200 OK HTTP response containing a NOTIMP DNS response. Tony. -- f.anthony.n.finch http://dotat.at/ Bailey, Fair Isle, Faeroes: West or northwest 3 or 4, increasing 5 at times in Fair Isle. Slight or moderate. Rain at times. Good, occasionally moderate. From nobody Mon Jun 11 09:42:13 2018 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 DC335131036 for ; Mon, 11 Jun 2018 09:42:03 -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 WDgkVg5jZzm1 for ; Mon, 11 Jun 2018 09:42:02 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0549D1310CC for ; Mon, 11 Jun 2018 09:42:01 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 4359C32885; Mon, 11 Jun 2018 12:42:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23326.42584.259069.537631@gro.dd.org> Date: Mon, 11 Jun 2018 12:42:00 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: <8E5D4626-6DB3-4168-87E8-717F2CA1DB5D@icann.org> References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <23325.65421.902726.322697@gro.dd.org> <8E5D4626-6DB3-4168-87E8-717F2CA1DB5D@icann.org> Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 16:42:11 -0000 Paul Hoffman writes: > This feels dismissive of the other developers in the WG who said > that they do see the issue in the code they are writing. You might > not see it in the code you are writing, but that doesn't mean it > hasn't been seen. I'm not being dismissive of them. I am observing that I haven't seen a description of a real problem that they have where a message larger than 64k is getting into existing software that isn't a result of new code being written, code which can trivially check to make sure there isn't a problem. I am really quite okay with being corrected on this point, being shown a real, practical problem that exists that is solved by insisting on a limit for all implementations. I am also really quite okay with being gently reminded that such an example has already been provided, so that I can have the opportunity to evaluate it. > It does not introduce a legacy issue: it introduces a restriction > for a completely new media type. I described further down in my message how this creates a new legacy issue, but causing new code to be written with the unnecessary limit and further solidifying the notion that this maximum length is an immutable characteristic of DNS messages. My contention is that even though you're trying to attach it to a specific media type, if that media type is the one-and-only media type that starts off being defined for DoH it will be very easy to programmers to confuse it as an attribute of the transport rather than an attribute of only one media type, leading to deployment problems in the future. > > A message greater than 64k wouldn't be representable on DNS/UDP or > > DNS/TCP? This is an issue that goes back the founding of the DNS; > > there's always been the potential for a message to only be fully > > available on one transport. Not a new problem. > > Yes, it is. There were two transports defined with no explicit > provision for more. This WG has created a new problem. I really don't get how this remark is in disagreement with my assertion. You're disputing that the UDP/TCP DNS already has situations where some messages can only be representable on one (TCP) transport? That's what my remarks were about, that philosophically this is not a new concept and not a technical reason to claim that messages over 64k should be verboten. > > Are we going to hamstring [JSON] too? If not, why not? > > Because, if it exists, it will be an new media type. Each media type > has its own rules. There is nothing in current DOH spec that limits > what a media type can do. I agree with you on that last bit, but it shoots right past the point. If JSON is going to be allowed to carry DNS data that would ultimately represent DNS wire format messages in excess of 64k, then why should an explicitly DNS wire format media type be unnecessarily constrained? I need to use an even more voluminous media type in order to get the large messages that I want? From nobody Mon Jun 11 09:52:06 2018 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 5BD9B13100F for ; Mon, 11 Jun 2018 09:52:04 -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 W1qBnoSdMKj9 for ; Mon, 11 Jun 2018 09:52:03 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EBB130E73 for ; Mon, 11 Jun 2018 09:52:03 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 7E7D532898; Mon, 11 Jun 2018 12:52:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23326.43186.501116.977750@gro.dd.org> Date: Mon, 11 Jun 2018 12:52:02 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> Archived-At: Subject: Re: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 16:52:04 -0000 Mark Nottingham writes: > DNS may very well need a new architecture, but loading this > responsibility onto DOH post-WGLC is asking too much of it, and is > unfair to the folks who brought this work to the IETF in good > faith. With my co-chair hat on, it is absolutely fair for this to be brought now. I say that even as I appear to be in opposition to at least one of the draft authors and on the minority side of consensus, going by a strict counting of the dozen or so people who've offered an opinion on the list. What's genuinely surprising to me is that of all the interesting architectural issues which come along with DoH, it's only message size that caused such debate. It's not quite bike-shedding but it's in rock-throwing distance of it. From nobody Mon Jun 11 13:21:36 2018 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 D6344130EC9 for ; Mon, 11 Jun 2018 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 ripFBdO8EUsc for ; Mon, 11 Jun 2018 13:21:33 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88780130EC4 for ; Mon, 11 Jun 2018 13:21:32 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id AD1859FB55; Mon, 11 Jun 2018 20:21:30 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 4A39CAC621C; Mon, 11 Jun 2018 22:21:30 +0200 (CEST) Date: Mon, 11 Jun 2018 22:21:30 +0200 From: bert hubert To: Dave Lawrence Cc: doh@ietf.org Message-ID: <20180611202130.GA26355@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23326.43186.501116.977750@gro.dd.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 20:21:35 -0000 On Mon, Jun 11, 2018 at 12:52:02PM -0400, Dave Lawrence wrote: > What's genuinely surprising to me is that of all the interesting > architectural issues which come along with DoH, it's only message size > that caused such debate. It's not quite bike-shedding but it's in > rock-throwing distance of it. Perhaps this is at the root (or apex!) of our disagreement. It is relatively harmless to innovate at speed at the outer edge of DNS. Because various people (including me) are now implementing & deploying versions of this draft already, I think we can reasonably conclude that what we are doing is not obviously broken. Worst we can do is deliver a sub-optimal DOH spec. Any changes that impact the core of DNS however have far bigger consequences and will lead to a lot of work down the road. We have not overseen, and in fact can not yet oversee, all the consequences of the existence of newly increased message sizes. This is not what our proxies and experiments are testing at the outer edge of DNS. Specifically, I know we have no defined semantics for what a TCP DNS speaker is supposed to do if it finds it has to truncate a response, nor what anyone on the receiving side should do if it receives such a truncated message. And once large DNS messages can exist, this becomes an issue. I (and many others) consider the existing DNS to be extremely complicated and tricky enough already, and I'd hate to burden it with new dimensions before we have really thought it through. This goes beyond "I don't think there should be problems". It needs the level of "after serious and prolonged thought, we have identified what needs to be done". The entire open source DNS community opined here that they too don't want to go "large dns message" now, and I suspect this is because their spidey sense, like mine, is tingling that trouble and complexity could be ahead - for uncertain gain. So maybe that explains why this part is getting bike-shedded, and many other parts of DOH are not. We worry about core DNS complexity. Bert From nobody Mon Jun 11 14:52:44 2018 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 92B5E131095 for ; Mon, 11 Jun 2018 14:52:34 -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 u7cSQ1BcHjQM for ; Mon, 11 Jun 2018 14:52:30 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163F3130EF7 for ; Mon, 11 Jun 2018 14:52:28 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 17CA532AD0; Mon, 11 Jun 2018 17:52:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23326.61211.72657.945633@gro.dd.org> Date: Mon, 11 Jun 2018 17:52:27 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <20180611202130.GA26355@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> Archived-At: Subject: Re: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 21:52:41 -0000 bert hubert writes: > The entire open source DNS community opined here that they too don't > want to go "large dns message" now, and I suspect this is because > their spidey sense, like mine, is tingling that trouble and > complexity could be ahead - for uncertain gain. > > So maybe that explains why this part is getting bike-shedded, and > many other parts of DOH are not. We worry about core DNS complexity. I hear you, I really do. I don't think it is surprising that someone might worry. I too have concern about the overall health of the DNS ecosystem, and I do not cavalierly make my arguments without regard for it. But spidey sense is not a technical argument, and worry is not a great basis for making decisions. So what do we do when we have vague feelings? Well most analytical computer folks, including you I bet, puzzle it out to find out the root of the issue. So far in my puzzling I've been unable to think of any realistic scenario where the deployed DNS software is at risk here. If there were even one solid example of how this impacts the rest of the DNS, I'd certainly be willing to reconsider my position. And I can certainly see that consensus of the open source DNS community carries a lot of weight. I just want it to be clear, for the list now and for the posterity of the archives, that if that's the way it goes then it was not a technical decision that drove it and it comes with its own set of consequences. From nobody Mon Jun 11 17:36:59 2018 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 C8633130E99 for ; Mon, 11 Jun 2018 17:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 gucEOxzatNBs for ; Mon, 11 Jun 2018 17:36:52 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5A130E7D for ; Mon, 11 Jun 2018 17:36:51 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id 72A723A03D for ; Mon, 11 Jun 2018 20:36:50 -0400 (EDT) Received: by mail-oi0-f48.google.com with SMTP id h79-v6so19533350oig.13 for ; Mon, 11 Jun 2018 17:36:50 -0700 (PDT) X-Gm-Message-State: APt69E26WbVekRwUYCIUZqaV1iqTVRMK9/EZr8m6wZHUU3iFfA1PGKxK zlktNQAmuVWdsXLuv8+NtCn6gKDwTvmj+WPTdb0= X-Google-Smtp-Source: ADUXVKLULOFq327OYASkTs8PK0JunFjNQ4UA3+XGhIQzKvLlIzofveu8K3zlqJWfEbKzrlSOzsgdYfDFsFaJ4DrJm0E= X-Received: by 2002:aca:5c46:: with SMTP id q67-v6mr714306oib.17.1528763810132; Mon, 11 Jun 2018 17:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 17:36:48 -0700 (PDT) In-Reply-To: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> From: Patrick McManus Date: Mon, 11 Jun 2018 17:36:48 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Tony Finch Cc: Patrick McManus , Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="000000000000d93a84056e670f46" Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 00:36:54 -0000 --000000000000d93a84056e670f46 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 11, 2018 at 8:54 AM, Tony Finch wrote: > Patrick McManus wrote: > > > > There has a been a convincing case that a > 64KB axfr responses uses 2 > > wireformat records in TCP today and therefore won't fit in the DoH MTI > > wireformat media type. AIUI that's not because its AXFR, but because it > is > > >64KB, right? At the same time tale convincingly argues he has plenty of > > <64KB zones that only use one message and match our MTI fine. > > It's more complicated than that :-) > > Small zones can be transferred using multiple messages too. > > it doesn't need to be more complicated. The mti wireformat is defined as one message (or if its not - it should be clarified) that might be limited to 64KB. I thought one message was already clear and we were debating the 64KB point. so if you can't meet those constraints, you can't use that media format. but its not inherently about the query type. > "HTTP defines status code 406 for cases where the server cannot generate a > > representation suitable for the client". We can probably just say that. > > My DoH server sends a 200 OK HTTP response containing a NOTIMP DNS > response. > > Personally, I think you're better off with the HTTP error in this case as the problem is with finding a matching HTTP transport. --000000000000d93a84056e670f46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 11, 2018 at 8:54 AM, Tony Finch <dot@dotat.at> wr= ote:
Patrick McManus <= ;pmcmanus@mozilla.com> wrote= :
>
> There has a been a convincing case that a > 64KB axfr responses use= s 2
> wireformat records in TCP today and therefore won't fit in the DoH= MTI
> wireformat media type. AIUI that's not because its AXFR, but becau= se it is
> >64KB, right? At the same time tale convincingly argues he has plen= ty of
> <64KB zones that only use one message and match our MTI fine.

It's more complicated than that :-)

Small zones can be transferred using multiple messages too.


it doesn't need to be more complic= ated. The mti wireformat is defined as one message (or if its not - it shou= ld be clarified) that might be limited to 64KB. I thought one message was a= lready clear and we were debating the 64KB point.

<= div>so if you can't meet those constraints, you can't use that medi= a format. but its not inherently about the query type.


> "HTTP defines status code 406 for cases where the server cannot g= enerate a
> representation suitable for the client". We can probably just say= that.

My DoH server sends a 200 OK HTTP response containing a NOTIMP DNS r= esponse.


Personally, I think you're better off with the H= TTP error in this case as the problem is with finding a matching HTTP trans= port.

--000000000000d93a84056e670f46-- From nobody Mon Jun 11 18:06:32 2018 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 ED8B6130EAB for ; Mon, 11 Jun 2018 18:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 X8c1HUC0c1OP for ; Mon, 11 Jun 2018 18:06:28 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8DF130DC3 for ; Mon, 11 Jun 2018 18:06:28 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id A47DE3A03B for ; Mon, 11 Jun 2018 21:06:27 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id f79-v6so19599146oib.7 for ; Mon, 11 Jun 2018 18:06:27 -0700 (PDT) X-Gm-Message-State: APt69E3F4C/bH14ZMzvzn5OX5rOYl0iHIJX0f7zE04nVSlyjsNLnC1uv qDq7VoLDbTVOj+hVIvm3v8OMfdOrq7sk4BzTCus= X-Google-Smtp-Source: ADUXVKKWzm25acj3Dz2bRZtig/otrwqKBbxoJ4OvQwWQ/1upwbzxAMnrhTibYisbpFAomTeqvVEPXNVhRwLHNiKCDcs= X-Received: by 2002:aca:41d6:: with SMTP id o205-v6mr847202oia.38.1528765587384; Mon, 11 Jun 2018 18:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 18:06:26 -0700 (PDT) In-Reply-To: <23326.61211.72657.945633@gro.dd.org> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> From: Patrick McManus Date: Mon, 11 Jun 2018 18:06:26 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Dave Lawrence Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000c7f273056e67799f" Archived-At: Subject: Re: [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 01:06:30 -0000 --000000000000c7f273056e67799f Content-Type: text/plain; charset="UTF-8" On Mon, Jun 11, 2018 at 2:52 PM, Dave Lawrence wrote: > > > If there were even one solid example of how this impacts the rest of > the DNS, I'd certainly be willing to reconsider my position. This is my position as well. I'm willing to make minor accommodations here based on the use of a 2 byte message framing length when using wireformat over TCP. I've concluded that is evidence that the wireformat is expected to have no single message be more than 16 bits in length (TCP routinely uses more than one message, and could have chosen a 32bit framing after all). One of the things DoH does is define a media type for the classic wireformat so it should be consistent with the classic definition of that.. unfortunately sometimes these things have to be reverse engineered and ambiguity leads to disagreement. However, the scope of that evidence is limited to a single wireformat message. Its not limited to particularly query types, or alternative media types, or multipart-schemes, etc.. And I > can certainly see that consensus of the open source DNS community > carries a lot of weight. I just want it to be clear, for the list now > and for the posterity of the archives, that if that's the way it goes > then it was not a technical decision that drove it and it comes with > its own set of consequences. > > If it is not a technical decision, then it is not consensus. RFC 7282 is pretty helpful in this regard. Obviously, there is still a generous dollop of "technical is in the eye of the beholder". But I'm hopeful we can come to a technical resolution - you're right imo to keep pushing through the general concerns to get to specifics. That makes it easier for everyone. -Patrick --000000000000c7f273056e67799f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 11, 2018 at 2:52 PM, Dave Lawrence <tale@dd.org> w= rote:


If there were even one solid example of how this impacts the rest of
the DNS, I'd certainly be willing to reconsider my position.=C2=A0

This is my position as well. I'm willing to= make minor accommodations here based on the use of a 2 byte message framin= g length when using wireformat over TCP. I've concluded that is evidenc= e that the wireformat is expected to have no single message be more than 16= bits in length (TCP routinely uses more than one message, and could have c= hosen a 32bit framing after all). One of the things DoH does is define a me= dia type for the classic wireformat so it should be consistent with the cla= ssic definition of that.. unfortunately sometimes these things have to be r= everse engineered and ambiguity leads to disagreement.

However, the scope of that evidence is limited to a single wirefor= mat message. Its not limited to particularly query types, or alternative me= dia types, or multipart-schemes, etc..

And I
can certainly see that consensus of the open source DNS community
carries a lot of weight.=C2=A0 I just want it to be clear, for the list now=
and for the posterity of the archives, that if that's the way it goes then it was not a technical decision that drove it and it comes with
its own set of consequences.

=C2=A0
If it is not a technical decision, then it is not consensus. R= FC 7282 is pretty helpful in this regard. Obviously, there is still a gener= ous dollop of "technical is in the eye of the beholder".

But I'm ho= peful we can come to a technical resolution - you're right imo to keep = pushing through the general concerns to get to specifics. That makes it eas= ier for everyone.

-Patrick


--000000000000c7f273056e67799f-- From nobody Mon Jun 11 18:51:18 2018 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 49093130DD1 for ; Mon, 11 Jun 2018 18:51:14 -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 AfuU6Y5d4G4a for ; Mon, 11 Jun 2018 18:51:11 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D3F130DC3 for ; Mon, 11 Jun 2018 18:51:11 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 11 Jun 2018 18:51:09 -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; Mon, 11 Jun 2018 18:51:09 -0700 From: Paul Hoffman To: David C Lawrence CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) Thread-Index: AQHUAe/VzBhdNBCRWEK8i8XD7rRPGQ== Date: Tue, 12 Jun 2018 01:51:09 +0000 Message-ID: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> In-Reply-To: <23326.61211.72657.945633@gro.dd.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 01:51:14 -0000 On Jun 11, 2018, at 2:52 PM, Dave Lawrence wrote: > If there were even one solid example of how this impacts the rest of > the DNS, I'd certainly be willing to reconsider my position. Great! Let me try again. The DNS message format is defined specifically for two transports. Looking = at the format without looking at the transports, one can imagine a message = that cannot be carried in either format. However, the original specificatio= ns and all the ones since have always treated the message format as being h= andled in one of the two transports. When we define a new transport that allows messages different than the ones= we have always assumed, gatewaying those different messages will be differ= ent than gatewaying between the two current transports and thus have an imp= act on the rest of the DNS. The WG charter we are working under clearly says: Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group. Creating new queries, to me, seems "beyond normal DNS queries". --Paul Hoffman= From nobody Tue Jun 12 06:31:55 2018 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 21CC0130E27 for ; Tue, 12 Jun 2018 06:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 G_cWDreLPNOb for ; Tue, 12 Jun 2018 06:31:47 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 EF174130E3C for ; Tue, 12 Jun 2018 06:31:46 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39464) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fSjOj-000WsB-ct (Exim 4.91) (return-path ); Tue, 12 Jun 2018 14:31:45 +0100 Date: Tue, 12 Jun 2018 14:31:44 +0100 From: Tony Finch To: Patrick McManus cc: Paul Hoffman , DoH WG In-Reply-To: Message-ID: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 13:31:51 -0000 Patrick McManus wrote: > it doesn't need to be more complicated. The mti wireformat is defined as > one message (or if its not - it should be clarified) that might be limited > to 64KB. I thought one message was already clear and we were debating the > 64KB point. I was talking about how to handle query meta-types rather than response sizes. My point was that there are several reasons an AXFR or IXFR query can break the single message requirement. > so if you can't meet those constraints, you can't use that media format. > but its not inherently about the query type. I think I would prefer it if the client could predict the response media type based on the query, rather than the server choosing a media type based on criteria outside the client's control. This is a programmer interface so I think predictability is more important than DWIMmery. > > > "HTTP defines status code 406 for cases where the server cannot generate a > > > representation suitable for the client". We can probably just say that. > > > > My DoH server sends a 200 OK HTTP response containing a NOTIMP DNS > > response. > > Personally, I think you're better off with the HTTP error in this case as > the problem is with finding a matching HTTP transport. I don't think that is supported by the current draft text: it explicitly says that DNS errors should be returned as 200 OK application/dns-message responses, and there's no other defined media type that we're failing to negotiate. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Northerly or northwesterly 4 or 5, occasionally 6 in east. Slight or moderate. Fair. Good. From nobody Tue Jun 12 10:23:20 2018 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 527A4130FA2 for ; Tue, 12 Jun 2018 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 kqCHtNlPEH_0 for ; Tue, 12 Jun 2018 10:23:06 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id A8DF3130E06 for ; Tue, 12 Jun 2018 10:23:06 -0700 (PDT) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by linode64.ducksong.com (Postfix) with ESMTPSA id 1732B3A059 for ; Tue, 12 Jun 2018 13:23:06 -0400 (EDT) Received: by mail-ot0-f171.google.com with SMTP id l15-v6so27977036oth.6 for ; Tue, 12 Jun 2018 10:23:06 -0700 (PDT) X-Gm-Message-State: APt69E14zVhCY17XtXWX6+jbRV/RZYwTd5C+XE2BL8Ga2bTQx2SWki3l j5YfdmaHoqGxsQsaUxNk5SDgkPe9phOS0yXCkyQ= X-Google-Smtp-Source: ADUXVKJhaiJLbfRs6v6k5CzKLcATLIL4RlA6VgMdlkEEQuV2B/ODVzJqWd2eyAPbE/fi2DOVFpPrgM/KElt6W65soB4= X-Received: by 2002:a9d:419c:: with SMTP id p28-v6mr970155ote.2.1528824185799; Tue, 12 Jun 2018 10:23:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 10:23:05 -0700 (PDT) In-Reply-To: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> From: Patrick McManus Date: Tue, 12 Jun 2018 10:23:05 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Tony Finch Cc: Patrick McManus , Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="00000000000084cb2f056e751edd" Archived-At: Subject: Re: [Doh] [Ext] Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 17:23:16 -0000 --00000000000084cb2f056e751edd Content-Type: text/plain; charset="UTF-8" On Tue, Jun 12, 2018 at 6:31 AM, Tony Finch wrote: > > I don't think that is supported by the current draft text: it explicitly > says that DNS errors should be returned as 200 OK application/dns-message > responses, and there's no other defined media type that we're failing to > negotiate. > we're more aligned that you think :) DNS errors should indeed be 2xx responses (the draft doesn't specify the media type, correctly) I would just argue that the situation you are describing is a HTTP error, not a DNS one. Let's assume a response that requires multiple messages - you've got that information at the DNS layer, you just can't encode transport it at the HTTP layer using a media type the client can understand. So that's an http level failure. --00000000000084cb2f056e751edd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 12, 2018 at 6:31 AM, Tony Finch <dot@dotat.at> wr= ote:

I don't think that is supported by the current draft text: it ex= plicitly
says that DNS errors should be returned as 200 OK application/dns-message responses, and there's no other defined media type that we're faili= ng to
negotiate.

we're more ali= gned that you think :)

DNS errors should indeed be= 2xx responses (the draft doesn't specify the media type, correctly)

I would just argue that the situation you are descri= bing is a HTTP error, not a DNS one. Let's assume a response that requi= res multiple messages - you've got that information at the DNS layer, y= ou just can't encode transport it at the HTTP layer using a media type = the client can understand. So that's an http level failure.
<= br>

--00000000000084cb2f056e751edd-- From nobody Tue Jun 12 14:46:55 2018 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 024D8130EAA for ; Tue, 12 Jun 2018 14:46:51 -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 MqSyG4l6zVEJ for ; Tue, 12 Jun 2018 14:46:48 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91667130F39 for ; Tue, 12 Jun 2018 14:46:46 -0700 (PDT) Received: from [88.212.170.147] (port=60469 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fSr7h-0001Ol-J1 (Exim 4.72) for doh@ietf.org (return-path ); Tue, 12 Jun 2018 22:46:41 +0100 To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> From: Ray Bellis Message-ID: <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> Date: Tue, 12 Jun 2018 22:46:44 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 21:46:52 -0000 On 12/06/2018 02:51, Paul Hoffman wrote: > The DNS message format is defined specifically for two transports. > Looking at the format without looking at the transports, one can > imagine a message that cannot be carried in either format. However, > the original specifications and all the ones since have always > treated the message format as being handled in one of the two > transports. > > When we define a new transport that allows messages different than > the ones we have always assumed, gatewaying those different messages > will be different than gatewaying between the two current transports > and thus have an impact on the rest of the DNS. I do think it would be helpful to consider in more detail where DOH is expected to sit in the DNS architecture. Is it going to be a new "first class" transport (sic) protocol, or is it merely a tunneling protocol for carrying DNS messages whose sole purpose is to provide interworking for those that cannot use the "normal" transport protocols because either a) there's a stoopid middlebox in the way, or b) they're a web client ? Ray From nobody Tue Jun 12 15:02:19 2018 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 8FA98130FAC for ; Tue, 12 Jun 2018 15:02:16 -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 z7FfXyDsmFUe for ; Tue, 12 Jun 2018 15:02:13 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A1E130FC4 for ; Tue, 12 Jun 2018 15:02:13 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.237.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 86C30533; Tue, 12 Jun 2018 18:01:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Tom Pusateri In-Reply-To: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> Date: Tue, 12 Jun 2018 18:02:11 -0400 Cc: David C Lawrence , "doh@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <485A5830-9799-4ED5-B884-CEDB27040544@bangj.com> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 22:02:17 -0000 > On Jun 11, 2018, at 9:51 PM, Paul Hoffman = wrote: >=20 > On Jun 11, 2018, at 2:52 PM, Dave Lawrence wrote: >> If there were even one solid example of how this impacts the rest of >> the DNS, I'd certainly be willing to reconsider my position. >=20 > Great! Let me try again. >=20 > The DNS message format is defined specifically for two transports. = Looking at the format without looking at the transports, one can imagine = a message that cannot be carried in either format. However, the original = specifications and all the ones since have always treated the message = format as being handled in one of the two transports. >=20 > When we define a new transport that allows messages different than the = ones we have always assumed, gatewaying those different messages will be = different than gatewaying between the two current transports and thus = have an impact on the rest of the DNS. >=20 > The WG charter we are working under clearly says: > Specification of how DNS-formatted data may be used for use cases = beyond > normal DNS queries is out of scope for the working group. > Creating new queries, to me, seems "beyond normal DNS queries". >=20 > --Paul Hoffman If there is an uncertainty about how DoH will interact with existing = message sizes, then this can be alleviated by having DoH use the TCP = wire format instead of the UDP wire format. While the two byte length = prepend is not necessary for HTTP, it will prevent the unknown = translations that some people seem to be concerned about. Then a future media type can be defined in another spec to handle larger = messages. Tom From nobody Tue Jun 12 15:19:12 2018 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 C29CA130FDF for ; Tue, 12 Jun 2018 15:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 aeEJlwuux5ii for ; Tue, 12 Jun 2018 15:19:05 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 9D712130EE8 for ; Tue, 12 Jun 2018 15:19:05 -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, 12 Jun 2018 15:19:03 -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, 12 Jun 2018 15:19:03 -0700 From: Paul Hoffman To: Ray Bellis CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) Thread-Index: AQHUApbj6sr7HpgoCUqfpeUX7P+jQqRdpuYA Date: Tue, 12 Jun 2018 22:19:03 +0000 Message-ID: <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> In-Reply-To: <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> 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: <289DDDA2E449D24BBD31C8B429D252DC@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 22:19:07 -0000 On Jun 12, 2018, at 2:46 PM, Ray Bellis wrote: > I do think it would be helpful to consider in more detail where DOH is > expected to sit in the DNS architecture. This is the DNS: "is expected" almost always turns out to be wrong. (No smi= ley appended.) The same can be said for HTTP. > Is it going to be a new "first class" transport (sic) protocol, or is it > merely a tunneling protocol for carrying DNS messages whose sole purpose > is to provide interworking for those that cannot use the "normal" > transport protocols because either a) there's a stoopid middlebox in the > way, or b) they're a web client ? These are good questions, but if we try to base our protocol on what "is ex= pected" and our expectations turn out to be wrong, we will probably design = the protocol badly.=20 --Paul Hoffman= From nobody Tue Jun 12 21:10:45 2018 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 ED9A0130DD8 for ; Tue, 12 Jun 2018 21:10:41 -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 7w-QFg1GpRA8 for ; Tue, 12 Jun 2018 21:10:38 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B387130DD0 for ; Tue, 12 Jun 2018 21:10:38 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 0CB0B2F692; Wed, 13 Jun 2018 00:10:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23328.39227.27444.258030@gro.dd.org> Date: Wed, 13 Jun 2018 00:10:35 -0400 From: Dave Lawrence To: "doh\@ietf.org" In-Reply-To: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 04:10:43 -0000 Paul Hoffman writes: > On Jun 11, 2018, at 2:52 PM, Dave Lawrence wrote: > > If there were even one solid example of how this impacts the rest of > > the DNS, I'd certainly be willing to reconsider my position. > > Great! Let me try again. > > The DNS message format is defined specifically for two > transports. Looking at the format without looking at the transports, > one can imagine a message that cannot be carried in either > format. However, the original specifications and all the ones since > have always treated the message format as being handled in one of > the two transports. > > When we define a new transport that allows messages different than > the ones we have always assumed, gatewaying those different messages > will be different than gatewaying between the two current transports > and thus have an impact on the rest of the DNS. We appear to be two technical geeks separated by a common language. I'm not sure where either my phrasing has gone wrong or I have not understood yours. In either case I apologize for my failing. What I am looking for is a concrete example of how any pre-DoH clients or servers are is going to have any sort of problem if a DoH DNS wire format message exceeds 64k -- a specific mechanism for specific old software that will react badly to an unexpectedly large message being fed to it, where it hasn't gotten there as a result of new code that could easily prevent it. This is the sort of concern that we've had to worry about in the past with the DNS and for which we did have concrete answers about implementations that would have issues with a non-zero ADCOUNT in a request or the semantics of a KEY RR changing or using compressible names in rdata of new types or so on. All of those things impacted messages that existing servers would see. As far as I can tell there is no way that the pre-DoH DNS/UDP and DNS/TCP world can even be aware of the existence of DoH and its potentially 64k+1 messages because nothing at all is being changed for the messages that the existing code sends and receives. You could spin up a BIND 4 instance in a world of unlimited-DoH and it would still work just as it always did. The generalized gateway examples you give don't challenge this. The DNS/UDP an DNS/TCP network are still not impacted; they weren't able to carry messages greater than 64k before, and they still won't after. No change to their inputs, their outputs, or their behaviour. I believe that makes not imposing a 64k limit on DNS fall within the bounds of the charter. In fact, I could make a case that it goes right to the first paragraph: This working group will standardize encodings for DNS queries and responses that are suitable for use in HTTPS. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems. ... in addressing cases where existing methods experience problems. I'm not going to get too hung up on rules-lawyering that argument though, it's a sideshow. Per our out-of-band conversation, I will later this week (new $dayjob intrudes) be offering text for the proposal I made in another message about using two mandatory-to-implement media types right out of the gate, differing only in that one has a Content-Length limit. Implementers can then choose to make it plainly explicit that they are sticking to legacy TCP limits. From nobody Tue Jun 12 21:17:58 2018 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 A0FD9130DE2 for ; Tue, 12 Jun 2018 21:17:54 -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 7_RY0obdeMfq for ; Tue, 12 Jun 2018 21:17:51 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E7F130E5F for ; Tue, 12 Jun 2018 21:17:51 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id D4CCE2F69A; Wed, 13 Jun 2018 00:17:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23328.39662.854936.357114@gro.dd.org> Date: Wed, 13 Jun 2018 00:17:50 -0400 From: Dave Lawrence To: doh@ietf.org In-Reply-To: <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 04:17:55 -0000 Ray Bellis writes: > I do think it would be helpful to consider in more detail where DOH is > expected to sit in the DNS architecture. > > Is it going to be a new "first class" transport (sic) protocol, or is it > merely a tunneling protocol for carrying DNS messages whose sole purpose > is to provide interworking for those that cannot use the "normal" > transport protocols because either a) there's a stoopid middlebox in the > way, or b) they're a web client ? There's no way you'll be able to keep the genie in the bottle of "merely a tunneling protocol". There are already indications from people who want to leverage it to provide DNS response delivery without involving the traditional resolution path. Some of them stated quite clearly at the first DoH BoF that they really weren't even interested in working on it if it was just going to be merely a tunneling protocol. It isn't clear to me how you could meaningfully restrict it from being a "'first class' transport". Fiat declaration sure wouldn't do it. From nobody Wed Jun 13 02:59:49 2018 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 109AF130E14 for ; Wed, 13 Jun 2018 02:59:47 -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 1l_mXhNfiRuL for ; Wed, 13 Jun 2018 02:59:44 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678D8130E0A for ; Wed, 13 Jun 2018 02:59:44 -0700 (PDT) Received: from [88.212.170.147] (port=62791 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fT2Z3-0004fn-Eb (Exim 4.72) for doh@ietf.org (return-path ); Wed, 13 Jun 2018 10:59:41 +0100 To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <23328.39662.854936.357114@gro.dd.org> From: Ray Bellis Message-ID: <157c9cfb-ed84-4635-9c67-f9726adfccce@bellis.me.uk> Date: Wed, 13 Jun 2018 10:59:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <23328.39662.854936.357114@gro.dd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:59:47 -0000 On 13/06/2018 05:17, Dave Lawrence wrote: > There are already indications from people who want to leverage it to > provide DNS response delivery without involving the traditional > resolution path. Can you elaborate? I don't know what that means. > It isn't clear to me how you could meaningfully restrict it from being > a "'first class' transport". Fiat declaration sure wouldn't do it. To be a first class transport IMHO it would have to update STD13. Ray From nobody Wed Jun 13 03:16:09 2018 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 B86AB130EB2 for ; Wed, 13 Jun 2018 03:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 xwaHX_nM5pa4 for ; Wed, 13 Jun 2018 03:16:05 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CF1130EAC for ; Wed, 13 Jun 2018 03:16:04 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 138749FB55 for ; Wed, 13 Jun 2018 10:16:01 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id EF7BFAC5F94; Wed, 13 Jun 2018 12:16:00 +0200 (CEST) Date: Wed, 13 Jun 2018 12:16:00 +0200 From: bert hubert To: doh@ietf.org Message-ID: <20180613101600.GB14462@server.ds9a.nl> References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <23328.39662.854936.357114@gro.dd.org> <157c9cfb-ed84-4635-9c67-f9726adfccce@bellis.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157c9cfb-ed84-4635-9c67-f9726adfccce@bellis.me.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 10:16:07 -0000 On Wed, Jun 13, 2018 at 10:59:42AM +0100, Ray Bellis wrote: > > It isn't clear to me how you could meaningfully restrict it from being > > a "'first class' transport". Fiat declaration sure wouldn't do it. > > To be a first class transport IMHO it would have to update STD13. Indeed. This would then also have to define TCP TC=1 behaviour and how resolvers need to then use the third first-class transport called DOH. It makes little sense to tell everyone they can use this protocol but leave the semantics of inevitable downstream effects of its use undefined. If there were no downstream effects, for example if we restrict the protocol to <65535 bytes, life would be a lot easier. Bert From nobody Wed Jun 13 06:04:36 2018 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 52DCB130E29 for ; Wed, 13 Jun 2018 06:04:34 -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 dmfhf0l1ZZIf for ; Wed, 13 Jun 2018 06:04:31 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5E7130DCA for ; Wed, 13 Jun 2018 06:04:30 -0700 (PDT) Received: from [88.212.170.147] (port=64516 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fT5Rr-0008IY-Kz (Exim 4.72) for doh@ietf.org (return-path ); Wed, 13 Jun 2018 14:04:27 +0100 To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <23328.39662.854936.357114@gro.dd.org> <157c9cfb-ed84-4635-9c67-f9726adfccce@bellis.me.uk> <20180613101600.GB14462@server.ds9a.nl> From: Ray Bellis Message-ID: Date: Wed, 13 Jun 2018 14:04:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180613101600.GB14462@server.ds9a.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 13:04:34 -0000 On 13/06/2018 11:16, bert hubert wrote: > Indeed. This would then also have to define TCP TC=1 behaviour and how > resolvers need to then use the third first-class transport called DOH. which would then effectively become Mandatory To Implement, otherwise someone's going to start provisioning RRsets that are illegal over TCP and UDP and only capable of being carried in DoH. This is getting dangerously close into "get off our lawn" territory. Ray From nobody Wed Jun 13 06:28:54 2018 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 655FF130E2A for ; Wed, 13 Jun 2018 06:28:52 -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] 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 csYVZs6swZRz for ; Wed, 13 Jun 2018 06:28:49 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 2ED2F12777C for ; Wed, 13 Jun 2018 06:28:49 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:41431) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fT5pO-000nht-gt (Exim 4.91) (return-path ); Wed, 13 Jun 2018 14:28:46 +0100 Date: Wed, 13 Jun 2018 14:28:46 +0100 From: Tony Finch To: Patrick McManus cc: Paul Hoffman , DoH WG In-Reply-To: Message-ID: References: <1D917C05-2B74-4607-9EE2-55D367FF48B5@icann.org> <20180610220841.GB16671@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] meta-types, was Re: Proposal to close off these threads X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 13:28:53 -0000 Patrick McManus wrote: > > I would just argue that the situation you are describing is a HTTP error, > not a DNS one. Let's assume a response that requires multiple messages - > you've got that information at the DNS layer, you just can't encode > transport it at the HTTP layer using a media type the client can > understand. So that's an http level failure. The reason I think it's a DNS-level error is that AXFR and IXFR are just examples of the more general problem of query meta-types. The DNS machinery needs special-case code to handle a meta-type: if it's a proxy it won't (in general) be able to parse the response it gets from upstream; if it's an integrated DoH server, it won't even know how to begin generating a response. So the problem occurs at DNS query dispatch time, well before it gets to the point of thinking about rendering the response for HTTP. My code looks at the qtype and generates a DNS error if it is an unknown meta-type (128 <= qtype <= 254). There are similar considerations for DNS opcodes. Tony. -- f.anthony.n.finch http://dotat.at/ promote human rights and open government From nobody Wed Jun 13 10:47:48 2018 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 CA0A4130F6D for ; Wed, 13 Jun 2018 10:47:45 -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 8ecNKuvALbY6 for ; Wed, 13 Jun 2018 10:47:43 -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 DD852130F6C for ; Wed, 13 Jun 2018 10:47:42 -0700 (PDT) Received: from [172.20.6.227] (unknown [172.20.6.227]) by mail.nic.cz (Postfix) with ESMTPSA id 986D6601B2 for ; Wed, 13 Jun 2018 19:47:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1528912060; bh=xlWVUxSgWVAdaLnTEsZJtBNmFOLKkCJYuUkEtt2FCy0=; h=To:From:Date; b=bWrvTa6nT5kYr05/cAwrBcSgAPfGtqz5BtWKUpRR8mWLwZ9Xa8hwk74QBApPdNTaH MIotTBhyIZqSc1CI+FWtlAjQIys5hkcIkCOQK09rNA38KoAXIIF3qUEx5ZWZVH9yf0 IbxR1KO/O585CCWHcpnNUr3a4Gj1OIePlLRo70tk= To: doh@ietf.org References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> Date: Wed, 13 Jun 2018 19:47:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> Content-Type: text/plain; charset=utf-8; format=flowed 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] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 17:47:46 -0000 On 13.6.2018 00:19, Paul Hoffman wrote: > On Jun 12, 2018, at 2:46 PM, Ray Bellis wrote: >> I do think it would be helpful to consider in more detail where DOH is >> expected to sit in the DNS architecture. > > This is the DNS: "is expected" almost always turns out to be wrong. (No smiley appended.) > > The same can be said for HTTP. > >> Is it going to be a new "first class" transport (sic) protocol, or is it >> merely a tunneling protocol for carrying DNS messages whose sole purpose >> is to provide interworking for those that cannot use the "normal" >> transport protocols because either a) there's a stoopid middlebox in the >> way, or b) they're a web client ? > > These are good questions, but if we try to base our protocol on what "is expected" and our expectations turn out to be wrong, we will probably design the protocol badly. I think Ray was too shy to ask The Question: Is the goal of the current doh WG a) "standardize encodings for DNS queries and responses that are suitable for use in HTTPS. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an interoperable way, i.e. doing a thing the WG was chartered to do? OR b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the original DNS protocol? We badly need DNS 2.0 so let's admit that, it is not a shame. If the answer is b) then I will applaud and support doh doing DNS 2.0, we only need to stop pretending that current doh work is just a new transport for the original DNS. My reading of the doh charter is that doh protocol is a transport which should help to get the existing DNS to endpoints. Changes beyond existing DNS semantics are work on DNS 2.0 and thus outside of current doh charter. I strongly support work on DNS 2.0 but we must not pretend that it is still the original DNS with minor tweaks, and recharter doh to admit that. Clean cut will make all discussions about "what happens if there is a dumb proxy" moot because it will be clear to everyone that "doh is going to be DNS 2.0". Or even better, let's use a new name for the new protocol: HTTP naming system (HNS) and do not confuse everyone with references to the legacy DNS. Can we get consensus call to answer what doh WG participants want to do? a) just do new transport for the existing DNS OR b) invent "HTTP naming system" without the burden of legacy DNS (HNS == DNS 2.0) Can we get clear answers to this question? Pretty please! -- Petr Špaček @ CZ.NIC From nobody Wed Jun 13 11:16:30 2018 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 CF10D130F75 for ; Wed, 13 Jun 2018 11:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 k3inRfZ6eoom for ; Wed, 13 Jun 2018 11:16:24 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 823D8130F69 for ; Wed, 13 Jun 2018 11:16:24 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id d22-v6so4403775iof.13 for ; Wed, 13 Jun 2018 11:16:24 -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=fogyiRmCpjTi6OlbZUkseOc8KzAGfqTCtYgTgrelY8c=; b=LpyFrUBRiC+bBvs6w8tTC3+x1hbgR4aXSeoCwdkkZoKNBlAEi30e60xqQdJuymNrIX 0epAyhdGCbmieIPiDJYbkTY+990pHRjRdapzL2Lm+ESdQZN82v1AoUaM2xoi9Ie26Jo6 +zyl1X4cDt1JV307zmNst99mrr8zwCDuNw58v46erKOQOuxJ6r76qzGz4z3od4w1AZSp JQHcPFwnwZNu61Mih5l9TWmJ4bYEF8y3IfyDGGCUvAG8Kjf1g48aPQg2+AvGON6cC38Q NTHiAuTVbjdjsRXXhPlw1gIWVyIT3gmdzf8npeNEXrTjjNHLX/3jSphkLuTJxqAA7PDh SlgA== 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=fogyiRmCpjTi6OlbZUkseOc8KzAGfqTCtYgTgrelY8c=; b=mbC5XZqZNi9a2L6f9GcSXAtsI0XSQY6YCiSEoeDOQmX9zLBdTOvfmaz4E1LRiTUwY5 pLQkMqrCoaG07FH6k3/QFXOo3VGOlitIew0lkfakQCV02fSetWlwkNTSp8BZLVMfums1 D49zzYz8COBN5KKN5V5kZJtuAUJCs/n0hBNgLKRYcm9YiQAV9fwxfK8FHJNf+6Y9lt9M fUrjzPmFFdvLnAU2lZso2Bc19y2rH3ssG4Tp+W69VcdsV6XXOQ5bZhdM16pO2gIcQKSM wUwhbw7I6LXICuKoKspC5SjNCA5GeRNaSul9jGrSReAsw58mMgehzxqFK2+Se6kIEnYj WJLQ== X-Gm-Message-State: APt69E3zXXuYOV9AHWMjhoaj+DnWkRU7coRrv/nQaFXzt+zmlbTzcY65 iy/DAuv8GVt36XzFSzk6eK41nWsuEspQ8C2g2CCJOTbbXc8= X-Google-Smtp-Source: ADUXVKLTQ8obXnHvu/NGs9k7mVCuYaeCzyvw+A4evnEC5G7VPcLQO0L0noDhLfMOkmy6pRc4rHB7QxaK+kTMq6gubpM= X-Received: by 2002:a6b:df45:: with SMTP id d5-v6mr5461123iop.230.1528913783425; Wed, 13 Jun 2018 11:16:23 -0700 (PDT) MIME-Version: 1.0 References: <20180606093212.GA23880@server.ds9a.nl> <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> In-Reply-To: <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> From: Ben Schwartz Date: Wed, 13 Jun 2018 14:16:11 -0400 Message-ID: To: petr.spacek@nic.cz Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000fe0f25056e89fa4e" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 18:16:28 -0000 --000000000000fe0f25056e89fa4e Content-Type: multipart/alternative; boundary="000000000000f4d187056e89faef" --000000000000f4d187056e89faef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2018 at 1:47 PM Petr =C5=A0pa=C4=8Dek = wrote: > On 13.6.2018 00:19, Paul Hoffman wrote: > > On Jun 12, 2018, at 2:46 PM, Ray Bellis wrote: > >> I do think it would be helpful to consider in more detail where DOH is > >> expected to sit in the DNS architecture. > > > > This is the DNS: "is expected" almost always turns out to be wrong. (No > smiley appended.) > > > > The same can be said for HTTP. > > > >> Is it going to be a new "first class" transport (sic) protocol, or is = it > >> merely a tunneling protocol for carrying DNS messages whose sole purpo= se > >> is to provide interworking for those that cannot use the "normal" > >> transport protocols because either a) there's a stoopid middlebox in t= he > >> way, or b) they're a web client ?functional > > > > These are good questions, but if we try to base our protocol on what "i= s > expected" and our expectations turn out to be wrong, we will probably > design the protocol badly. > > I think Ray was too shy to ask The Question: > > Is the goal of the current doh WG > > a) "standardize encodings for DNS queries and responses > that are suitable for use in HTTPS. This will enable the domain name > system to function over certain paths where existing DNS methods (UDP, > TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an > interoperable way, i.e. doing a thing the WG was chartered to do? > > OR > > b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the > original DNS protocol? We badly need DNS 2.0 so let's admit that, it is > not a shame. > I appreciate your concern but please try to avoid accusing members of the working group of trying to hide anything. The question of what message size limits to require or recommend does not resemble an attempt at any kind of "DNS 2.0". Note that message size interoperability questions are not a new issue within the DNS: many endpoints will reject messages larger than 4K or 8K, even though there is no way to signal this limitation. HTTP has similar issues (e.g. URL length limits). The charter does not require that the standard guarantee functionality in all possible use cases and multi-system interactions, and both choices (to apply a limit or not) fail to serve a desirable use case: either we don't support 100% reliable gateways from DoH into DNS-over-TCP, or we don't support large zone transfers over DoH. It's up to the working group to balance these concerns, either by choosing one option or by finding a middle ground. So far, I've heard two middle-ground proposals: a new media type for >64K DNS messages, or usage of multipart/related to deliver multiple DNS messages in a DoH response. I hope the working group will seriously consider these proposals, or other ways to satisfy both of the desired use cases above. > If the answer is b) then I will applaud and support doh doing DNS 2.0, > we only need to stop pretending that current doh work is just a new > transport for the original DNS. > > My reading of the doh charter is that doh protocol is a transport which > should help to get the existing DNS to endpoints. Changes beyond > existing DNS semantics are work on DNS 2.0 and thus outside of current > doh charter. > > I strongly support work on DNS 2.0 but we must not pretend that it is > still the original DNS with minor tweaks, and recharter doh to admit that= . > > Clean cut will make all discussions about "what happens if there is a > dumb proxy" moot because it will be clear to everyone that "doh is going > to be DNS 2.0". > > Or even better, let's use a new name for the new protocol: > HTTP naming system (HNS) > and do not confuse everyone with references to the legacy DNS. > > > > Can we get consensus call to answer what doh WG participants want to do? > > a) just do new transport for the existing DNS > OR > b) invent "HTTP naming system" without the burden of legacy DNS > (HNS =3D=3D DNS 2.0) > > Can we get clear answers to this question? Pretty please! > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000f4d187056e89faef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Jun 13, 2018 at 1:47 PM Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:
On 13.6.2018 00:19, Paul= Hoffman wrote:
> On Jun 12, 2018, at 2:46 PM, Ray Bellis <ray@bellis.me.uk> wrote:
>> I do think it would be helpful to consider in more detail where DO= H is
>> expected to sit in the DNS architecture.
>
> This is the DNS: "is expected" almost always turns out to be= wrong. (No smiley appended.)
>
> The same can be said for HTTP.
>
>> Is it going to be a new "first class" transport (sic) pr= otocol, or is it
>> merely a tunneling protocol for carrying DNS messages whose sole p= urpose
>> is to provide interworking for those that cannot use the "nor= mal"
>> transport protocols because either a) there's a stoopid middle= box in the
>> way, or b) they're a web client ?functional
>
> These are good questions, but if we try to base our protocol on what &= quot;is expected" and our expectations turn out to be wrong, we will p= robably design the protocol badly.

I think Ray was too shy to ask The Question:

Is the goal of the current doh WG

a) "standardize encodings for DNS queries and responses
that are suitable for use in HTTPS. This will enable the domain name
system to function over certain paths where existing DNS methods (UDP,
TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an
interoperable way, i.e. doing a thing the WG was chartered to do?

OR

b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the original DNS protocol? We badly need DNS 2.0 so let's admit that, it is=
not a shame.

I appreciate your concern = but please try to avoid accusing members of the working group of trying to = hide anything.

The question of what message size l= imits to require or recommend does not resemble an attempt at any kind of &= quot;DNS 2.0".=C2=A0 Note that message size interoperability questions= are not a new issue within the DNS: many endpoints will reject messages la= rger than 4K or 8K, even though there is no way to signal this limitation.= =C2=A0 HTTP has similar issues (e.g. URL length limits).

The charter does not require that the standard guarantee functionali= ty in all possible use cases and multi-system interactions, and both choice= s (to apply a limit or not) fail to serve a desirable use case: either we d= on't support 100% reliable gateways from DoH into DNS-over-TCP, or we d= on't support large zone transfers over DoH.=C2=A0 It's up to the wo= rking group to balance these concerns, either by choosing one option or by = finding a middle ground.

So far, I've heard tw= o middle-ground proposals: a new media type for >64K DNS messages, or us= age of multipart/related to deliver multiple DNS messages in a DoH response= .=C2=A0 I hope the working group will seriously consider these proposals, o= r other ways to satisfy both of the desired use cases above.

=

If the answer is b) then I will applaud and support doh doing DNS 2.0,
we only need to stop pretending that current doh work is just a new
transport for the original DNS.

My reading of the doh charter is that doh protocol is a transport which should help to get the existing DNS to endpoints. Changes beyond
existing DNS semantics are work on DNS 2.0 and thus outside of current
doh charter.

I strongly support work on DNS 2.0 but we must not pretend that it is
still the original DNS with minor tweaks, and recharter doh to admit that.<= br>
Clean cut will make all discussions about "what happens if there is a =
dumb proxy" moot because it will be clear to everyone that "doh i= s going
to be DNS 2.0".

Or even better, let's use a new name for the new protocol:
HTTP naming system (HNS)
and do not confuse everyone with references to the legacy DNS.



Can we get consensus call to answer what doh WG participants want to do?
a) just do new transport for the existing DNS
OR
b) invent "HTTP naming system" without the burden of legacy DNS (HNS =3D=3D DNS 2.0)

Can we get clear answers to this question? Pretty please!

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

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000f4d187056e89faef-- --000000000000fe0f25056e89fa4e 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAVrDbHDJTyHjrrrT+3rKA3 Yeg2hyN/bvGn6kkpDMgE2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA2MTMxODE2MjRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAi9bSoc7tzVUGdZxrU9N25FTQdZKyZxpi3t8wc47v 8gpB0dSy0FOdn0VY5+Qf+KaRsSTJwyNL/c3omqvulW1Mnacu3SgpDD/YfO1F4fzsPeE6sS21W/Af nfleMM1cBBc/DSiGuBk96Q5YajCy8lzgGra/36Q7EXQBMvK+ECV2zchpPGEIYWQ12K2cgrBN+L6a kKwZobsMTMJM9cFoG522/p8Ij0I0QhYz5RF6MkZNG4rCWWa55M0rj/5Vao+m4OCxU9f02JNcmb5G slbiHXReTT0pp40gdBb5oXL5Xn/g1/0+AQ6ktmt4pj24r+dFbsQABScxCr+mv2w0Jvp+tFo76A== --000000000000fe0f25056e89fa4e-- From nobody Wed Jun 13 12:20:46 2018 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 5697612426A for ; Wed, 13 Jun 2018 12:20: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, 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 hmGoiK0WN3a9 for ; Wed, 13 Jun 2018 12:20:42 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id E737F130E8A for ; Wed, 13 Jun 2018 12:20:41 -0700 (PDT) Received: from jurassic (unknown [14.194.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 5E54532C0972; Wed, 13 Jun 2018 19:20:36 +0000 (UTC) Date: Thu, 14 Jun 2018 00:50:30 +0530 From: Mukund Sivaraman To: Ben Schwartz Cc: petr.spacek@nic.cz, DoH WG Message-ID: <20180613192030.GA2792@jurassic> References: <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:20:45 -0000 On Wed, Jun 13, 2018 at 02:16:11PM -0400, Ben Schwartz wrote: > > I think Ray was too shy to ask The Question: > > > > Is the goal of the current doh WG > > > > a) "standardize encodings for DNS queries and responses > > that are suitable for use in HTTPS. This will enable the domain name > > system to function over certain paths where existing DNS methods (UDP, > > TLS [RFC 7857], and DTLS [RFC 8094]) experience problems." in an > > interoperable way, i.e. doing a thing the WG was chartered to do? > > > > OR > > > > b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the > > original DNS protocol? We badly need DNS 2.0 so let's admit that, it is > > not a shame. > > > > I appreciate your concern but please try to avoid accusing members of the > working group of trying to hide anything. It's a valid question that has been asked. Many of us are concerned about things are being said and it's best to discuss them freely without taking offense. This is from Tale's post: > There are already indications from people who want to leverage it to > provide DNS response delivery without involving the traditional > resolution path. Some of them stated quite clearly at the first DoH > BoF that they really weren't even interested in working on it if it > was just going to be merely a tunneling protocol. > > It isn't clear to me how you could meaningfully restrict it from being > a "'first class' transport". Fiat declaration sure wouldn't do it. This may well fit in within current DoH charter or may not, depending on how "existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems" from the charter is interpreted. Is this a replacement for traditional DNS? (there's no need to take offense at this question.. please let's just discuss it.) The 64kB limit is just one aspect (we've been asked for proof of problems - it has been explained already that DNS message parsers do it in memory currently - 64kB imposes an implicit upper limit on the derived objects in in-memory message structures (lists of names + RDATA objects). E.g., a 32-bit limit would mean the possibility of requiring to hold 4GB wire data in memory and the larger derived structs from parsing it, or, reimplementing message parsing with disk storage. (Think of sax vs. DOM XML parsing for an analogy.) > The question of what message size limits to require or recommend does not > resemble an attempt at any kind of "DNS 2.0". Note that message size > interoperability questions are not a new issue within the DNS: many > endpoints will reject messages larger than 4K or 8K, even though there is > no way to signal this limitation. HTTP has similar issues (e.g. URL length > limits). Implementators are concerned because this 64kB limit has been assumed forever now and various parts of code aren't written or even designed to handle larger sizes. I don't know how you mean by "endpoints will reject messages larger than 4k".. I think any of the popular open source DNS nameservers will parse 64kB messages over TCP (though some may not generate > 16kB messages as name compression pointers have a limit of 16kB from the start). > The charter does not require that the standard guarantee functionality in > all possible use cases and multi-system interactions, and both choices (to > apply a limit or not) fail to serve a desirable use case: either we don't > support 100% reliable gateways from DoH into DNS-over-TCP, or we don't > support large zone transfers over DoH. It's up to the working group to > balance these concerns, either by choosing one option or by finding a > middle ground. The charter says: "The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS clients (e.g., operating system stub resolvers) and recursive resolvers." and "Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group." and we're talking about zone transfers. Zone transfers are not DNS queries. So what's the limit of this charter? Large zone transfers are supported today using TCP continuation messages and the same can be encoded by DoH within the 64kB message limit. FWIW, even we don't use larger than 16kB messages for zone transfers in traditional DNS because it doesn't compress well, though there is a 64kB budget. If DoH is purely an encoding transport to carry traditional DNS messages, then there will be a problem with larger than 64kB messages from: (1) tradtional NS -> (2) trad:DoH intermediate using 1MB messages -> (3) DoH client and: (1) DoH NS using 1MB messages -> (2) DoH/trad intermediate -> (3) traditional client because TSIG will not validate if only (1) has the secret to generate them and (2) is just a forwarder. A person like me is wondering about these things, because I don't know what's the limit for DoH - how all it will be used, because of everything that's being discussed. It appears that DoH will not be restricted, so before rushing to update things, please discuss traditional DNS's concerns, and also discuss what's within scope in the charter. As an exercise, it'd be good to read about several practial usage patterns in which DoH may be used. Mukund From nobody Wed Jun 13 12:30:24 2018 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 3780E130F15 for ; Wed, 13 Jun 2018 12:30:21 -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 2qcTPMz78pZj for ; Wed, 13 Jun 2018 12:30:20 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 02D6E130E87 for ; Wed, 13 Jun 2018 12:30:20 -0700 (PDT) Received: from jurassic (unknown [14.194.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 0364732C0972; Wed, 13 Jun 2018 19:30:16 +0000 (UTC) Date: Thu, 14 Jun 2018 01:00:11 +0530 From: Mukund Sivaraman To: Ben Schwartz Cc: petr.spacek@nic.cz, DoH WG Message-ID: <20180613193011.GB2792@jurassic> References: <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180613192030.GA2792@jurassic> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:30:21 -0000 On Thu, Jun 14, 2018 at 12:50:30AM +0530, Mukund Sivaraman wrote: > and we're talking about zone transfers. Zone transfers are not DNS > queries. So what's the limit of this charter? Before someone pedantically points out this, AXFRs are sent as DNS QUERY but they're not a DNS query in the layman's sense and the charter isn't talking about the opcode. :P Mukund From nobody Wed Jun 13 12:44:02 2018 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 AE840130E91 for ; Wed, 13 Jun 2018 12:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 7DN7jsnPJDbA for ; Wed, 13 Jun 2018 12:43:57 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 9DF36130E87 for ; Wed, 13 Jun 2018 12:43:57 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id a3-v6so5570851itd.0 for ; Wed, 13 Jun 2018 12:43:57 -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=Ts6Gdrbm38qPkRuf890GBfRiezTJ0KNTRkfXpAgPomA=; b=LDofmQW30DQSk5StZnCGMxXAI+zma6l+Zw9B+/CRjZb7nco4A++sLHfDVmNUc8h8j6 l5AhNmrZpGDGSOrYdykX58iR25kwrXxjNvtPeKDVy2uJHx6dQ/VcxE2PWkhHu7ty+7FT epCmOlDRpMYE5lccsfIO+wDxoZfaF/UxUB6Fq0UlnWeEOgWmJR7uSzG7EbvHNLrzXZTQ C7/53fj36TbTf3VMlpb0ypVmxmvKpJGeANV4Ghawx3PeS3mJL2V2ibiNljYuI4brFXgh DucY6ET4chy+JWZvRRzV20KoWhIt0ZF9K3C4iSsh298qTq7J64Qp1mGeXfdrrZdz6/63 uUvg== 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=Ts6Gdrbm38qPkRuf890GBfRiezTJ0KNTRkfXpAgPomA=; b=eG4poMIbNmUXbXMKC7+5afSbMHfU0KnxJR4Debt2E3+h83Jo77+oYrL3SkxZ6AyyTi 94Yr9H9Q8bjOwXLLm2MgEyw5q0pOsyG2PEKNWKwHM8G/MPLc0sLTPhYlST6y9ZHVP9Yx DnVPAJGd9wxHi7Y6Ty82PC+Qtyd1e2Ha7ueCxLnfkE6sN7gk9CvGIYWWsBMmx3pRWYEA 6iIyMMjGRq825ofbcVAwXzp4YE0Koxp6YRoQUscmZFICTD2Phq5r1oyAY4Joy/VkOHoo iyQlWLu/t+q8YfsG5EzhBplpnv1Zh2GchRVgDTLR+BG2KY8eHVVlQNl1mXb4iEFmR9sf G4KQ== X-Gm-Message-State: APt69E2kB2jhkIGRpOsiWU9WZV+U1kAGn/pk4voSJIuvl9whXi00lyKZ 7k6BsIZCkNq99G3lSh6hZ7rccwLUmmhG6vZT5VWkbf2Bng8= X-Google-Smtp-Source: ADUXVKLDYyvjhjzY0UG5W6JiFpqQi4UMahkRucLy/6HpswXwfhlrn2E+5QmzKmG/d4jUK5a/Osol4NKC/XKzQI9U2/E= X-Received: by 2002:a02:4187:: with SMTP id n7-v6mr966494jad.86.1528919036510; Wed, 13 Jun 2018 12:43:56 -0700 (PDT) MIME-Version: 1.0 References: <20180608170744.GY11227@mx4.yitter.info> <03DC5A73-4BAD-45FE-AC60-C8BC82FD5690@mnot.net> <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> In-Reply-To: <20180613192030.GA2792@jurassic> From: Ben Schwartz Date: Wed, 13 Jun 2018 15:43:44 -0400 Message-ID: To: muks@mukund.org Cc: petr.spacek@nic.cz, DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000018e965056e8b34d5" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:44:00 -0000 --00000000000018e965056e8b34d5 Content-Type: multipart/alternative; boundary="0000000000001065b0056e8b34ec" --0000000000001065b0056e8b34ec Content-Type: text/plain; charset="UTF-8" Snipped to focus on one technical point. On Wed, Jun 13, 2018 at 3:20 PM Mukund Sivaraman wrote: > Large zone transfers are supported today using TCP continuation messages > and the same can be encoded by DoH within the 64kB message limit. This is currently not true, because each DoH query must return at most a single DNS message in the response. Therefore, there is no way to make use of continuation messages in DoH. I think this is a major reason why we are having this conversation: lack of continuation messages renders DoH strictly less expressive than standard DNS, which is a concern for gateway applications. Before someone pedantically points out this, AXFRs are sent as DNS QUERY > but they're not a DNS query in the layman's sense and the charter isn't > talking about the opcode. :P > Without veering into charter interpretation, I agree that supporting AXFR is distinctly lower priority than typical client-recursive queries. However, some working group participants believe that it would be valuable, so it's worth considering if there is a reasonable way to include support for it, or to leave open the possibility of future support. --0000000000001065b0056e8b34ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Snipped to focus on one technical point.

On Wed, Jun 13, 2018 at 3:20 PM Mukund Si= varaman <muks@mukund.org> wrot= e:
Large zone transfers are support= ed today using TCP continuation messages
and the same can be encoded by DoH within the 64kB message limit.

This is currently not true, because each DoH query m= ust return at most a single DNS message in the response.=C2=A0 Therefore, t= here is no way to make use of continuation messages in DoH.=C2=A0 I think t= his is a major reason why we are having this conversation: lack of continua= tion messages renders DoH strictly less expressive than standard DNS, which= is a concern for gateway applications.

Before someone pedantically points out this, AXFRs are= sent as DNS QUERY
but they're not a DNS query= in the layman's sense and the charter isn't
talking about the opcode. :P

= Without veering into charter interpretation, I agree that supporting AXFR i= s distinctly lower priority than typical client-recursive queries.=C2=A0 Ho= wever, some working group participants believe that it would be valuable, s= o it's worth considering if there is a reasonable way to include suppor= t for it, or to leave open the possibility of future support.
--0000000000001065b0056e8b34ec-- --00000000000018e965056e8b34d5 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB7ZSiUKE9CHvHNeq/438/f 0Ng4dCtE+93Oa1LAergEozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA2MTMxOTQzNTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAtWQjysC6G+VzQh39R1qDmGk87vTYvEt+4mH6tYVC qX6ymQ1ETfBe8OOpFOzy01x3Fsl6MsJc5ypkzfMUH9meTKJhgA/tBEDChTA8J8rPQoeteQ6E4Ba7 VwIOFuVSJxvs6n+gHSO5Ne9BjOBGqqvIsBSE6b3QJ8aK3ba0ov8wcfnAEZ9S96cRyR0BktSlAyC0 Nlm1OzKAJ+CBJPzMGzSVfB0xsS1fpOMxpzzdjSKTeYdEoMLw1J+kcAhOziXDIsVhjhB4nxX5Q4hW jLEyVBOunE+0kh4YWmsPGD+uJjrkaJ7A9fNOB5vqqFqV+ecdcT7tld+ahyZ1fQ5dZJOCkQ1Ekw== --00000000000018e965056e8b34d5-- From nobody Wed Jun 13 13:56:51 2018 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 EE124130F6F for ; Wed, 13 Jun 2018 13:56: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=unavailable 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 UvDrNH44T9uf for ; Wed, 13 Jun 2018 13:56:46 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD68130F7E for ; Wed, 13 Jun 2018 13:56:46 -0700 (PDT) Received: from jurassic (unknown [14.194.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id E724332C0972; Wed, 13 Jun 2018 20:56:42 +0000 (UTC) Date: Thu, 14 Jun 2018 02:26:37 +0530 From: Mukund Sivaraman To: Ben Schwartz Cc: petr.spacek@nic.cz, DoH WG Message-ID: <20180613205637.GA23215@jurassic> References: <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 20:56:50 -0000 On Wed, Jun 13, 2018 at 03:43:44PM -0400, Ben Schwartz wrote: > Snipped to focus on one technical point. > > On Wed, Jun 13, 2018 at 3:20 PM Mukund Sivaraman wrote: > > > Large zone transfers are supported today using TCP continuation messages > > and the same can be encoded by DoH within the 64kB message limit. > > > This is currently not true, because each DoH query must return at most a > single DNS message in the response. Therefore, there is no way to make use > of continuation messages in DoH. I think this is a major reason why we are > having this conversation: lack of continuation messages renders DoH > strictly less expressive than standard DNS, which is a concern for gateway > applications. I meant it can be encoded by DoH within the 64kB limit as multiple messages by using a multi-part scheme, instead of extending the DNS message size. If the above is the concern, then this is the most interoperable way. Changing DNS message boundaries isn't always doable. Let me also be the devil's advocate. If the idea is to have more flexible DNS messages that modern parsers can parse and reframe for traditional DNS, why limit ourselves? Throw away the DNS message format with redundant owner names of individual RRs, possibility of TTL mismatch within RRset, no defined ordering of RRs, which has become horrible already with hacks like OPT, and other things that make parsing horrible. Make a clean new message format that encodes and decodes from traditional DNS message format. I'd prefer that to increasing the message size which is neither here nor there. > Before someone pedantically points out this, AXFRs are sent as DNS QUERY > > but they're not a DNS query in the layman's sense and the charter isn't > > talking about the opcode. :P > > > > Without veering into charter interpretation, I agree that supporting AXFR > is distinctly lower priority than typical client-recursive queries. > However, some working group participants believe that it would be valuable, > so it's worth considering if there is a reasonable way to include support > for it, or to leave open the possibility of future support. On the topic of charter, my interpretation on reading it is that DoH will be used to configure a stub resolver when other traditional DNS transports are tried and will not work, as a means to keep things going. DoH is not even an RFC yet and there has been an announcement from Mozilla that by default all its DNS queries will be sent to Cloudflare via DoH, and this is the default behavior that's all within the Firefox application. Is anybody else concerned about the Firefox DoH announcement? Apart from the privacy implications, the fact that a browser used by millions with a large market share is switching suddenly to a new protocol at the application layer, that nobody except one or a handful of cloud providers are ready for is unnerving. It seems to be the first major use and it seems quite different from the charter of DoH. Who is this serving? What will be some typical patterns of using DoH? Is DoH a fallback to a transport when traditional DNS won't work, or is it supposed to become the new way of doing DNS, i.e., DNS 2.0? The concerns about what the purpose of DoH is and how it compares to traditional DNS are not unjustified. Mukund From nobody Wed Jun 13 14:59:08 2018 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 8986A130E97 for ; Wed, 13 Jun 2018 14:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 Nyu5yS4kHwEL for ; Wed, 13 Jun 2018 14:59:03 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3C7130E96 for ; Wed, 13 Jun 2018 14:59:03 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 388DE3A05C for ; Wed, 13 Jun 2018 17:59:02 -0400 (EDT) Received: by mail-oi0-f46.google.com with SMTP id a141-v6so3795194oii.8 for ; Wed, 13 Jun 2018 14:59:02 -0700 (PDT) X-Gm-Message-State: APt69E1gzCtW9FBxWxOc0ujCrwtzaGygr/MJ9u8MbCeTTM1V2hRR+aBP OitMs7jauhV1MSo53MHUoce75aPp7T+yzFcDOFI= X-Google-Smtp-Source: ADUXVKIIzUKs9Trra1KcNFr+78rzX9desDRtCjSMtmb7oKSAKX7cWZOisZRsjrtMeYwBDdB5XHDZbT7QKjrvMd7YEuk= X-Received: by 2002:aca:41d6:: with SMTP id o205-v6mr5634744oia.38.1528927141895; Wed, 13 Jun 2018 14:59:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 14:59:01 -0700 (PDT) In-Reply-To: <20180613205637.GA23215@jurassic> References: <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> From: Patrick McManus Date: Wed, 13 Jun 2018 14:59:01 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Mukund Sivaraman Cc: Ben Schwartz , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , DoH WG Content-Type: multipart/alternative; boundary="0000000000002e22a1056e8d17ba" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 21:59:06 -0000 --0000000000002e22a1056e8d17ba Content-Type: text/plain; charset="UTF-8" > DoH is not even an RFC yet and there has been an announcement from > Mozilla that by default all its DNS queries will be sent to Cloudflare > via DoH, and this is the default behavior that's all within the Firefox > application. Is anybody else concerned about the Firefox DoH > announcement? > > You are overstating the announcement greatly. We're running some fairly small experiments to see how this works. It has gotten a bit more publicity than something at this scale normally does because its important to let impacted users know how their data flow is changing - that's all. I hope it makes for a better protocol. This is part of the process of data driven decision making. sometimes known as running code - and it makes for successful protocols when the IETF does it right. I'm happy to say that open standards are an important part of our mission and we're confident that we won't accidentally create defacto standards from Internet Drafts - that's something we think carefully about and have done well managing with HTTP and TLS over the last few years (of which we have shipped dozes on draft versions to much bigger populations in service of creating the final consensus product) and I'm confident we'll be fine aligning with the final DoH as well. on the other hand, as I've told the HTTP WG on many occasions: this forum is for open standards, its not the room I make product specific decisions in (nor would I expect other participants to negotiate their product decisions with me). -Patrick --0000000000002e22a1056e8d17ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
DoH is not even an RFC yet and there has been an announcement from
Mozilla that by default all its DNS queries will be sent to Cloudflare
via DoH, and this is the default behavior that's all within the Firefox=
application. Is anybody else concerned about the Firefox DoH
announcement?


You are overstating the announcement g= reatly. We're running some fairly small experiments to see how this wor= ks. It has gotten a bit more publicity than something at this scale normall= y does because its important to let impacted users know how their data flow= is changing - that's all. I hope it makes for a better protocol.

This is part of the process of data driven decision= making. sometimes known as running=C2=A0 code - and it makes for successfu= l protocols when the IETF does it right. I'm happy to say that open sta= ndards are an important part of our mission and we're confident that we= won't accidentally create defacto standards from Internet Drafts - tha= t's something we think carefully about and have done well managing with= HTTP and TLS over the last few years (of which we have shipped dozes on dr= aft versions to much bigger populations in service of creating the final co= nsensus product) and I'm confident we'll be fine aligning with the = final DoH as well.

on the other hand, as I'= ;ve told the HTTP WG on many occasions: this forum is for open standards, i= ts not the room I make product specific decisions in (nor would I expect ot= her participants to negotiate their product decisions with me).
<= br>
-Patrick




--0000000000002e22a1056e8d17ba-- From nobody Wed Jun 13 15:02:09 2018 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 DE901130FBF for ; Wed, 13 Jun 2018 15:02:05 -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 uGYV4-hP6Zas for ; Wed, 13 Jun 2018 15:02:04 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A318130E97 for ; Wed, 13 Jun 2018 15:02:04 -0700 (PDT) Received: from [88.212.170.147] (port=51155 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fTDq3-0003W1-8p (Exim 4.72) for doh@ietf.org (return-path ); Wed, 13 Jun 2018 23:01:59 +0100 To: doh@ietf.org References: <23326.43186.501116.977750@gro.dd.org> <20180611202130.GA26355@server.ds9a.nl> <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> From: Ray Bellis Message-ID: <1f3a8e0b-93bc-f0bf-38e5-988b4c71e98b@bellis.me.uk> Date: Wed, 13 Jun 2018 23:02:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 22:02:06 -0000 On 13/06/2018 22:59, Patrick McManus wrote: > This is part of the process of data driven decision making. Here's some data for you. If Mozilla does go this route and makes this behaviour the default, I'll never run Firefox again. no cheers, Ray From nobody Wed Jun 13 21:22:33 2018 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 3DBB5131063 for ; Wed, 13 Jun 2018 21:22:30 -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 keWDNSNp0rDH for ; Wed, 13 Jun 2018 21:22:28 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0213105D for ; Wed, 13 Jun 2018 21:22:27 -0700 (PDT) Received: from jurassic (unknown [49.203.216.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 7D6D132C09D5; Thu, 14 Jun 2018 04:22:25 +0000 (UTC) Date: Thu, 14 Jun 2018 09:52:17 +0530 From: Mukund Sivaraman To: Patrick McManus Cc: Ben Schwartz , Petr =?utf-8?B?xaBwYcSNZWs=?= , DoH WG Message-ID: <20180614042217.GA25915@jurassic> References: <23326.61211.72657.945633@gro.dd.org> <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 04:22:31 -0000 Hi Patrick On Wed, Jun 13, 2018 at 02:59:01PM -0700, Patrick McManus wrote: > > DoH is not even an RFC yet and there has been an announcement from > > Mozilla that by default all its DNS queries will be sent to Cloudflare > > via DoH, and this is the default behavior that's all within the Firefox > > application. Is anybody else concerned about the Firefox DoH > > announcement? > > > > > You are overstating the announcement greatly. We're running some fairly > small experiments to see how this works. It has gotten a bit more publicity > than something at this scale normally does because its important to let > impacted users know how their data flow is changing - that's all. I hope it > makes for a better protocol. > > This is part of the process of data driven decision making. sometimes known > as running code - and it makes for successful protocols when the IETF does > it right. I'm happy to say that open standards are an important part of our > mission and we're confident that we won't accidentally create defacto > standards from Internet Drafts - that's something we think carefully about > and have done well managing with HTTP and TLS over the last few years (of > which we have shipped dozes on draft versions to much bigger populations in > service of creating the final consensus product) and I'm confident we'll be > fine aligning with the final DoH as well. > > on the other hand, as I've told the HTTP WG on many occasions: this forum > is for open standards, its not the room I make product specific decisions > in (nor would I expect other participants to negotiate their product > decisions with me). The questions aren't about Firefox explaining its decision or its usage of protocol. The questions are about DoH enabling this, what its purpose is. Until this announcement, I used to view DoH as a way to make DNS service available where existing secure stub->resolver protocols such as DNS over TLS and dnscrypt don't work. It seems DoH may be used as the means to bypass traditional DNS completely, where answers are not obtained via the system configuration of stub. It may be justified (and surely this is possible using traditional DNS as well), but let's see some descriptions of how DoH is expected to be used. On re-reading the charter, it appears someone had thought about all this which isn't apparent on a naive reading. It would help participation, get to more consensus if the usage patterns are better understood. Mukund From nobody Wed Jun 13 21:41:20 2018 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 3C15513102F for ; Wed, 13 Jun 2018 21:41:19 -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 0C4qzTxWPILq for ; Wed, 13 Jun 2018 21:41:18 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 22224130DDD for ; Wed, 13 Jun 2018 21:41:18 -0700 (PDT) Received: from jurassic (unknown [49.203.216.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 4139C32C09D5; Thu, 14 Jun 2018 04:41:16 +0000 (UTC) Date: Thu, 14 Jun 2018 10:11:13 +0530 From: Mukund Sivaraman To: Patrick McManus Cc: Ben Schwartz , Petr =?utf-8?B?xaBwYcSNZWs=?= , DoH WG Message-ID: <20180614044113.GA27115@jurassic> References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180614042217.GA25915@jurassic> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 04:41:20 -0000 On Thu, Jun 14, 2018 at 09:52:17AM +0530, Mukund Sivaraman wrote: > It would help participation, get to more consensus if the usage patterns > are better understood. As an implementer, it is unclear where this is all going, which is what I'm curious about over DoH. If there's more description of different usage patterns, we can better plan how it would fit in our projects. The switch to DoH at the application layer seems suddenly upon us. I was thinking of DoH just as a fallback transport, but suddenly it seems almost like this is the new way to do DNS queries (a switch). (Musing.. why did we even spend any time on DNS over TLS if this is more or less the same thing?) Mukund From nobody Thu Jun 14 01:14:58 2018 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 CA0FD130EA5 for ; Thu, 14 Jun 2018 01:14:55 -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=unavailable 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 iQaD1kfI-l3E for ; Thu, 14 Jun 2018 01:14:51 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 25B4112F1AC for ; Thu, 14 Jun 2018 01:14:50 -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 w5E8EjHp011254 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Jun 2018 10:14:45 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w5E8EiNM011247; Thu, 14 Jun 2018 10:14:44 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 14 Jun 2018 10:14:44 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mukund Sivaraman cc: Patrick McManus , Ben Schwartz , =?ISO-8859-2?Q?Petr_=A9pa=E8ek?= , DoH WG In-Reply-To: <20180614044113.GA27115@jurassic> Message-ID: References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 08:14:56 -0000 On Thu, 14 Jun 2018, Mukund Sivaraman wrote: > The switch to DoH at the application layer seems suddenly upon us. I was > thinking of DoH just as a fallback transport, but suddenly it seems almost > like this is the new way to do DNS queries (a switch). Users have wanted (and used) "name resolving in the application" layer since a long time in various situations. The fact that the standard operating system APIs make this hard has never taken away the desire or will for a lot of solutions to be able to ask their *preferred* resolvers. Why shouldn't applications be able to decide this? 1. DOH doesn't really change this property and 2. there's no DOH support in any system name resolver functions yet so there's no way to do DOH other than "yourself" at this point. DOH is just a protocol to deliver DNS data. It can be used in several ways. -- / daniel.haxx.se From nobody Thu Jun 14 07:01:01 2018 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 3C022131163 for ; Thu, 14 Jun 2018 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NrLh_SvYwEOw for ; Thu, 14 Jun 2018 07:00:57 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 91315131160 for ; Thu, 14 Jun 2018 07:00:57 -0700 (PDT) Received: from [62.232.251.194] (port=5090 helo=[192.168.12.23]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fTSnu-0006x7-C6; Thu, 14 Jun 2018 15:00:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sara Dickinson In-Reply-To: Date: Thu, 14 Jun 2018 15:00:24 +0100 Cc: Mukund Sivaraman , Ben Schwartz , DoH WG , =?utf-8?B?UGV0ciDFoHBhxI1law==?= , Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> To: Daniel Stenberg X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 14:01:00 -0000 > On 14 Jun 2018, at 09:14, Daniel Stenberg wrote: >=20 > On Thu, 14 Jun 2018, Mukund Sivaraman wrote: >=20 >> The switch to DoH at the application layer seems suddenly upon us. I = was thinking of DoH just as a fallback transport, but suddenly it seems = almost like this is the new way to do DNS queries (a switch). >=20 > Users have wanted (and used) "name resolving in the application" layer = since a long time in various situations. The fact that the standard = operating system APIs make this hard has never taken away the desire or = will for a lot of solutions to be able to ask their *preferred* = resolvers. Why shouldn't applications be able to decide this? Applications are free to decide it but it is not without consequences, = for example: 1) Many enterprises rely on using internal views for DNS from servers = provided by DHCP. If applications override this by _default_ then that = model completely breaks internal name resolution _and_ leaks internal = queries to the external resolver. Some might consider that a loss of = security and privacy.=20 2) By =E2=80=98users=E2=80=99 above I think you mean =E2=80=98application = developers=E2=80=99 not =E2=80=98actual end users=E2=80=99? While their = may be good reasons for application developers to want to do this I = would postulate that actual end users who understand enough about DNS to = want to control it would prefer to have a single system setting to = configure it to point at _their_ preferred resolver, rather than a = (transport/DNSSEC/resolver) setting existing in every individual = application.=20 I=E2=80=99m not saying there is a right or wrong model here, just that = there are more concerns than simply what the application prefers.=20 Sara.=20 From nobody Thu Jun 14 07:10:06 2018 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 B855513115B for ; Thu, 14 Jun 2018 07:09:55 -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 cYo1cJ4kB2BO for ; Thu, 14 Jun 2018 07:09:50 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id C782C13116D for ; Thu, 14 Jun 2018 07:09:49 -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 w5EE9kgu023298 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Jun 2018 16:09:46 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w5EE9jep023294; Thu, 14 Jun 2018 16:09:45 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 14 Jun 2018 16:09:45 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Sara Dickinson cc: =?ISO-8859-2?Q?Petr_=A9pa=E8ek?= , Ben Schwartz , DoH WG , Patrick McManus , Mukund Sivaraman In-Reply-To: <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> Message-ID: References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1129329158-2137643623-1528985385=:29598" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 14:10:03 -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-2137643623-1528985385=:29598 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 14 Jun 2018, Sara Dickinson wrote: > I’m not saying there is a right or wrong model here, just that there are > more concerns than simply what the application prefers. Sure. And I'm saying they already existed since long before and are independent of DOH. -- / daniel.haxx.se --1129329158-2137643623-1528985385=:29598-- From nobody Thu Jun 14 07:38:44 2018 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 A825712777C for ; Thu, 14 Jun 2018 07:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OLn6yZS97j_V for ; Thu, 14 Jun 2018 07:38:40 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 859B1130E46 for ; Thu, 14 Jun 2018 07:38:39 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=50899) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fTTOU-0001nN-3A; Thu, 14 Jun 2018 15:38:38 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sara Dickinson In-Reply-To: Date: Thu, 14 Jun 2018 15:38:32 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> To: Daniel Stenberg X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 14:38:43 -0000 > On 14 Jun 2018, at 15:09, Daniel Stenberg wrote: >=20 > On Thu, 14 Jun 2018, Sara Dickinson wrote: >=20 >> I=E2=80=99m not saying there is a right or wrong model here, just = that there are more concerns than simply what the application prefers. >=20 > Sure. And I'm saying they already existed since long before and are = independent of DOH. I don't disagree (note I did not mention DoH at all in my response). I = was replying to the generic question =E2=80=9CWhy shouldn=E2=80=99t = application be able to decide to use their own preferred resolvers=E2=80=9D= . But it is also true to say that prior to DoH applications that made that = choice were the _exception_ and not the norm, whereas it seems highly = likely that many applications (and most browsers) will soon all choose = to perform DoH themselves, making this new model a reality that has to = be addressed. That fundamentally shifts the role of DNS and DHCP within = the end user device infrastructure and the raises questions about the = concept of implicit choice of DNS resolver (e.g. the network resolver vs = application resolver). The observation here is that this shift is being directly driven today = by applications wanting to use DoH to their preferred resolver for a = variety of reasons, not by (for example) operating systems, enterprises, = ISPs, end users or the DNS community.=20 Sara. From nobody Thu Jun 14 08:22:39 2018 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 AD138130E62 for ; Thu, 14 Jun 2018 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 kY8-5XZFwAuh for ; Thu, 14 Jun 2018 08:22:36 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 B1C7E130E45 for ; Thu, 14 Jun 2018 08:22:36 -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; Thu, 14 Jun 2018 08:22:34 -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; Thu, 14 Jun 2018 08:22:34 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) Thread-Index: AQHUApbj6sr7HpgoCUqfpeUX7P+jQqRdpuYAgAFGhACAAAf3gIAAEfgAgAAGfgCAABRdgIAAEW+AgABrFoCAAAVKgIAAO6gAgABglACAAAKdgIAACAoAgAAMTYA= Date: Thu, 14 Jun 2018 15:22:33 +0000 Message-ID: <3C2F4C66-8CA4-4954-90E3-D63410FAC90B@icann.org> References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> In-Reply-To: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 15:22:38 -0000 There were a bunch of DoH implementations at the last IETF Hackathon. The f= act that two of these implementations are getting early publicity is not in= dicative of a trend. On Jun 14, 2018, at 7:38 AM, Sara Dickinson wrote: > The observation here is that this shift is being directly driven today by= applications wanting to use DoH to their preferred resolver It is one implementation of one application, not "applications". And Mozill= a has not said if they want to use a preferred resolver or are just doing t= hat now so that they can get better measurements about whether or not they = want to deploy DoH at all. If Mozilla (or Chrome, or Edge, or ...) turns Do= H into a way in the long term to force a lot of DNS traffic to just one pre= ferred resolver, they will rightly suffer people moving away from them. It'= s pretty trivial to detect this type of behavior. > for a variety of reasons, not by (for example) operating systems, enterpr= ises, ISPs, end users or the DNS community.=20 There was clearly interest in DoH for operating system use (by Stubby). Ent= erprises have indeed indicated they are interested in DoH to avoid redirect= ing of their traffic by intermediaries. We haven't heard from ISPs or end u= sers, but we *certainly* have heard interest on this list from the DNS comm= unity. --Paul Hoffman= From nobody Thu Jun 14 12:12:33 2018 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 0E38C130EAF for ; Thu, 14 Jun 2018 12:12:31 -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, FREEMAIL_FROM=0.001, 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 bLuun_tV4h1R for ; Thu, 14 Jun 2018 12:12:28 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 4F7CF130E74 for ; Thu, 14 Jun 2018 12:12:27 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 32728 invoked from network); 14 Jun 2018 21:12:23 +0200 Received: from agkn52.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.141.52]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 14 Jun 2018 21:12:23 +0200 To: Sara Dickinson , DoH WG References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> Date: Thu, 14 Jun 2018 21:12:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B9RhGjLrglHhKUfBLuXZ52wkYs5XQBuer" X-WP-MailID: a27459fca9fb4423f541906f2ce5c6cd X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [saOU] Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:12:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B9RhGjLrglHhKUfBLuXZ52wkYs5XQBuer Content-Type: multipart/mixed; boundary="Dak8W4ZuX9uzefpquYH8w40N4ydluETXC"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Sara Dickinson , DoH WG Message-ID: <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> In-Reply-To: <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> --Dak8W4ZuX9uzefpquYH8w40N4ydluETXC Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 14.06.2018 o=C2=A016:00, Sara Dickinson pisze: > Applications are free to decide it but it is not without consequences, = for example: >=20 > 1) Many enterprises rely on using internal views for DNS from servers p= rovided by DHCP. If applications override this by _default_ then that mod= el completely breaks internal name resolution _and_ leaks internal querie= s to the external resolver. Some might consider that a loss of security a= nd privacy.=20 >=20 > 2) By =E2=80=98users=E2=80=99 above I think you mean =E2=80=98applicati= on developers=E2=80=99 not =E2=80=98actual end users=E2=80=99? While thei= r may be good reasons for application developers to want to do this I wou= ld postulate that actual end users who understand enough about DNS to wan= t to control it would prefer to have a single system setting to configure= it to point at _their_ preferred resolver, rather than a (transport/DNSS= EC/resolver) setting existing in every individual application.=20 >=20 > I=E2=80=99m not saying there is a right or wrong model here, just that = there are more concerns than simply what the application prefers.=20 >=20 > Sara.=20 >=20 +1 There is a need for robust DHCP to discover DOH servers. I hope that separate DOH settings in web browsers are just a stopgap meas= ure until operating systems will support DOH. Greetings, Mateusz --Dak8W4ZuX9uzefpquYH8w40N4ydluETXC-- --B9RhGjLrglHhKUfBLuXZ52wkYs5XQBuer Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbIr4WAAoJEPvWWrhhCv7Gh54QAJq7P2YE0mBlwro6vUzAuf3w dywEBm5jUS9YLDKAZzQ+EOVWpq3GLsX/rXrVqnHmFFtDftpUG7+ynopHQNdVLvjs yVeCcCReJdYZVyj+/MI0kq6YT4QdIl4wo5ashBLJS3opPPI1E6RQihnQSYWg3SOV QdOnafyuqRkBUsC4QASo63nUOceGqJXGSE5P4BKVMxM/js8DtGIVynXbG7lQNrGP 4cyem3heP8s+NQUXg3FF6u/GOwVKmTbysNAazS9B6aSROCk2ECLQ0nYWbh/I5p2x APTwra6jHkO1vASAx9JzrPe5Nl7peft832hcMyGQK4i4N68t+JE3lJt5LCKk8ozt u+IzqhrMsr8lsHSaIdat0gl++1OdmNzRgfUlUgOzU5mbmHC884qy3xiat6KfvssV 5Qem2NqY8SWKOG5jgzP60nlhZBGuAYcbKf2iwjm+aeLRBbpHCJGIhPVsk7FSLCTi Fi0kdCEsgtoy3dkxWIra/UfCkl9Oi80v2j0q+3vm0gvnKS+pyn8rPfoJ7Q8L/jTF FyIDBDLyEvwNrK8AVC0TF93MRcYdqPiFDI7yXYqkhoESH6FbKWLhCigXiq61mi6N K+mF2ZIdZ4LP2QwI9U0ECLfWgIw1MJ+tA4MBfvIeZBohf+YdWT8JDwyI2hHWvwE5 NAg0STsTK2lnYFURWUmn =pNRl -----END PGP SIGNATURE----- --B9RhGjLrglHhKUfBLuXZ52wkYs5XQBuer-- From nobody Thu Jun 14 12:22:39 2018 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 BF3D4130EE0 for ; Thu, 14 Jun 2018 12:22:37 -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 COoFYU5gfrVT for ; Thu, 14 Jun 2018 12:22:36 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701E0130E88 for ; Thu, 14 Jun 2018 12:22:36 -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; Thu, 14 Jun 2018 12:22:34 -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; Thu, 14 Jun 2018 12:22:34 -0700 From: Paul Hoffman To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= CC: DoH WG Thread-Topic: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) Thread-Index: AQHUApbj6sr7HpgoCUqfpeUX7P+jQqRdpuYAgAFGhACAAAf3gIAAEfgAgAAGfgCAABRdgIAAEW+AgABrFoCAAAVKgIAAO6gAgABglACAAFcZAIAAAumA Date: Thu, 14 Jun 2018 19:22:34 +0000 Message-ID: References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> In-Reply-To: <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_B4AD441F-0CAB-4ECD-973D-A8F0F2080A0D"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:22:38 -0000 --Apple-Mail=_B4AD441F-0CAB-4ECD-973D-A8F0F2080A0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 14, 2018, at 12:12 PM, Mateusz Jo=C5=84czyk = wrote: > There is a need for robust DHCP to discover DOH servers. Agree. > I hope that separate DOH settings in web browsers are just a stopgap = measure > until operating systems will support DOH. We haven't gotten much traffic on the driu mailing list = , but I do hope we get more = on this. --Paul Hoffman --Apple-Mail=_B4AD441F-0CAB-4ECD-973D-A8F0F2080A0D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAlsiwHkACgkQsZnCoeEP RXsztQf8D/8HNpKc1MMx3aZRGQQlr5NKoZ46LTDSus996KloDIL4rD4FXU1XCPxf 6S8ulI//XAaDhm0dJZ3REljvbRQHKYrK8+0l+jstP6IDqBhcpcYteTl3yQeLXff7 j7GtDJn/bn1EVvFq8sAnP2nsJUCkvmq1bS+fuf4HYzuJ4UVbP9GZQ0ukiwtypGOd 1mPNkUdsVivKc9hmNoTCtR6m96diqcjBFjPswikwFdNJsAyGznTFmvKvS/xnjCP3 mW3RyUt1wf9g5fstgKCfapOvnRSbmHnOHjDVdgzAKf6N7oQ5N2WsUil63CcgiPXg rxUVPWet6rZdH7Y6ehTv7cY8/I9ceA== =2vqJ -----END PGP SIGNATURE----- --Apple-Mail=_B4AD441F-0CAB-4ECD-973D-A8F0F2080A0D-- From nobody Thu Jun 14 12:25:09 2018 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 7FDD5130F65 for ; Thu, 14 Jun 2018 12:24:56 -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 97AoI76JR7FC for ; Thu, 14 Jun 2018 12:24:53 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49C0130F4F for ; Thu, 14 Jun 2018 12:24:53 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 14 Jun 2018 12:24:51 -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; Thu, 14 Jun 2018 12:24:51 -0700 From: Paul Hoffman To: Sara Dickinson CC: Tony Finch , "doh@ietf.org" Thread-Topic: [Ext] [Doh] terminology: "DNS API" Thread-Index: AQHUBBVdlnNbyOj7GkiUSq4ST4mr4A== Date: Thu, 14 Jun 2018 19:24:51 +0000 Message-ID: References: In-Reply-To: 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="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] terminology: "DNS API" X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:25:05 -0000 T24gSnVuIDgsIDIwMTgsIGF0IDU6MTUgQU0sIFNhcmEgRGlja2luc29uIDxzYXJhQHNpbm9kdW4u Y29tPiB3cm90ZToNCj4gDQo+PiBPbiA2IEp1biAyMDE4LCBhdCAxNTo1OCwgVG9ueSBGaW5jaCA8 ZG90QGRvdGF0LmF0PiB3cm90ZToNCj4+IA0KPj4gQ2FuIHdlIGFtZW5kIHRoZSBkb2N1bWVudCB0 byByZXBsYWNlICJETlMgQVBJIHNlcnZlciIgd2l0aCAiRE5TLW92ZXItSFRUUFMNCj4+IHNlcnZl ciIgb3IgIkRvSCBzZXJ2ZXIiIHBsZWFzZT8NCj4gDQo+ICsxIG9uIHRoaXMgKHNpbmNlIGFsc28g aW4gcHJhY3RpY2Ug4oCYRG9IIHNlcnZlcuKAmSBzZWVtcyB0byBiZSB0aGUgdGVybSBldmVyeW9u ZSBpcyB1c2luZykNCg0KTGF0ZSByZXBseTogYWdyZWUuIFdlJ2xsIG1ha2UgdGhpcyBjaGFuZ2Ug aW4gdGhlIG5leHQgZHJhZnQuDQoNCj4gV2hhdCB3YXMgdGhlIHJlYXNvbiB0aGF0IHRoaXMgbmFt ZSB3YXMgY2hvc2VuPw0KDQpVbSwgZXIsIHdlbGwuLi4uIGEgbWlzdW5kZXJzdGFuZGluZyBiZXR3 ZWVuIHRoZSB0d28gYXV0aG9ycy4gUGF0cmljayB0aG91Z2ggSSBsaWtlZCBpdCwgSSB0aG91Z2h0 IHRoYXQgaGUgbGlrZWQgaXQuIFdlIGNsZWFyZWQgdGhhdCB1cCB0aGF0IHN5bW1ldHJpYyBlcnJv ciB0b2RheS4NCg0KLS1QYXVsIEhvZmZtYW4= From nobody Thu Jun 14 12:33:03 2018 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 B88F9130EE0 for ; Thu, 14 Jun 2018 12:33:01 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0ZzhiByCHZls for ; Thu, 14 Jun 2018 12:33:00 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 1D7F5130E88 for ; Thu, 14 Jun 2018 12:32:59 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 2941 invoked from network); 14 Jun 2018 21:32:56 +0200 Received: from agkn52.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.141.52]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 14 Jun 2018 21:32:56 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: dnsmasq-discuss@lists.thekelleys.org.uk, DoH WG Openpgp: preference=signencrypt Message-ID: Date: Thu, 14 Jun 2018 21:32:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ho8eJquasGR2jO5qGav0nMqKDmcLs7Vrt" X-WP-MailID: e7ae8f3d53dd91075b8fa3fa30d12e7e X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [8SNk] Archived-At: Subject: [Doh] Implementation of DOH in dnsmasq X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:33:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ho8eJquasGR2jO5qGav0nMqKDmcLs7Vrt Content-Type: multipart/mixed; boundary="TcywKUwZaxGZ9tHtbCwoNpkXWomE3cwOI"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: dnsmasq-discuss@lists.thekelleys.org.uk, DoH WG Message-ID: Subject: Implementation of DOH in dnsmasq --TcywKUwZaxGZ9tHtbCwoNpkXWomE3cwOI Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable // I am writing to dnsmasq developers to ask them about viability of // implementing HTTP/2 in dnsmasq. Hello, As You may know, IETF is developing a new standard called DOH - DNS over = HTTPS. It will allow tunelling DNS requests over HTTPS. Current version of the standard can be found on https://github.com/dohwg/draft-ietf-doh-dns-over-https/blob/master/draft= -ietf-doh-dns-over-https-latest.mkd This standard is currently being finished. Current version of this standard recommends use of HTTP/2.0 as the data transport, but allows use of earlier versions of HTTP. It does not, howev= er, require clients to support servers that talk HTTP/1.0 or HTTP/1.1 only. How difficult would it be to add support to DNS over HTTP/2.0 in dnsmasq,= for example in constrained environments like home routers? Please send any replies to the DoH mailing list at . Greetings, Mateusz Jo=C5=84czyk --TcywKUwZaxGZ9tHtbCwoNpkXWomE3cwOI-- --Ho8eJquasGR2jO5qGav0nMqKDmcLs7Vrt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbIsLnAAoJEPvWWrhhCv7GcykQAJOmWT7fb2vGfwFXVRUJ/SU5 Qzd32DK56m6qEdzVcdj8bU5Yv5jMiXkjuOAstRIiLcpycHaaAWf2a/Y1xQQQ7zHp hSpunOZ8zqLAIQoiV6QsaOB4mbHbRBP+btRSjYrmc5aUL6EAiQhML6u2BBKnyqFW 5qFqOw7U1la7jMWKfrVh9pD3ZISHIRExVdXsYKMRdBRi+p896jWzStAnDVrxgfC7 Wwp9DgbQ/NguZ10jykaa/zLrD8iq88LZ/Cyz3frqplFAJDCVEw8TkGvY2ambrDdM PAbZtExPkdAafSH4RkQpItlXGc8mk2r556SrbMrbzCFYwvqx2erh3Gjacr04+/VG lnDbFr8+elGcT4Rs9VHABnA2PIjciZSn6IOOOUBUBMTYJRzeR1Wc5g3fXfDEX1W+ HQrM45KY02lIqmsMgb+xatAOr2dwlZmoGjU52D+WnQl046fGcsal6EjkZ5Pq9Z6H q1um279XtZgJBox9JpKWkiiMwxKKkf52GEW41S5reyE5s6KIkISXuEz7oSl70rUd Hj3gIXhoyhqFCZw1h1wdLgjF1q+eKMVToN+KcE3CvwbxlW0w3/8MZWtElikHXnPy 4USYyG057BTfXaSEdNdZ0mgIinS2QJpx+6Jx4K/3hsPsNuBcdXvk1TdSwL30YXMK 2QGJtavRfLlwsJyYC5to =3Osy -----END PGP SIGNATURE----- --Ho8eJquasGR2jO5qGav0nMqKDmcLs7Vrt-- From nobody Thu Jun 14 12:35:40 2018 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 6151A130EED for ; Thu, 14 Jun 2018 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 y4g9Tf8Zrf5t for ; Thu, 14 Jun 2018 12:35:36 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 F1FF7130E5B for ; Thu, 14 Jun 2018 12:35:35 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id f1-v6so8370764ioh.6 for ; Thu, 14 Jun 2018 12:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ko0xzwp2PW6LRnY6HpSEsPDK6YmdnIxJvBpLOb3WrhY=; b=iIQtqPibQhuTNJjHw4CVumTAX3Iw7oOV3+c90c+WntwFwdzVDMC0zV9dzN9cjRsWKQ XQOU8u/F6xe/MJgJfNUySnKll2/U8O3C9AcUIk6wlADrdlkHbzqIDrlYlvEzBNDbHbSM XRPDWbybgNlJUIssVem4GiUV9NEfAHoibY+vF2Q6UaKUb7Gr8IOaA554gWGUtE7utrnX H3NyoxuLSzorGJ/miyfZhL/S2LQHNWVUGSdQMsqbaxY6/xOZXp6X378nh1iXlDlOdFVp a/4RN8BMY1Vs39Etn5gqp6uH45PBpiC01d4MLNwdaVapVkIqJp/dYOrxm1P7NXIb8pdm udDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ko0xzwp2PW6LRnY6HpSEsPDK6YmdnIxJvBpLOb3WrhY=; b=L4zonrNgMa4GGcMQMAuzAW57GLi/uo/bod0drNtba0wpOkTDlaQYxkAxBXoH/q1aU2 DQzVlYv2on8iPtY2IsJ/uWtY0uOKhl1RzdV0JD0razgu9rOsFPNWwjGKbXoPA8ARMW+U N1N9iEAGBd8hE8NUPYWCY5Rn8nNeuxGQh/9BpyuWg6OFIhec9u40+4xhSUNtjy3xX8WB oIaNOEyViVah2R2UNS/twKhCGiv623gF3JI1Wmg404AtHtm/OH6tZop+xv7lmVT2DbOG iIutCyA6HYDyl3psuvTOlL47+x4zatGcULj5EsT+1XM83q5Q47vJU1+tjeIfr/3OswXe 4EcQ== X-Gm-Message-State: APt69E0RsinygDIju5ILTqIeUyN+a7NH6P7ye56dEB8f0IntEu2Lz7Jc P0ZLbPjAAGUpnjqv+qZGFzwYigJf7OxpHMl7wnJE+w== X-Google-Smtp-Source: ADUXVKLkbSGOoU23ONj8IpwGNYXcXWktj3gaBVwzyGlQYhQj/VXc+lxyPPq/LlmmHDT60AFY8rSBSkWneJFP1mzRhvw= X-Received: by 2002:a6b:9d15:: with SMTP id g21-v6mr3797193ioe.85.1529004935293; Thu, 14 Jun 2018 12:35:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6f86:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 12:34:54 -0700 (PDT) In-Reply-To: References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> From: Ted Lemon Date: Thu, 14 Jun 2018 12:34:54 -0700 Message-ID: To: Paul Hoffman Cc: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= , DoH WG Content-Type: multipart/alternative; boundary="000000000000074494056e9f3412" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:35:39 -0000 --000000000000074494056e9f3412 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Paul, Mateusz, can you talk about the use case for using DHCP to discover DoH? It's not at all clear to me. On Thu, Jun 14, 2018 at 12:22 PM, Paul Hoffman wrote: > On Jun 14, 2018, at 12:12 PM, Mateusz Jo=C5=84czyk wr= ote: > > There is a need for robust DHCP to discover DOH servers. > > Agree. > > > I hope that separate DOH settings in web browsers are just a stopgap > measure > > until operating systems will support DOH. > > We haven't gotten much traffic on the driu mailing list < > https://www.ietf.org/mailman/listinfo/driu>, but I do hope we get more on > this. > > --Paul Hoffman > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000074494056e9f3412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul, Mateusz, can you talk about the use case for using D= HCP to discover DoH? =C2=A0 It's not at all clear to me.

On Thu, Jun 14, 2018 at 12= :22 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Jun 14, 2018, at 12:12 = PM, Mateusz Jo=C5=84czyk <mat.joncz= yk@o2.pl> wrote:
> There is a need for robust DHCP to discover DOH servers.

Agree.

> I hope that separate DOH settings in web browsers are just a stopgap m= easure
> until operating systems will support DOH.

We haven't gotten much traffic on the driu mailing list <https://www.ietf.org/mailman/listinfo/driu>, but I= do hope we get more on this.

--Paul Hoffman

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--000000000000074494056e9f3412-- From nobody Thu Jun 14 12:39:12 2018 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 5D98D130E8A for ; Thu, 14 Jun 2018 12:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 CQ2_CzOoraK8 for ; Thu, 14 Jun 2018 12:39:09 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 776EC130E88 for ; Thu, 14 Jun 2018 12:39:09 -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; Thu, 14 Jun 2018 12:39:07 -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; Thu, 14 Jun 2018 12:39:07 -0700 From: Paul Hoffman To: Ted Lemon CC: DoH WG Thread-Topic: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) Thread-Index: AQHUApbj6sr7HpgoCUqfpeUX7P+jQqRdpuYAgAFGhACAAAf3gIAAEfgAgAAGfgCAABRdgIAAEW+AgABrFoCAAAVKgIAAO6gAgABglACAAFcZAIAAAumAgAADcwCAAAEugA== Date: Thu, 14 Jun 2018 19:39:07 +0000 Message-ID: <602C852F-D988-4D3C-A959-E7A6EAE6AC3E@icann.org> References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> In-Reply-To: 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: <1E3E88C46A5D8640A3040353E64617A9@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:39:11 -0000 On Jun 14, 2018, at 12:34 PM, Ted Lemon wrote: > Paul, Mateusz, can you talk about the use case for using DHCP to discover= DoH? It's not at all clear to me. An OS might want to offer protected DNS for its stub resolver. DNS-over-TLS= is one obvious option, DOH might be another. --Paul Hoffman= From nobody Thu Jun 14 12:46:19 2018 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 E575A130E8A for ; Thu, 14 Jun 2018 12:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 rJc25aOtdRtF for ; Thu, 14 Jun 2018 12:46:15 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 29794130E79 for ; Thu, 14 Jun 2018 12:46:15 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id t5-v6so8390217ioa.8 for ; Thu, 14 Jun 2018 12:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zru4mlWH5+TD0JbwZwuftQhBOWuq8GFHh5Vh687g/2Y=; b=XE0An00SXjxDg6iNaX+Yoq4cIDyLTKdPjA2HhAVSbGqzOYAWxqBnPqUdP8JlnAhS8f X6BOIlKsCALh8iNBCk8i8xRKJ/SETBAuUjR/FzIJ+4yWEEFveuwS+wr/7r93prWiMpme i7knV8I3p0C8EPImuzG9A+JRh3kICojEZPg6gSjXa6mSbRXo03EI6CEDYd4wysRIBWRs VtiVI5X4gAu+mQ5gD2bLcymAxwVbiLeSnRJyPzkdHbZLa1hXR4xQSNHzzO2GzRdXoglb p3zzJrlyWCu3otc491JUXhb3FTxGDJJ5zwsmyw2tjOgL2fWtXin/Tmd8/+9aD3cf/IiH XG6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zru4mlWH5+TD0JbwZwuftQhBOWuq8GFHh5Vh687g/2Y=; b=Teb9UtEoouSzG6q7Q0GruDEHEUiRCJwjE/lzHRz69wF7UC3NHFpGBf+QKZSt+449vH CZEXwLFrJu/1olY5Q95EnNavbrRW6VZo9davkZjDyIBPf39Ftr3HgaUGOtOQdxdY2cvc Mkwl0Kk1CRSUWZst2jVjeOQDCESmemEKuI9D60L9bxFcGY12lxNAVZtfL6lJeIHENxE5 3KiJpmdcg70Unn1KaVB/wbBNc++oXPz9UcJ3PuK2qtLT3b3CuvmA/VN8ipoMCxYGsDZw ZQI7CdsEftW4nZB6iBudjb1B5Ipa7klg6ZU9NxZDlpAkqAa9JErES0JBD67Pk8LUa1Lz q62A== X-Gm-Message-State: APt69E1jXQTKZw55y7sqfUx7wD+r00J5YrOu7pZPYvHu8P4WuUkZJSMq /8x9WTYFSnD1L+9ynsXVHhpcOFP+WlOccE47GZB0DA== X-Google-Smtp-Source: ADUXVKLuy+clI1JMK7RodHyJfiHy/RoM/FrfywhEl2rx5REKSrNqE7u5B4PmjjeVWBsbVwoiRGGSZC5JySd5csvYU3M= X-Received: by 2002:a6b:be05:: with SMTP id o5-v6mr1423531iof.45.1529005574508; Thu, 14 Jun 2018 12:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6f86:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 12:45:33 -0700 (PDT) In-Reply-To: <602C852F-D988-4D3C-A959-E7A6EAE6AC3E@icann.org> References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> <602C852F-D988-4D3C-A959-E7A6EAE6AC3E@icann.org> From: Ted Lemon Date: Thu, 14 Jun 2018 12:45:33 -0700 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000211138056e9f5a82" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:46:17 -0000 --000000000000211138056e9f5a82 Content-Type: text/plain; charset="UTF-8" Okay. But do you *get* protected DNS if you discover a DoH server using DHCP? What does "protected" mean in this context? On Thu, Jun 14, 2018 at 12:39 PM, Paul Hoffman wrote: > On Jun 14, 2018, at 12:34 PM, Ted Lemon wrote: > > Paul, Mateusz, can you talk about the use case for using DHCP to > discover DoH? It's not at all clear to me. > > An OS might want to offer protected DNS for its stub resolver. > DNS-over-TLS is one obvious option, DOH might be another. > > --Paul Hoffman --000000000000211138056e9f5a82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay. =C2=A0 But do you get=C2=A0protected DNS if y= ou discover a DoH server using DHCP? =C2=A0 What does "protected"= mean in this context?

On Thu, Jun 14, 2018 at 12:39 PM, Paul Hoffman <paul.hoffm= an@icann.org> wrote:
On Jun 14, 2018, at 12:34 PM, Ted Lemon <mellon@fugue.com> wrote:
> Paul, Mateusz, can you talk about the use case for using DHCP to disco= ver DoH?=C2=A0 =C2=A0It's not at all clear to me.

An OS might want to offer protected DNS for its stub resolver. DNS-o= ver-TLS is one obvious option, DOH might be another.

--Paul Hoffman

--000000000000211138056e9f5a82-- From nobody Thu Jun 14 12:49:29 2018 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 1D55A130EE0 for ; Thu, 14 Jun 2018 12:49:27 -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 Dl5fEw4cLkBT for ; Thu, 14 Jun 2018 12:49:25 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460C5126CB6 for ; Thu, 14 Jun 2018 12:49:25 -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; Thu, 14 Jun 2018 12:49:23 -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; Thu, 14 Jun 2018 12:49:23 -0700 From: Paul Hoffman To: Ted Lemon CC: DoH WG Thread-Topic: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) Thread-Index: AQHUApbj6sr7HpgoCUqfpeUX7P+jQqRdpuYAgAFGhACAAAf3gIAAEfgAgAAGfgCAABRdgIAAEW+AgABrFoCAAAVKgIAAO6gAgABglACAAFcZAIAAAumAgAADcwCAAAEugIAAAcyAgAABEQA= Date: Thu, 14 Jun 2018 19:49:23 +0000 Message-ID: References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> <602C852F-D988-4D3C-A959-E7A6EAE6AC3E@icann.org> In-Reply-To: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:49:27 -0000 On Jun 14, 2018, at 12:45 PM, Ted Lemon wrote: >=20 > Okay. But do you get protected DNS if you discover a DoH server using D= HCP? Yes, for some value of protected. > What does "protected" mean in this context? That's a topic for the DRIU mailing list and the upcoming BoF. It's not rel= evant here other than that people are asking where DoH might be used. --Paul Hoffman= From nobody Thu Jun 14 12:57:03 2018 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 B7591130E70 for ; Thu, 14 Jun 2018 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 L1D_oW8NVknt for ; Thu, 14 Jun 2018 12:56:59 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 D0762126CB6 for ; Thu, 14 Jun 2018 12:56:58 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id d22-v6so8409195iof.13 for ; Thu, 14 Jun 2018 12:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oeDIzuNiK3bwf9CgiOocD7uhGbOEMfaiHGjpcsU5QL4=; b=vpArEySj2d+v3JXFCEoqQpFtHOzBMJukiu38yeywR0bQCqxsedrQy+rs4q+L+UHQzp xK3lE0dnFgnJf5LiZM6w7PLgGciO/HiqSnV63mWbj8gPNItBMssXOQdronH2q9fjTGNJ awWGhGKW44tuZmhgklr+2kgfCIwG/R6hQ9VwheDOFJVG41XlBuBEuFEnwSR6OqPOMVgT KPpeKhVqWRwaapMioHtMvyt3LujbrESuoRLcwOEa+Zk9qs3tQND4WD+HvtkNTBeVybIx GnkmpcySwLtY4uXa4mWFG9kc9jYkG3Bsy6F6aM1Z5mm8FsQ1ODQO9u5hLoKJAUNQ7Vnw dFlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oeDIzuNiK3bwf9CgiOocD7uhGbOEMfaiHGjpcsU5QL4=; b=TzD6NfuRUwLHaN3TS+AfXLVtXFPjd01nOsNPeG0C7iI8B3jEXlI12m7bCbOEklNO4C ElRdMjU58yjgMoR78YAtTGL9MV8EXn0p+KzB/In5RDmnf/Tx0nTd8zLV21x+C9qS3KsF 63s8mnQUtnZnD+1BZokFLGpjG15MtYGjQXeYgnAHjpflfs0Zxh8jTOqM+nWtvhxAY3Sp 4B7jBbWLtPsZmM9laRjLSbF7rBiPR/QTYNnteNkv3mqwchQHPY9BX7M5eUl6U9sM3byw 00EZUw7hEwTRWnYr577oFQiRkqWbR0eR2HZzJpIiyusWD3zpTjB0Ht8tvmglnTYh0ae8 SVSA== X-Gm-Message-State: APt69E0XVXlczTQuiWGhJDlReZAbcYDOpgJJ+o+W0tXtzTD8LyrRKGOK Xq2rza8Og80LtYILEQvf/rVVhBwRXQvztBffua9sog== X-Google-Smtp-Source: ADUXVKJ6Xitboc2bytcxhC+4ZKElT9lCVZ7DicCbsFdC1m2mO8pfXtTtB5LiLm2NzgpLtlNvXiJB37Pjyx+2IUB1v/Q= X-Received: by 2002:a6b:be05:: with SMTP id o5-v6mr1456365iof.45.1529006218064; Thu, 14 Jun 2018 12:56:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6f86:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 12:56:17 -0700 (PDT) In-Reply-To: References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <20180613192030.GA2792@jurassic> <20180613205637.GA23215@jurassic> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl> <602C852F-D988-4D3C-A959-E7A6EAE6AC3E@icann.org> From: Ted Lemon Date: Thu, 14 Jun 2018 12:56:17 -0700 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000007cc063056e9f80fa" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 19:57:01 -0000 --0000000000007cc063056e9f80fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, fair enough, but if that's the case, then you probably shouldn't be advocating for a DHCP option *here. *I see that Tom has raised the DHCP question on that mailing list, so I'll subscribe. FWIW, Tom and Willem and I had a discussion about the security implications of this last week, and while I don't know if Tom and Willem came away agreeing with me on this, the upshot from my perspective is that this really does need to be carefully thought through and carefully specified=E2=80=94it's by no means = clear to me that we "need" a DHCP option, but if we do, it has to have the right security properties. Thanks for the pointer. On Thu, Jun 14, 2018 at 12:49 PM, Paul Hoffman wrote: > On Jun 14, 2018, at 12:45 PM, Ted Lemon wrote: > > > > Okay. But do you get protected DNS if you discover a DoH server using > DHCP? > > Yes, for some value of protected. > > > What does "protected" mean in this context? > > That's a topic for the DRIU mailing list and the upcoming BoF. It's not > relevant here other than that people are asking where DoH might be used. > > --Paul Hoffman --0000000000007cc063056e9f80fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, fair enough, but if that's the case, then you pr= obably shouldn't be advocating for a DHCP option here. =C2=A0I s= ee that Tom has raised the DHCP question on that mailing list, so I'll = subscribe. =C2=A0 FWIW, Tom and Willem and I had a discussion about the sec= urity implications of this last week, and while I don't know if Tom and= Willem came away agreeing with me on this, the upshot from my perspective = is that this really does need to be carefully thought through and carefully= specified=E2=80=94it's by no means clear to me that we "need"= ; a DHCP option, but if we do, it has to have the right security properties= . =C2=A0 Thanks for the pointer.

On Thu, Jun 14, 2018 at 12:49 PM, Paul Hoffman <= paul.hoffman@icann.org> wrote:
On Jun 14, 2018, at 12:45 PM, Ted Lemon <mellon@fugue.com> wrote:
>
> Okay.=C2=A0 =C2=A0But do you get protected DNS if you discover a DoH s= erver using DHCP?

Yes, for some value of protected.

>=C2=A0 =C2=A0What does "protected" mean in this context?

That's a topic for the DRIU mailing list and the upcoming BoF. I= t's not relevant here other than that people are asking where DoH might= be used.

--Paul Hoffman

--0000000000007cc063056e9f80fa-- From nobody Thu Jun 14 13:01:11 2018 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 92AB0130F67 for ; Thu, 14 Jun 2018 13:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 Iv7lIYNK_ZUO for ; Thu, 14 Jun 2018 13:00:59 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 DAF44130F69 for ; Thu, 14 Jun 2018 13:00:58 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id 200-v6so4421425vkc.0 for ; Thu, 14 Jun 2018 13:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E1SUJ2fUnd+ONLvv75CEfd87i8e3wQ+MqQsQpxGmzp0=; b=nIpL1+M26vtuNcVJSgZEMBFmIcWmqaIGAPeqZVC7nQQ+XRl18nGydsF8VQcE0zZXdI SFknO90ZdbLlhYyAVNJt+mxHZFLs3tIg3f+oPfB7OsUiDiPPcUO1qd60s4onmePVFrnr nqKgcqz8cUSpEoXdAgjZ1q/u+t+aFTKH4a69YSzAN0Yy5aCwSVrITTiGmesUipZpdivN YQdrlndsfYCdSdUQaJ8kLWWVDIKSLQbHtLIzxq0dZZW/55TbvbUWBVpLQ4ddiz4my3Tm R9P+CjOlZUIaTshbbwdPhM9feB5xvuqocOHT+kS+XxWTyhPVtQKdgD03u4KtNcD/naym Ozuw== 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; bh=E1SUJ2fUnd+ONLvv75CEfd87i8e3wQ+MqQsQpxGmzp0=; b=HABKVDFsiQspU/0NWooqX7YLRF0b1Hs2wJTa6z+QcVbZec+5283MP27SZ8XsgVMFwA zSmnHVRi4nGAy3K/Fs0i0pcuWzX9In0crgrcvHJA8VCzX3usLb3qDOMEypakAkNsxEBp qUzsag3QZ+8Beu5SC0H0zgyPMnHGogrYpwaFp9nYlJWJhqEqq/eIjLrsExspYdWwmGup JmqvPDSrNnMIBKmtRLXyJBT6v713DoEWArMpx/qgPbjh5SfeSTuSIK0JDp3zM9q+TNLA Gvo3SgD+d2+rG0+0eepczKJaaoJgFRJMZxZWtkrZCKGFGvsYhe+02i5tNq27i4weYFAh xASg== X-Gm-Message-State: APt69E06vspNR/ljJAB9mJPVU13ooVBajWN5k1AlcpCmzwT+s9qhRQWE jpnoTDG4BhWU86Mnn+2i1mH2v7LB7JdHeD9jWJJB16I3/64= X-Google-Smtp-Source: ADUXVKL928ZUTky6gG4WkjMak+gXPlfF/sFu7IiP3WSOVBlTNduIfju92X1Xxu/dCWvghV16hmlMoWSMNXMqKoacaZM= X-Received: by 2002:a1f:3697:: with SMTP id d145-v6mr2473390vka.79.1529006456024; Thu, 14 Jun 2018 13:00:56 -0700 (PDT) MIME-Version: 1.0 From: Puneet Sood Date: Thu, 14 Jun 2018 16:00:43 -0400 Message-ID: To: doh@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 20:01:10 -0000 New to the list, quoting the relevant message manually (https://www.ietf.org/mail-archive/web/doh/current/msg00743.html). Dave Lawrence wrote: > I believe that makes not imposing a 64k limit on DNS fall within the > bounds of the charter. In fact, I could make a case that it goes > right to the first paragraph: > > This working group will standardize encodings for DNS queries and > responses that are suitable for use in HTTPS. This will enable the > domain name system to function over certain paths where existing DNS > methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience > problems. > > ... in addressing cases where existing methods experience problems. > I'm not going to get too hung up on rules-lawyering that argument > though, it's a sideshow. > > Per our out-of-band conversation, I will later this week (new $dayjob > intrudes) be offering text for the proposal I made in another message > about using two mandatory-to-implement media types right out of the > gate, differing only in that one has a Content-Length limit. > Implementers can then choose to make it plainly explicit that they > are sticking to legacy TCP limits. Having two distinct media types (one with the limit, one without) will allow a doh server to determine if a larger response is safe to send and respond accordingly. So I am in favor of your proposal to define two media types. The RFC should not mandate length limits for media types other than the existing wire format media type. That should be entirely up to the specification of the new media types. Barring a clear indication in the client request, a doh server should conservatively limit responses to 64K for the existing wire format media type. Reading draft 10 section 6.1, I do not see any text addressing interaction of the message size with the cache behavior in a recursive resolver. This is mostly theoretical right now because the transports (UDP, TCP) between recursive and authoritative servers are constrained by the 64K limit. However when recursive resolvers start receiving > 64K responses, this will need to be addressed. Couple of points: 1. Will a caching resolver be expected to cache very large responses? An implementation may decide to put an upper limit on the size of a message it will cache. 2. Will a caching resolver need to cache different answers corresponding to the 64K limit and the "unlimited" case? -Puneet From nobody Thu Jun 14 13:12:09 2018 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 1A6BA130EE0 for ; Thu, 14 Jun 2018 13:12:07 -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 MUtEf_71wcFW for ; Thu, 14 Jun 2018 13:12:04 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B233130F4D for ; Thu, 14 Jun 2018 13:12:03 -0700 (PDT) Received: from jurassic (unknown [49.203.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id B081232C07B4; Thu, 14 Jun 2018 20:12:00 +0000 (UTC) Date: Fri, 15 Jun 2018 01:41:55 +0530 From: Mukund Sivaraman To: Puneet Sood Cc: doh@ietf.org Message-ID: <20180614201155.GA27412@jurassic> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 20:12:08 -0000 On Thu, Jun 14, 2018 at 04:00:43PM -0400, Puneet Sood wrote: > Reading draft 10 section 6.1, I do not see any text addressing > interaction of the message size with the cache behavior in a recursive > resolver. This is mostly theoretical right now because the transports > (UDP, TCP) between recursive and authoritative servers are constrained > by the 64K limit. However when recursive resolvers start receiving > > 64K responses, this will need to be addressed. Couple of points: > 1. Will a caching resolver be expected to cache very large responses? > An implementation may decide to put an upper limit on the size of a > message it will cache. > 2. Will a caching resolver need to cache different answers > corresponding to the 64K limit and the "unlimited" case? There's no use-case for any such caching. There's no data that DNS carries that needs such large answers to be cached today. That "640k ought to be enough for anybody" thing keeps coming up, but this is over-engineering. It's like computing everything with bignums instead of 64-bit ints because.. who knows.. a larger number may come and we should not restrict it because it's 2018. Mukund From nobody Fri Jun 15 09:48:43 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1412F18C; Fri, 15 Jun 2018 09:48:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152908132156.27398.4658872074579668000@ietfa.amsl.com> Date: Fri, 15 Jun 2018 09:48:41 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-11.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:48:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS (DoH) Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-11.txt Pages : 18 Date : 2018-06-15 Abstract: This document describes how to make DNS queries over HTTPS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-11 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 15 09:49:12 2018 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 C4BC8130F39 for ; Fri, 15 Jun 2018 09:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3-8Azld4IvyI for ; Fri, 15 Jun 2018 09:48:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B33130F0D for ; Fri, 15 Jun 2018 09:48:58 -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; Fri, 15 Jun 2018 09:48:56 -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; Fri, 15 Jun 2018 09:48:56 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: Version -11: media type definition changes, clearer error handling, DoH Thread-Index: AQHUBMi/vNj1UStJeU6GDOPK1pSzCw== Date: Fri, 15 Jun 2018 16:48:56 +0000 Message-ID: <73B49AA0-7890-4701-84CB-E30AAE562327@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: <5421E2E340E7FC4B906361A83230ECC5@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Doh] Version -11: media type definition changes, clearer error handling, DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:49:10 -0000 Greetings again. As you can see, Patrick and I just published -11 to match = the recent WG discussion. The diff is long because we changed "DNS API" to "DoH" (and "DOH" to "DoH")= ; we actually looked at each instance to make sure it made sense, but if yo= u find any place where it is now not clear, by all means let us know. It felt like most people agreed with having the 64K limit in the media type= being defined here as long as other media types can be defined in the futu= re, which of course they can be.=20 The recent AXFR discussion caused us to re-look at the discussion of HTTP a= nd DNS error handling, and we realized that it was spread over a few differ= ent places. We combined it into one so that HTTP folks can understand more = about DNS error codes, and DNS folks can understand more about HTTP error c= odes. We think -11 is ready for the WG chairs to pass on to AD for IETF Last Call= . The architecture discussion is important, and will probably continue in I= ETF Last Call, but shouldn't hold up the protocol document. --Paul Hoffman From nobody Mon Jun 18 04:21:23 2018 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 CD6FA130E96 for ; Mon, 18 Jun 2018 04:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 GdKCvq1u2Czt for ; Mon, 18 Jun 2018 04:21:20 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F62F124BE5 for ; Mon, 18 Jun 2018 04:21:19 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 3C6E39FB55 for ; Mon, 18 Jun 2018 11:21:16 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 0E9E6AC623F; Mon, 18 Jun 2018 13:21:16 +0200 (CEST) Date: Mon, 18 Jun 2018 13:21:16 +0200 From: bert hubert To: doh@ietf.org Message-ID: <20180618112116.GB9195@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 11:21:22 -0000 Hi everyone, I'm happy with the progress in -11 and hope we can see this in standardized production soon! One thing I would like to note though, but I'm not sure if it has a place in the draft: the differential privacy aspects of DNS versus DNS over HTTPS. DNS is encoded so tightly that there is almost no variation in queries coming from stub resolvers. Your esp8266, fridge, microwave and iPhone X all send out bit for bit identical queries, and this is a wonderful thing. HTTPs however can be highly identifiable. Over the course of a week, over 4000 different agent strings visited https://ds9a.nl/ and https://powerdns.org/, for example (and this is excluding bots). This allows DoH servers to differentiate different devices in a household easily, since most of them will have a unique string. In addition, HTTP can carry further identifying headers like accepted languages, HSTS settings (perhaps) or even cookies. It has also been observed that TLS session resumption data provides a way to semi-persistently track individual TLS originators (but I don't know for how long). With all this, there is the clear risk that DoH as a privacy feature will at first succeed in providing DNS operators with a more detailed insight into per-device browsing habits, something they may not be shy to monetize. I have discussed this on Twitter with various HTTP users and they opined that since they were supplying these headers already anyhow the privacy impact is minimal. After some discussion & dumping of headers, I think they agreed it is not necessary to send out a user's language preferences with DNS request, nor the CPU, or the operating system or the exact browser version. As noted, I don't know if this has a place in the draft, but I'd recommend DoH clients to: * Set their Agent to 'DoH client', no matter what browser/library * Do not pass non-essential HTTP headers (like language) * Do not allow the DoH server to set cookies * Ponder TLS sessions resumption data settings * Think about all other ways in which HTTP can be tracked (HSTS?) Thoughts? Bert From nobody Mon Jun 18 05:49:35 2018 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 6A35F12F1A6 for ; Mon, 18 Jun 2018 05:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 grji-fI7kbm0 for ; Mon, 18 Jun 2018 05:49:31 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99AC0126DBF for ; Mon, 18 Jun 2018 05:49:31 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 53C2D1A0A32 for ; Mon, 18 Jun 2018 05:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529326171; bh=AFbt1ubO0ZWSOE0U3Luse4N7a8mY2MwUaInozyHAOfU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QpKpZURc2g98uQ0e60BmRmaqVZc7ZpI/svH+lKLL4OO0YahJ4Dk8HL2soEah+VZM8 swtjSCb2GkLlqQKPVSjyaXCLCIEgoo4E+nh/i5CVBognJ8FOY1E8f+ZnrK7GVo7xQd tpZTgxGkirfcoguq651AtunfF67Lf734lAXFuXlQ= X-Riseup-User-ID: E996391366613B9510B2277C61E260D942976937C1C66612EB2529F81EFD8C10 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 81CD16E32F for ; Mon, 18 Jun 2018 05:49:30 -0700 (PDT) To: doh@ietf.org References: <20180618112116.GB9195@server.ds9a.nl> 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: Mon, 18 Jun 2018 12:49:00 +0000 MIME-Version: 1.0 In-Reply-To: <20180618112116.GB9195@server.ds9a.nl> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="18voAP4bskIJOsYI52BS11BRrwKiwM2Kn" Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 12:49:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --18voAP4bskIJOsYI52BS11BRrwKiwM2Kn Content-Type: multipart/mixed; boundary="NV1FVcX1HgOrKVWqB9N2x0N8jhYDuKkJB"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS References: <20180618112116.GB9195@server.ds9a.nl> In-Reply-To: <20180618112116.GB9195@server.ds9a.nl> --NV1FVcX1HgOrKVWqB9N2x0N8jhYDuKkJB Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable > As noted, I don't know if this has a place in the draft, but I'd recomm= end > DoH clients to: >=20 > * Set their Agent to 'DoH client', no matter what browser/library > * Do not pass non-essential HTTP headers (like language) > * Do not allow the DoH server to set cookies > * Ponder TLS sessions resumption data settings > * Think about all other ways in which HTTP can be tracked (HSTS?) >=20 > Thoughts? Thanks for this, I find it rather important to avoid introducing new data= =20 collection opportunities (at the resolver) that haven't been there on pla= in DNS=20 and support your recommendations to minimize data exposure. Ideally all DoH clients look the same from the DoH server perspective. This this will never be completely the case but we should try to minimize= the DoH client fingerprintability. I hope the minimization of the DoH client fingerprint becomes a mandatory= part in the document. This is also in-line with the spirit of RFC6973 Privacy Considerations for Internet Protocols specifically section 6.1 and 7.1 https://tools.ietf.org/html/rfc6973#section-6.1 https://tools.ietf.org/html/rfc6973#section-7.1 "What identifiers could be omitted or be made less identifying while still fulfilling the protocol's goals?" is always a good question to ask. kind regards, nusenu --=20 https://twitter.com/nusenu_ --NV1FVcX1HgOrKVWqB9N2x0N8jhYDuKkJB-- --18voAP4bskIJOsYI52BS11BRrwKiwM2Kn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsnqlMACgkQrWE4wkXN Qn5Lpw//Tm7p0u8nFWMZX+rL/QcRBLKbIHQvR2uzunaPqpgYAyhr/8LSkt+uBWpV DJHLdo69B1jkvLlyjn7q7nlqkGXjE0qJEEWhgChwvae6ORuEqyhcdH5eov2i1a6B Rctq+RJc0pON0MnjJrMpsSbVMkZC5q05mWSIosk933/2oZ7jwzfDRO59VId3dVBg 96gfKc+ZxOA9Yz/5e9wDSClTXQi8Jha6+GvICb9SuGUeQmCfWCB6TM1QgYhPei1X mI2o1rTfrTpfZs4uQudBlp1o/JeD2mork16XcFb9IrybTwlATBqzYADbwFpLS2DJ VTT0407KwDsElXSsi3gLaC/RR1O0cqA5OXHu00pL5Nh1BrlMLOFqvtDBej/13oy4 nv5z6NzhkqC8AExdhudwMvU/v7CLZeag5INc5SGmp7oh3V1LIXC226365ePFuMT7 SMsadq5JXhkpZ8khX8e4Gn2aEuc2ojJQq1iKmIKhNlBieXqqfW84onS8OLNfL/e/ qFer8mxf24m8qj0h5NGs/T0lChr13ivZDlsuBtw0jc9C8js5BsnkMFYU8eryX2IP ckYHhlkIWaJFRaYZZCOmP4lYut3K4XpI9q2gSxkwEiRSXNrdAT1UkxO/3cskQmKp jhtjSAjE0J3K7OKHwL3lwJEEe6Xxs4PJaTbrSoiwQjftlS2+HgM= =yhBb -----END PGP SIGNATURE----- --18voAP4bskIJOsYI52BS11BRrwKiwM2Kn-- From nobody Mon Jun 18 06:47:42 2018 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 5BB03130DE5 for ; Mon, 18 Jun 2018 06:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 ZVLntsJ98qsB for ; Mon, 18 Jun 2018 06:47:35 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 78A75124C04 for ; Mon, 18 Jun 2018 06:47:35 -0700 (PDT) Received: from [62.232.251.194] (port=22353 helo=[192.168.12.23]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fUuVF-0005jq-Ud; Mon, 18 Jun 2018 14:47:34 +0100 From: Sara Dickinson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9D354BD8-8A7F-4E58-86BD-EF13C54D51FE" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 18 Jun 2018 14:47:25 +0100 In-Reply-To: Cc: DoH WG , bert hubert To: nusenu References: <20180618112116.GB9195@server.ds9a.nl> X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 13:47:40 -0000 --Apple-Mail=_9D354BD8-8A7F-4E58-86BD-EF13C54D51FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jun 2018, at 13:49, nusenu wrote: >=20 > Signed PGP part >> As noted, I don't know if this has a place in the draft, but I'd = recommend >> DoH clients to: >>=20 >> * Set their Agent to 'DoH client', no matter what browser/library >> * Do not pass non-essential HTTP headers (like language) >> * Do not allow the DoH server to set cookies >> * Ponder TLS sessions resumption data settings >> * Think about all other ways in which HTTP can be tracked (HSTS?) >>=20 >> Thoughts? >=20 > Thanks for this, I find it rather important to avoid introducing new = data=20 > collection opportunities (at the resolver) that haven't been there on = plain DNS=20 > and support your recommendations to minimize data exposure. >=20 > Ideally all DoH clients look the same from the DoH server perspective. > This this will never be completely the case but we should try to = minimize > the DoH client fingerprintability. >=20 > I hope the minimization of the DoH client fingerprint becomes a = mandatory part > in the document. +1 on this. DNSOP and DPRIVE have both acknowledged that client = identifiers in DNS messages directly compromise user privacy and have = attempted to minimise or mitigate their use (for example see RFC7626, = RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing = the same (or at least no less). >=20 > This is also in-line with the spirit of RFC6973 > Privacy Considerations for Internet Protocols >=20 > specifically section 6.1 and 7.1 > https://tools.ietf.org/html/rfc6973#section-6.1 > https://tools.ietf.org/html/rfc6973#section-7.1 >=20 > "What identifiers could be omitted or be made less > identifying while still fulfilling the protocol's goals?" > is always a good question to ask. And given that the charter says=20 =E2=80=9CThe working group will analyze the security and privacy issues = that could arise from accessing DNS over HTTPS. =E2=80=9C it suddenly strikes me that this draft doesn=E2=80=99t contain a Privacy = Considerations section. I would suggest that one is added to address = this issue and offer to help with text on that.=20 On a technical note do we have 2 use cases to deal with? - one where dedicated connections are used for DoH (i.e. where only DoH = requests are made) - one where DoH requests are intermingled on the same connection with = existing traffic (which will most likely include headers already = identifying the client) Sara.=20 --Apple-Mail=_9D354BD8-8A7F-4E58-86BD-EF13C54D51FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 Jun 2018, at 13:49, nusenu <nusenu-lists@riseup.net> wrote:

Signed PGP = part
As noted, I don't know if this has a place in the draft, but = I'd recommend
DoH clients to:

*= Set their Agent to 'DoH client', no matter what browser/library
* Do not pass non-essential HTTP headers (like language)
* Do not allow the DoH server to set cookies
* = Ponder TLS sessions resumption data settings
* Think about = all other ways in which HTTP can be tracked (HSTS?)

Thoughts?

Thanks = for this, I find it rather important to avoid introducing new data
collection opportunities (at the resolver) that haven't been = there on plain DNS
and support your recommendations to = minimize data exposure.

Ideally all DoH = clients look the same from the DoH server perspective.
This = this will never be completely the case but we should try to minimize
the DoH client fingerprintability.

I hope the minimization of the DoH client fingerprint becomes = a mandatory part
in the document.

+1 on this. DNSOP and DPRIVE have both = acknowledged that client identifiers in DNS messages directly compromise = user privacy and have attempted to minimise or mitigate their use (for = example see RFC7626, RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be = doing the same (or at least no less).


This is also in-line with the = spirit of RFC6973
Privacy Considerations for Internet = Protocols

specifically section 6.1 and = 7.1
https://tools.ietf.org/html/rfc6973#section-6.1
https://tools.ietf.org/html/rfc6973#section-7.1

"What identifiers could be omitted or be made = less
identifying while still fulfilling the protocol's = goals?"
is always a good question to = ask.

And given that = the charter says 
=E2=80=9CThe working group will analyze = the security and privacy issues that
could arise from = accessing DNS over HTTPS. =E2=80=9C

it= suddenly strikes me that this draft doesn=E2=80=99t contain a Privacy = Considerations section. I would suggest that one is added to address = this issue and offer to help with text on that. 

On a technical note do we have 2 use cases to deal = with?
- one where dedicated connections are used for DoH (i.e. = where only DoH requests are made)
- one where DoH requests are = intermingled on the same connection with existing traffic (which will = most likely include headers already identifying the = client)

Sara. 

= --Apple-Mail=_9D354BD8-8A7F-4E58-86BD-EF13C54D51FE-- From nobody Mon Jun 18 07:25:40 2018 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 D781A126DBF for ; Mon, 18 Jun 2018 07:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 4U5mONpeoB-k for ; Mon, 18 Jun 2018 07:25:36 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7741C120049 for ; Mon, 18 Jun 2018 07:25:36 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id D8F093A02C for ; Mon, 18 Jun 2018 10:25:32 -0400 (EDT) Received: by mail-oi0-f45.google.com with SMTP id 188-v6so14946383oid.12 for ; Mon, 18 Jun 2018 07:25:32 -0700 (PDT) X-Gm-Message-State: APt69E12Y9x5MnfusOvGChPC+1b8sfOjydKp9NVBcUxB3dTmDU/i53Rf LRQq81LBP+OHl8cM0ECGVsCZZhTm3Yfk9OOcahA= X-Google-Smtp-Source: ADUXVKIvfo9TZnXQAKK7TiGz6wQgau8j+QuV6ZWp1rtbPUbhAGIM3ZSuWFKHTe890hTzYfWuUQ9mDjokdSIA9/ZaQkk= X-Received: by 2002:aca:a88b:: with SMTP id r133-v6mr7437047oie.213.1529331932505; Mon, 18 Jun 2018 07:25:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 07:25:31 -0700 (PDT) In-Reply-To: References: <20180618112116.GB9195@server.ds9a.nl> From: Patrick McManus Date: Mon, 18 Jun 2018 10:25:31 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: nusenu , DoH WG , bert hubert Content-Type: multipart/alternative; boundary="00000000000094af06056eeb5652" Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 14:25:39 -0000 --00000000000094af06056eeb5652 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the interest of moving forward, given that we've completed wglc a couple of times, I'm going to incorporate this as a ietf last-call comment and include text as part of that cycle.. there is surely something useful that can be written in the big picture, this is something that I would like to see handled by BCP56-bis, but doesn't seem to be addressed at all there. That's probably a good comment for that draft. some more specific things to consider when writing text that come to my mind: * content negotiation is something doh clients will want to do as a normal part of http, and most of this information is related.. e.g. accept-languag= e * many headers leak state but are tied to http features that clients might choose to participate in anyhow (e.g. cache revalidation headers) * versioning information helps prevent bugs from becoming defacto features forever. * authentication is a normal thing to do * there are lots of headers that we don't know about - and that's ok. Let's provide advice rather than be a whitelisting firewall. * entities other than DoH clients and DoH servers participate in a DoH exchange (proxies, lb, etc) so be aware that there is an asymmetry between send and recv in this spec. (i.e. you can say a DoH client cannot send Foo, but you cannot say that a DoH server receiving Foo is a protocol error because generic HTTP in between might add it.) wrt Sara's specific comment about the differences between connection contexts - that's not a difference the core semantic layer of HTTP presents. from that pov HTTP is stateless. its often not something the client interface exposes very well, and is certainly not necessarily an end to end property. So any text in that neighborhood probably needs to be along the lines of fyi. So I think DoH will need to say something fairly generic along the lines of "think about the meta data tradeoffs and explicitly enable features you need". On Mon, Jun 18, 2018 at 9:47 AM, Sara Dickinson wrote: > > > On 18 Jun 2018, at 13:49, nusenu wrote: > > Signed PGP part > > As noted, I don't know if this has a place in the draft, but I'd recommen= d > DoH clients to: > > * Set their Agent to 'DoH client', no matter what browser/library > * Do not pass non-essential HTTP headers (like language) > * Do not allow the DoH server to set cookies > * Ponder TLS sessions resumption data settings > * Think about all other ways in which HTTP can be tracked (HSTS?) > > Thoughts? > > > Thanks for this, I find it rather important to avoid introducing new data > collection opportunities (at the resolver) that haven't been there on > plain DNS > and support your recommendations to minimize data exposure. > > Ideally all DoH clients look the same from the DoH server perspective. > This this will never be completely the case but we should try to minimize > the DoH client fingerprintability. > > I hope the minimization of the DoH client fingerprint becomes a mandatory > part > in the document. > > > +1 on this. DNSOP and DPRIVE have both acknowledged that client > identifiers in DNS messages directly compromise user privacy and have > attempted to minimise or mitigate their use (for example see RFC7626, > RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing > the same (or at least no less). > > > This is also in-line with the spirit of RFC6973 > Privacy Considerations for Internet Protocols > > specifically section 6.1 and 7.1 > https://tools.ietf.org/html/rfc6973#section-6.1 > https://tools.ietf.org/html/rfc6973#section-7.1 > > "What identifiers could be omitted or be made less > identifying while still fulfilling the protocol's goals?" > is always a good question to ask. > > > And given that the charter says > =E2=80=9CThe working group will analyze the security and privacy issues t= hat > could arise from accessing DNS over HTTPS. =E2=80=9C > > it suddenly strikes me that this draft doesn=E2=80=99t contain a Privacy > Considerations section. I would suggest that one is added to address this > issue and offer to help with text on that. > > On a technical note do we have 2 use cases to deal with? > - one where dedicated connections are used for DoH (i.e. where only DoH > requests are made) > - one where DoH requests are intermingled on the same connection with > existing traffic (which will most likely include headers already > identifying the client) > > Sara. > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --00000000000094af06056eeb5652 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the interest of moving forward, given that we'= ve completed wglc a couple of times, I'm going to incorporate this as a= ietf last-call comment and include text as part of that cycle.. there is s= urely something useful that can be written

in = the big picture, this is something that I would like to see handled by BCP5= 6-bis, but doesn't seem to be addressed at all there. That's probab= ly a good comment for that draft.

some more sp= ecific things to consider when writing text that come to my mind:
* content negotiation is something doh clients will want to do as a normal= part of http, and most of this information is related.. e.g. accept-langua= ge
* many headers leak state but are tied to http features th= at clients might choose to participate in anyhow (e.g. cache revalidation h= eaders)
* versioning information helps prevent bugs from becoming= defacto features forever.
* authentication is a normal thing to = do
* there are lots of headers that we don't know about -= and that's ok. Let's provide advice rather than be a whitelisting = firewall.
* entities other than DoH clients and DoH servers p= articipate in a DoH exchange (proxies, lb, etc) so be aware that there is a= n asymmetry between send and recv in this spec. (i.e. you can say a DoH cli= ent cannot send Foo, but you cannot say that a DoH server receiving Foo is = a protocol error because generic HTTP in between might add it.)

wrt Sara's specific comment about the differences bet= ween connection contexts - that's not a difference the core semantic la= yer of HTTP presents. from that pov HTTP is stateless. its often not someth= ing the client interface exposes very well, and is certainly not necessaril= y an end to end property. So any text in that neighborhood probably needs t= o be along the lines of fyi.

So I think DoH wi= ll need to say something fairly generic along the lines of "think abou= t the meta data tradeoffs and explicitly enable features you need".


= On Mon, Jun 18, 2018 at 9:47 AM, Sara Dickinson <sara@sinodun.com> wrote:


On 18 Jun 2018, at 13:49, nusenu <nusenu-lists@riseup.net> wrote:
Signed PGP part
As n= oted, I don't know if this has a place in the draft, but I'd recomm= end
DoH clients to:

* Set their Agent to 'DoH client', no= matter what browser/library
* Do not pass non-essential HTTP headers (l= ike language)
* Do not allow the DoH server to set cookies
* Ponder T= LS sessions resumption data settings
* Think about all other ways in whi= ch HTTP can be tracked (HSTS?)

Thoughts?

Thanks = for this, I find it rather important to avoid introducing new data
coll= ection opportunities (at the resolver) that haven't been there on plain= DNS
and support your recommendations to minimize data exposure.
Ideally all DoH clients look the same from the DoH server perspective.
= This this will never be completely the case but we should try to minimizethe DoH client fingerprintability.

I hope the minimization of the = DoH client fingerprint becomes a mandatory part
in the document.

+1 on this. DNS= OP and DPRIVE have both acknowledged that client identifiers in DNS message= s directly compromise user privacy and have attempted to minimise or mitiga= te their use (for example see RFC7626, RFC7871 or=C2=A0draft-tale-dns= op-edns0-clientid). The DoH WG should be doing the same (or at = least no less).


This is also in-line with the spirit of RFC697= 3
Privacy Considerations for Internet Protocols

specifically sect= ion 6.1 and 7.1
https://tools.ietf.org/html/rfc6973#section-6.1<= /a>
https://tools.ietf.org/html/rfc6973#section-7.1
"What identifiers could be omitted or be made less
identifying whi= le still fulfilling the protocol's goals?"
is always a good que= stion to ask.

And given that = the charter says=C2=A0
=E2=80=9CThe working group will analyze th= e security and privacy issues that
could arise from accessing DNS= over HTTPS. =E2=80=9C

it suddenly strikes me that= this draft doesn=E2=80=99t contain a Privacy Considerations section. I wou= ld suggest that one is added to address this issue and offer to help with t= ext on that.=C2=A0

On a technical note do we have = 2 use cases to deal with?
- one where dedicated connections are u= sed for DoH (i.e. where only DoH requests are made)
- one where D= oH requests are intermingled on the same connection with existing traffic (= which will most likely include headers already identifying the client)

Sara.= =C2=A0


______________________________= _________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--00000000000094af06056eeb5652-- From nobody Mon Jun 18 08:32:19 2018 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 A943D130EBF for ; Mon, 18 Jun 2018 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 tx78nXMfTg5T for ; Mon, 18 Jun 2018 08:32:07 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE57130E08 for ; Mon, 18 Jun 2018 08:32:07 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 23F941A0C59 for ; Mon, 18 Jun 2018 08:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529335927; bh=xBOjwwGNwy6NP2WpWVvjW8iDPjcdE1n025ChslumYDk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HLY3mOJEbskdUSMXiVyvNlop4nFWXg2/2un0KPbpgDnFP0VkdNGeH1eW7MoURPQGx Ov6v2b7ppG9MBOcEzxOn3w0uXt7njdxt3/Vs2J+/zgtwEvDVy3FCcC+n0u6a8zZIZd 0LXOFGLhCwVC/WjnGci/Z7THSknVJZ5Hvrj55XYY= X-Riseup-User-ID: C0964C13136FB0833FD01E5DF85ECD2B3B92E122AAAAEC6990E07DC5B3414F01 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 4C39AC6E81 for ; Mon, 18 Jun 2018 08:32:06 -0700 (PDT) To: doh@ietf.org References: <20180618112116.GB9195@server.ds9a.nl> 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: <5f32b800-9aa8-6b19-2983-3dbf5419ea9a@riseup.net> Date: Mon, 18 Jun 2018 15:31:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DVhhs27luUchgPKdhjGIYB71HAudn2nJQ" Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 15:32:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DVhhs27luUchgPKdhjGIYB71HAudn2nJQ Content-Type: multipart/mixed; boundary="ZBGp77JANSRgzEkaGy9DFtBU6ZWclFTTC"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <5f32b800-9aa8-6b19-2983-3dbf5419ea9a@riseup.net> Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS References: <20180618112116.GB9195@server.ds9a.nl> In-Reply-To: --ZBGp77JANSRgzEkaGy9DFtBU6ZWclFTTC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable >> This is also in-line with the spirit of RFC6973 >> Privacy Considerations for Internet Protocols >> >> specifically section 6.1 and 7.1 >> https://tools.ietf.org/html/rfc6973#section-6.1 >> https://tools.ietf.org/html/rfc6973#section-7.1 >> >> "What identifiers could be omitted or be made less >> identifying while still fulfilling the protocol's goals?" >> is always a good question to ask. >=20 > And given that the charter says=20 > =E2=80=9CThe working group will analyze the security and privacy issues= that > could arise from accessing DNS over HTTPS. =E2=80=9C Thanks for citing this, it nails the problem pretty much. Privacy problems arising from the specific combination of DNS over HTTPS and their mitigation should be in the scope of the document. > it suddenly strikes me that this draft doesn=E2=80=99t contain a Privac= y Considerations section. I would suggest that one is added to address th= is issue and offer to help with text on that.=20 +1 for a Privacy Consideration section (in fact I was looking for it alre= ady). Given the discussion in this thread: https://twitter.com/PowerDNS_Bert/status/1008081220603916289 I would also find it helpful to define the threat model (i.e. DoH server = is not necessarily ultimately trusted and data minimization still makes sense ev= en=20 if you are trusting the DoH server to learn your DNS queries - or especia= lly because you give it your queries you don't want to allow him to identify/track Do= H clients or link all the queries to a single DoH client). Queries alone are also potentially enoug= h to identify/link someone. > On a technical note do we have 2 use cases to deal with? > - one where dedicated connections are used for DoH (i.e. where only DoH= requests are made) > - one where DoH requests are intermingled on the same connection with e= xisting traffic (which will most likely include headers already identifyi= ng the client) I was thinking about the same problem that would arise from a single conn= ection being used for DoH server (no cookies) and for "normal" web content (with cookies) r= equests. Depending on how a DoH client implement a 'no cookies for DoH servers' pr= otection [1] it might allow a DoH server to link a cookie to a DoH client if cookie an= d non-cookie requests are multiplexed over the same connection. [1] https://twitter.com/mcmanusducksong/status/1008374832923279360 btw: Is this a typo in the charter? "This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS [RFC 785= 7], ..." RFC 7857 vs. RFC 7858? --=20 https://twitter.com/nusenu_ --ZBGp77JANSRgzEkaGy9DFtBU6ZWclFTTC-- --DVhhs27luUchgPKdhjGIYB71HAudn2nJQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsn0G4ACgkQrWE4wkXN Qn6/chAAzsUtNu3Vgs5ZACiOcT7TZYR5Ci5KIfZNyCd+nWXOjZDKjZrqleqWxz0w gJC2lBBYt2X73aQ/8aBvXBQPBu8dWDty6F5pYkh1XH1n8rDV5qq9u2jE527wakuO 7IEvk9/ubGu4TcsZiuwt18vy+xShgvwt1mycS7qlRKxgBX8KwH/dZEtUI7y1hC0c cza6exjcSFdSAiKsbhXOOypOilRbdHqTfg+RpCM1q5NECN7yxjxBdZUzwTPoOnTK SFO2myUxtocHBJti/UU46SsURcxuSpIF2fsyfgTf+3BaELRpbOu0DQbsvIvY5vBA dUzpkxnxBddpqoVXIn06YtDkC+Amcl56s/bwvUfWgmfSN9RiockrkUWj/RKZPden UjsVWCDc4W16sXPKuvtL4KY7z2pTEA4H5wRuvyYBRNjGTMD7ZvFLhP7sHBT8jxlt qAwpseIvrOxJ5BEnf8E+PqwFvxdMoqUNHrYrWdG7mqfezFcx8FddlXLo+q3t3FI0 8GftJvqcx80eNw7uyPghyr8gGAjjN6JZ7YEym5oPSj0rN5yTJMXfVxo4a2yBzuVu TRv16JrY20Veg4tuEgekLNOGBfRPlpFjxQAr780ddJ6es/sVGBWO7SEILTLGnL2z 31fmWu++32IChtGREAlS5WeY0Z6oi/BIysa+K7o1qb3l6hAYdiY= =OfXC -----END PGP SIGNATURE----- --DVhhs27luUchgPKdhjGIYB71HAudn2nJQ-- From nobody Mon Jun 18 08:33:08 2018 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 555D1130DF2 for ; Mon, 18 Jun 2018 08:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 VzWUwVYy12xf for ; Mon, 18 Jun 2018 08:33:01 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC713130DE8 for ; Mon, 18 Jun 2018 08:32:35 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 9F4461A0A45 for ; Mon, 18 Jun 2018 08:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529335955; bh=IXpCjhTvho0Ma9XGYMshNxS8UGYB+fVOVTvsmkPFTaI=; h=To:From:Subject:Date:From; b=jp+vp+SA5uXczUmOZfONMKl5tKPPyNbymRc/qmtRDFk5bmYmXEDs2DGNydplNmKFz 0pW9gYoANSvjGo2l1cywMSq8zd6eYSJeNNrXmXJ61BC/Exs1P5+fLol2gXnZM1toON JW0IpQDU1Y5SKH9nGHxRd+OsQSNCxUTpaiQ8WH50= X-Riseup-User-ID: C4335CC3DAB7F9586ED5D4A829332D057E6E23A7D235F36B63FC524BF96B48F8 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id B3A60C6E81 for ; Mon, 18 Jun 2018 08:32:34 -0700 (PDT) To: doh@ietf.org 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: <1e670055-b488-7b64-f24a-026857585fb2@riseup.net> Date: Mon, 18 Jun 2018 15:32:00 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dKd8YEm8kYAaLwOQtOwpvr2ZTAs4gBwZ2" Archived-At: Subject: [Doh] small typo ("client" missing) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 15:33:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dKd8YEm8kYAaLwOQtOwpvr2ZTAs4gBwZ2 Content-Type: multipart/mixed; boundary="enR2vC4gd9TIwgALnj0aJZGFdNbgqoya3"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <1e670055-b488-7b64-f24a-026857585fb2@riseup.net> Subject: small typo ("client" missing) --enR2vC4gd9TIwgALnj0aJZGFdNbgqoya3 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable in the security consideration section (9): is: > DoH Servers can also add DNS padding [RFC7830] if > the DoH requests it in the DNS query. probably should be: > DoH Servers can also add DNS padding [RFC7830] if > the DoH client requests it in the DNS query. and btw thanks for the renaming it is much better --=20 https://twitter.com/nusenu_ --enR2vC4gd9TIwgALnj0aJZGFdNbgqoya3-- --dKd8YEm8kYAaLwOQtOwpvr2ZTAs4gBwZ2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsn0I8ACgkQrWE4wkXN Qn5GOQ/+LTFGPLmozHD0wIIC3QGMB1rQKnME+C4H2b718QTVVSFbWVn3GcmNo9SI UlVS75hw1UF5djCnyV99cDdaCrQoxlheXrHmWatYOx6Tnissl6rgup3MzdBef9Bj Cidq8iPnP5Ww9746BMG7Z2VbVEwwrAnFZUu825KvbRiasy5VrIFBigZGUo20KLvh aJ4yHh7G6HgLbqqewNLjYpwAMrNwLKRM6XKs17Q3yNKK8RdbvHc6JzjMOj6Hc4w5 4hhboOeBrX0HAsqe2eZn8xPpnagcKvFv8LEEwB0mw3WJtjw93Xe52+ovuyOYZl2o PoJFeqeTYzJi47FwqwvOVKM0WPf50MkzBh6v/4la9rWFh3b/qfKrlXi0/59ttjWP ROpOKwnlkThhGnvBdG/NRdTBtj0wLbekzKVpLfiBEs/Ai73pHQjSI/Du/4/VdXfC H7v9bMK4nMvynJt3xbJuopuGNDkMoWCJ7T8Mp/2OLzEbUOejCZ/YB7UvqmloNj+I IqJj1dN7WfQ7u+0rD0fH6pg71byt3hAbWVjxKbCES+mE8SeLDNAUgMgxu54P3EUm gMvEKEK2/Ilg1heyVOwx9OFHTAnCEeAryV/mHwqJNHEt439yqIbgWYcNNmwfyWUR pvcz4V8fZdGWbA9unI2PNYBRXMgTPhlm4bWzEMKXH4DAakzsn+M= =dkf9 -----END PGP SIGNATURE----- --dKd8YEm8kYAaLwOQtOwpvr2ZTAs4gBwZ2-- From nobody Mon Jun 18 09:01:20 2018 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 7A423130DF6 for ; Mon, 18 Jun 2018 09:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 4aV4lK39Y87Z for ; Mon, 18 Jun 2018 09:01:12 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002096.outbound.protection.outlook.com [40.92.2.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02BF130E01 for ; Mon, 18 Jun 2018 09:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u8S8Cm/DBzWQpKBd6633U2rG9+7DmF0k4nx9Cy794bw=; b=s6lTDgYE7i1G3ZNQfFZ7EWsbk+vw2wUkq9zxNcVuz+RbKPWnIm7uMBgmhPF2xLwuPMVcB9cuUrdgJAtjm+UzsWbEK06Od7fQdTYT2ehW5YGq7WZg988UpT2YUBzsnSSutCaNB1Wyjzp+O4e9bYZHKkZSFqSlAVJmnu8jkmxmjK7ID4Lb41BlrtRPXMAC5SA/eCN6B8R5g9/9U69Dw8SwOepthEylxSZDazmaIopcztV8AN1gBDhnPPIBLwzh987PUI+M/+APcQa5QqRXxDDN4lZbgcb7k3P8IjpIiZAb7YIQibj01nZKQVEzYh+rQxlK1Ctk63kQM0qU7l47dyDynA== Received: from SN1NAM01FT020.eop-nam01.prod.protection.outlook.com (10.152.64.59) by SN1NAM01HT159.eop-nam01.prod.protection.outlook.com (10.152.64.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.863.11; Mon, 18 Jun 2018 16:00:45 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.64.58) by SN1NAM01FT020.mail.protection.outlook.com (10.152.65.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.863.11 via Frontend Transport; Mon, 18 Jun 2018 16:00:45 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::4067:c141:d328:eca3]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::4067:c141:d328:eca3%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 16:00:45 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] some privacy ponderings wrt HTTPs and plain DNS Thread-Index: AQHUBvaAmxaW+Q43B0mG8u9JY8anIaRmFHwl Date: Mon, 18 Jun 2018 16:00:45 +0000 Message-ID: References: <20180618112116.GB9195@server.ds9a.nl> In-Reply-To: <20180618112116.GB9195@server.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:DC8EAF62D2E79008A9EC02CB5567FD96A6A9B79F88C71F32D399812AF72FB3FE; UpperCasedChecksum:6FE93A02F65EB91BD4F13C78646B22778FA07879CE7945943E845515A8C84BB9; SizeAsReceived:7079; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [tks0o/C3PwDyhU7iUAr0Ppune1bhbZhAT+9gyb2lCdFvZ865gvQAgA==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM01HT159; 7:BRcjvS5mhDSDquYSwUqWGIEBF9/v4jX6t2cl2YdB8qmG3n4BC6dJP4BTiqK3t2EYf6d3k/HcoOfvPaU6PbXBgMh8TxvMmNLxt5xewqNajEAV8C94XBGZH8pWgEMiU5iAgrQ+CfwIJ5Pd+pOE26TlgQIqAON4m0dmkXZcQMwE6R8ts9xn0vJ/DLIPWR1nCCOkfxuxPUmoYsPclB6hfQiqiVpYv9+BCqWmJ8Qro7fjaL1WowXP8xFKxX2eLZKSgwxY x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101448)(1701031045); SRVR:SN1NAM01HT159; x-ms-traffictypediagnostic: SN1NAM01HT159: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM01HT159; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT159; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(57704003)(6346003)(8676002)(81156014)(2351001)(76176011)(97736004)(5250100002)(7696005)(1730700003)(59450400001)(6506007)(2900100001)(86362001)(486006)(102836004)(3660700001)(476003)(2501003)(5660300001)(8936002)(73972006)(3280700002)(446003)(46003)(11346002)(20460500001)(104016004)(33656002)(106356001)(966005)(68736007)(229853002)(105586002)(99286004)(74316002)(25786009)(6246003)(83332001)(6436002)(87572001)(14454004)(305945005)(5640700003)(82202002)(6916009)(9686003)(6306002)(55016002)(91040200002)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM01HT159; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: 6Bep9dx/SRjgLNU9Mf5gWZ5w1TJXszZ3sVc3SsZGWzFhOxTIuQfnqbZkGypEsRoKuyY9nLH+n2RjOfvudEEQ8sdX0iUSvZ7lQMB0WDSi6nLfwzcGDjSWvm9+TiJVL2WndoxPgexNz05PaZqjkVLd7UnFl8JMnbN1xcsFNaLwgGZ7i9bj5u5D2Y8Cvq2EelFO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: be7aca60-659f-486d-89f5-08d5d534a697 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 16:00:45.2077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT159 Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:01:15 -0000 Hi, I don't think we should not make it default, because most people need these= things. We shouldn't include these in the standard either, since it is pur= ely implementation dependent. You may want to disable these features for your own preference. And you may= develop, use, or recommend a client software that has options to disable t= hese features. Let me describe them item by item (sorry it's long): ***** > * Set their Agent to 'DoH client', no matter what browser/library Usually we need to include the software versions, mainly because older soft= ware may contain bugs, we need to take special care of them. (e.g. Some old= clients may use the obsolete application/dns-udpwireformat or message/dns = MIME types, so we need to be compatible.) Also, we need to give warning or stop service for certain clients that are = known to serious security flaws. Otherwise, the users may not be aware that= they need to install security patches. Third, it is useful if we can give separate error messages for human (brows= er) and standalone clients. Users may accidentally click into a DoH URL wit= hout any intention to do DNS query. Do we need to give them a 400 error, or= a 302 redirect to a human-readable help page? ***** > * Do not pass non-essential HTTP headers (like language) For browsers, we usually cannot control it through XHR API. For standalone clients, nobody would send extra headers since that requires= extra code. Since we cannot do anything to change it, I think it is useless to talk abo= ut it. ***** > * Do not allow the DoH server to set cookies Do you know RFC7873? Yes, there is already a Cookie system for traditional = DNS protocol. And many public DNS services are already using it to protect = against DDoS attack. Additionally, since DoH protocol usually relies on Keep-Alive connections (= otherwise it would be painfully slow), a single connection usually correspo= nd to a single user or a single group of users, isn't it? Similar to RFC7873 Cookie, HTTP Cookie also serves as a tool to defend serv= ers from DDoS attacks, and is already widely adapted by many leading CDN pr= oviders. My suggestions is to give the user an option to disable Cookies, or limit C= ookies to a very short lifetime (e.g. 2 minutes). So I think it is better to provide an option instead of making the choice f= or the user. A "disable Cookie" option is already implemented in my impleme= ntation of DoH protocol suite (check below for the software). ***** > * Ponder TLS sessions resumption data settings I am not familiar with this protocol. I guess disabling it will make connec= tions much slower? (200x CPU time according to CloudFlare blog.) Anyhow either enabling or disabling it does not affect security, because ag= ain, DoH usually relies on Keep-Alive connections and the user's IP can be = tracked. Since this feature can be turned on or off solely on the client side, you c= an just use a client that disables this feature, without relying anything f= rom the server. ***** > * Think about all other ways in which HTTP can be tracked (HSTS?) I don't think HSTS can be a problem if we always copy-and-paste DoH URLs. You may run a non-standard DoH server through plaintext HTTP protocol for d= ebugging or other purposes. But we strongly disrecommends using any DoH URL= that does not starts with "https:". ***** Extra A: Keep-Alive and Tor I just talked about Keep-Alive. Since DoH runs over HTTP/2, Keep-Alive is n= ormally enabled. If you are worried about it, you can run a non-standard Do= H client with HTTP/1.0 over HTTPS. Please be warned that this is non-standa= rd, and painfully slow, and burdens the server that may cause your IP to be= banned by them. If you use DoH through Tor, I recommend you try CloudFlare's DoH hidden ser= vice. It's fast, secure, and private. (Disclaimer: This is purely a persona= l recommendation and is not related with any promotional activities) ***** Extra B: ECS and IP tracking I consider RFC7871 (EDNS Client Subnet) an important feature with DoH. This= protocol is used by many traditional servers to provide geolocationally-ne= ar results. Servers without ECS rely on Anycast. Anycast does not solve all problems, especially for some countries where co= mpeting ISPs deprioritize inter-ISP traffic. (e.g. China Mobile -> Hong Kon= g Mobile has lower ping than China Mobile -> China Telecom) For DoH, which is TCP traffic, Anycast becomes much more difficult so DoH s= ervice providers may want to deploy ECS on their servers. A serious issue e= merges since ECS submits part of the client's IP address (/24 or /48) to th= e authoritative DNS server. Some users like this feature, while others hate= it for privacy reasons. A positive scenario of this feature is one of my user from China deployed a= DoH server outside China, submitting a Chinese IP address through ECS prot= ocol so he can enjoy an MITM-less DNS life but can also watch videos withou= t lag from CDN servers located in the same ISP with him. (DNS MITM is deplo= yed country-wide inside China.) I thought about this feature seriously and decided to provide an option for= the user in my own implementation. Good news is that, if disabled, I will = even send a flag telling upstreams to turn off any already enabled-by-defau= lt ECS features. ***** Conclusions: I agree that some users need the features Bert Hubert have just enumerated.= But for most of the time, these features would decrease service satisfacto= ry for the users. Users would not prefer DoH if DoH is much slower, or is not DDoS-resistant,= or is not GeoDNS-compliant, or is simply not secure enough (privacy !=3D s= ecurity). So let's make them options. The world is colorful if DoH implementations ar= e different from each other: some care about privacy and some do good on li= ghtning speed. ***** My implementation: I took my own DoH implementation as an example of providing abundant option= s for the sake of users' privacy. If you want to check it and give suggestions to it, please refer to https:/= /github.com/m13253/dns-over-https . --=20 Best regards, StarBrilliant= From nobody Mon Jun 18 09:06:26 2018 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 5298D130DF6 for ; Mon, 18 Jun 2018 09:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 tHjluM-xwP1O for ; Mon, 18 Jun 2018 09:06:22 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 3F338130DF5 for ; Mon, 18 Jun 2018 09:06:22 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by linode64.ducksong.com (Postfix) with ESMTPSA id 28FCE3A02A for ; Mon, 18 Jun 2018 12:06:20 -0400 (EDT) Received: by mail-oi0-f44.google.com with SMTP id l22-v6so15336095oib.4 for ; Mon, 18 Jun 2018 09:06:20 -0700 (PDT) X-Gm-Message-State: APt69E2pa8EhsAQQE4hx/T7cSoyVvnjXRGRzFu/7pGtKmhQNHStNYLa3 KkLssbme89c5DjN1spb5u8He6gxq7pHMK/CwN3g= X-Google-Smtp-Source: ADUXVKLX/d/Lc/yUWiPpgDvKuXSTULenZVTVEuQ5NKv2fkGkV0J9YFTneGBZp8CLTzU7mFJGol/gmwJlJsvsGLqBthc= X-Received: by 2002:aca:acb:: with SMTP id k72-v6mr6837702oiy.132.1529337979873; Mon, 18 Jun 2018 09:06:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 09:06:19 -0700 (PDT) In-Reply-To: <1e670055-b488-7b64-f24a-026857585fb2@riseup.net> References: <1e670055-b488-7b64-f24a-026857585fb2@riseup.net> From: Patrick McManus Date: Mon, 18 Jun 2018 12:06:19 -0400 X-Gmail-Original-Message-ID: Message-ID: To: nusenu Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000085301056eecbf61" Archived-At: Subject: Re: [Doh] small typo ("client" missing) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:06:25 -0000 --000000000000085301056eecbf61 Content-Type: text/plain; charset="UTF-8" thanks - reflected in github/editor's-copy On Mon, Jun 18, 2018 at 11:32 AM, nusenu wrote: > in the security consideration section (9): > > is: > > > DoH Servers can also add DNS padding [RFC7830] if > > the DoH requests it in the DNS query. > > probably should be: > > > DoH Servers can also add DNS padding [RFC7830] if > > the DoH client requests it in the DNS query. > > > > > > and btw thanks for the renaming it is much better > > -- > > https://twitter.com/nusenu_ > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000085301056eecbf61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks - reflected in github/editor's-copy
<= div>


On Mon, Jun 18, 2018 at 11:32 AM, nusenu <nusenu-l= ists@riseup.net> wrote:
in = the security consideration section (9):

is:

> DoH Servers can also add DNS padding [RFC7830] if
> the DoH requests it in the DNS query.

probably should be:

> DoH Servers can also add DNS padding [RFC7830] if
> the DoH client requests it in the DNS query.





and btw thanks for the renaming it is much better

--

https://twitter.com/nusenu_


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--000000000000085301056eecbf61-- From nobody Mon Jun 18 09:36:26 2018 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 BDBD3130DF6 for ; Mon, 18 Jun 2018 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 lCB7mEm4Bno5 for ; Mon, 18 Jun 2018 09:36:20 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 EBA33130DF9 for ; Mon, 18 Jun 2018 09:36:19 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=52504) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fUx8X-0002Vk-8e; Mon, 18 Jun 2018 17:36:18 +0100 From: Sara Dickinson Message-Id: <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9403FD35-809D-4F4B-A55D-44EDE8A7685B" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 18 Jun 2018 17:36:11 +0100 In-Reply-To: Cc: nusenu , DoH WG , bert hubert To: Patrick McManus References: <20180618112116.GB9195@server.ds9a.nl> X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:36:24 -0000 --Apple-Mail=_9403FD35-809D-4F4B-A55D-44EDE8A7685B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jun 2018, at 15:25, Patrick McManus = wrote: >=20 > In the interest of moving forward, given that we've completed wglc a = couple of times, I'm going to incorporate this as a ietf last-call = comment and include text as part of that cycle.. there is surely = something useful that can be written Erm, did you mean IESG not IETF LC? >=20 > in the big picture, this is something that I would like to see handled = by BCP56-bis, but doesn't seem to be addressed at all there. That's = probably a good comment for that draft. >=20 > some more specific things to consider when writing text that come to = my mind: > * content negotiation is something doh clients will want to do as a = normal part of http, and most of this information is related.. e.g. = accept-language > * many headers leak state but are tied to http features that clients = might choose to participate in anyhow (e.g. cache revalidation headers) > * versioning information helps prevent bugs from becoming defacto = features forever. > * authentication is a normal thing to do > * there are lots of headers that we don't know about - and that's ok. = Let's provide advice rather than be a whitelisting firewall. > * entities other than DoH clients and DoH servers participate in a DoH = exchange (proxies, lb, etc) so be aware that there is an asymmetry = between send and recv in this spec. (i.e. you can say a DoH client = cannot send Foo, but you cannot say that a DoH server receiving Foo is a = protocol error because generic HTTP in between might add it.) Thanks for the list=E2=80=A6 it certainly provides context to understand = that HTTP as a substrate brings a significant overhead (as well as all = the benefits of such bells and whistles). So I think what I am hearing here is that the use of DoH effectively = comes at the price of accepting that additional overhead and all its = potential privacy/tracking issues because in practice it is rather = impossible and/or impractical to have =E2=80=98bare=E2=80=99 DoH that = transmits only as much information about the user as, for example, = typical DNS-over-TLS? I see the trade-offs here, I just want to make sure I understood = correctly=E2=80=A6. >=20 > wrt Sara's specific comment about the differences between connection = contexts - that's not a difference the core semantic layer of HTTP = presents. from that pov HTTP is stateless. its often not something the = client interface exposes very well, and is certainly not necessarily an = end to end property. So any text in that neighborhood probably needs to = be along the lines of fyi. >=20 > So I think DoH will need to say something fairly generic along the = lines of "think about the meta data tradeoffs and explicitly enable = features you need=E2=80=9D. So from a privacy point of view there is no clear way at the protocol = level to separate DoH traffic from other HTTPS traffic? In other words = any considerations of data minimisation would have to be framed in that = context (i.e. DoH traffic can=E2=80=99t necessarily be isolated)? Sara.=20 >=20 >=20 > On Mon, Jun 18, 2018 at 9:47 AM, Sara Dickinson > wrote: >=20 >=20 >> On 18 Jun 2018, at 13:49, nusenu > wrote: >>=20 >> Signed PGP part >>> As noted, I don't know if this has a place in the draft, but I'd = recommend >>> DoH clients to: >>>=20 >>> * Set their Agent to 'DoH client', no matter what browser/library >>> * Do not pass non-essential HTTP headers (like language) >>> * Do not allow the DoH server to set cookies >>> * Ponder TLS sessions resumption data settings >>> * Think about all other ways in which HTTP can be tracked (HSTS?) >>>=20 >>> Thoughts? >>=20 >> Thanks for this, I find it rather important to avoid introducing new = data=20 >> collection opportunities (at the resolver) that haven't been there on = plain DNS=20 >> and support your recommendations to minimize data exposure. >>=20 >> Ideally all DoH clients look the same from the DoH server = perspective. >> This this will never be completely the case but we should try to = minimize >> the DoH client fingerprintability. >>=20 >> I hope the minimization of the DoH client fingerprint becomes a = mandatory part >> in the document. >=20 > +1 on this. DNSOP and DPRIVE have both acknowledged that client = identifiers in DNS messages directly compromise user privacy and have = attempted to minimise or mitigate their use (for example see RFC7626, = RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing = the same (or at least no less). >=20 >>=20 >> This is also in-line with the spirit of RFC6973 >> Privacy Considerations for Internet Protocols >>=20 >> specifically section 6.1 and 7.1 >> https://tools.ietf.org/html/rfc6973#section-6.1 = >> https://tools.ietf.org/html/rfc6973#section-7.1 = >>=20 >> "What identifiers could be omitted or be made less >> identifying while still fulfilling the protocol's goals?" >> is always a good question to ask. >=20 > And given that the charter says=20 > =E2=80=9CThe working group will analyze the security and privacy = issues that > could arise from accessing DNS over HTTPS. =E2=80=9C >=20 > it suddenly strikes me that this draft doesn=E2=80=99t contain a = Privacy Considerations section. I would suggest that one is added to = address this issue and offer to help with text on that.=20 >=20 > On a technical note do we have 2 use cases to deal with? > - one where dedicated connections are used for DoH (i.e. where only = DoH requests are made) > - one where DoH requests are intermingled on the same connection with = existing traffic (which will most likely include headers already = identifying the client) >=20 > Sara.=20 >=20 >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh = >=20 >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh --Apple-Mail=_9403FD35-809D-4F4B-A55D-44EDE8A7685B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 Jun 2018, at 15:25, Patrick McManus <pmcmanus@mozilla.com> wrote:

In the interest of moving forward, given that = we've completed wglc a couple of times, I'm going to incorporate this as = a ietf last-call comment and include text as part of that cycle.. there = is surely something useful that can be written

Erm, did you mean IESG not IETF LC?


in the big picture, this is something that I would like to = see handled by BCP56-bis, but doesn't seem to be addressed at all there. = That's probably a good comment for that draft.

some more specific = things to consider when writing text that come to my mind:
* content negotiation is something doh clients will want to = do as a normal part of http, and most of this information is related.. = e.g. accept-language
* many headers = leak state but are tied to http features that clients might choose to = participate in anyhow (e.g. cache revalidation headers)
* versioning information helps prevent bugs from becoming = defacto features forever.
* authentication is a = normal thing to do
* there are lots = of headers that we don't know about - and that's ok. Let's provide = advice rather than be a whitelisting firewall.
* entities other than DoH clients and DoH servers participate = in a DoH exchange (proxies, lb, etc) so be aware that there is an = asymmetry between send and recv in this spec. (i.e. you can say a DoH = client cannot send Foo, but you cannot say that a DoH server receiving = Foo is a protocol error because generic HTTP in between might add = it.)

Thanks for the list=E2=80=A6 it certainly provides = context to understand that HTTP as a substrate brings a significant = overhead (as well as all the benefits of such bells and = whistles).

So I think what I am = hearing here is that the use of DoH effectively comes at the price of = accepting that additional overhead and all its potential = privacy/tracking issues because in practice it is rather impossible = and/or impractical to have =E2=80=98bare=E2=80=99 DoH that transmits = only as much information about the user as, for example, typical = DNS-over-TLS?

I see the trade-offs = here, I just want to make sure I understood correctly=E2=80=A6.


wrt Sara's specific comment about the differences between = connection contexts - that's not a difference the core semantic layer of = HTTP presents. from that pov HTTP is stateless. its often not something = the client interface exposes very well, and is certainly not necessarily = an end to end property. So any text in that neighborhood probably needs = to be along the lines of fyi.

So I think DoH will need = to say something fairly generic along the lines of "think about the meta = data tradeoffs and explicitly enable features you need=E2=80=9D.

So from a privacy point of view there is no clear = way at the protocol level to separate DoH traffic from other HTTPS = traffic? In other words any considerations of data minimisation would = have to be framed in that context (i.e. DoH traffic can=E2=80=99t = necessarily be isolated)?

Sara. 



On Mon, Jun 18, 2018 at 9:47 AM, = Sara Dickinson <sara@sinodun.com> wrote:

On 18 Jun 2018, at 13:49, nusenu <nusenu-lists@riseup.net> wrote:

Signed PGP = part
As noted, I don't know if this has a place in = the draft, but I'd recommend
DoH clients to:

* Set their Agent to 'DoH client', no matter = what browser/library
* Do not pass non-essential HTTP = headers (like language)
* Do not allow the DoH server to = set cookies
* Ponder TLS sessions resumption data = settings
* Think about all other ways in which HTTP can be = tracked (HSTS?)

Thoughts?

Thanks for this, I find it rather = important to avoid introducing new data
collection = opportunities (at the resolver) that haven't been there on plain DNS
and support your recommendations to minimize data = exposure.

Ideally all DoH clients look the = same from the DoH server perspective.
This this will never = be completely the case but we should try to minimize
the = DoH client fingerprintability.

I hope the = minimization of the DoH client fingerprint becomes a mandatory part
in the document.
+1 on this. DNSOP and DPRIVE have both = acknowledged that client identifiers in DNS messages directly compromise = user privacy and have attempted to minimise or mitigate their use (for = example see RFC7626, RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing the same (or at = least no less).


This is = also in-line with the spirit of RFC6973
Privacy = Considerations for Internet Protocols

specifically section 6.1 and 7.1
https://tools.ietf.org/html/rfc6973#section-6.1
https://tools.ietf.org/html/rfc6973#section-7.1

"What = identifiers could be omitted or be made less
identifying = while still fulfilling the protocol's goals?"
is always a = good question to ask.

And given that the charter = says 
=E2=80=9CThe working group will analyze = the security and privacy issues that
could arise = from accessing DNS over HTTPS. =E2=80=9C

it suddenly strikes me that this draft = doesn=E2=80=99t contain a Privacy Considerations section. I would = suggest that one is added to address this issue and offer to help with = text on that. 

On a technical note do we have 2 use cases to deal = with?
- one where dedicated connections are used = for DoH (i.e. where only DoH requests are made)
- = one where DoH requests are intermingled on the same connection with = existing traffic (which will most likely include headers already = identifying the client)

Sara. 


_______________________________________________
Doh mailing list
Doh@ietf.org
= https://www.ietf.org/mailman/listinfo/doh


_______________________________________________
Doh = mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

= --Apple-Mail=_9403FD35-809D-4F4B-A55D-44EDE8A7685B-- From nobody Mon Jun 18 10:58:23 2018 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 ABB2E130EE2 for ; Mon, 18 Jun 2018 10:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 bAo4dYPOELfD for ; Mon, 18 Jun 2018 10:58:17 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 E7DD6130EC6 for ; Mon, 18 Jun 2018 10:58:16 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id l6-v6so13274021iti.2 for ; Mon, 18 Jun 2018 10:58:16 -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=ProCGSKJASrRUXFVahn9EeUe6lfSRTct1XhPENeV/dM=; b=IMQ+hNG6oHB6QyzZ7SATIRfCLjPZ3Efnu1fDKSckoEBxTKS3aW5/F8Vd3aPQVk/ciS 4lGqLrf9TZg3jE3XrJHezxQwB26SK17EJMJhWi7Ka6An8bGlguCJgvmbbbsMS2572RxH 054+9BLcjOVIJY5J1Pivivv5b7oY7ElWqUTP6YEYtpvy17ynGvOyxjGfl0YSrqjM28/R tZRh+oPLeYYL0BNNp8BJtL88su+x0Cw4YWgqkfuEPUxCIjkenlOSkMjSHiY6mUMpXxUk ZrRQ91J3s1kydKoylh86kl/M5Cek6blLr8o/nStGnv6ZCopLfMyGQvHlWqIt9yT0V5DN rPtA== 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=ProCGSKJASrRUXFVahn9EeUe6lfSRTct1XhPENeV/dM=; b=SxBNlnj8ftbzc8nhHakDdhtUTQSFWcAf3kX0T1ad0Wu/YRjIuArSHLecSH14LN2k4N VqpKzPGg3UrRQX4OuiLloKvMnS2XcnqH4TzFgK5xdMmZJUrtzZGn4p/AFY1iIq+d1nXV BFL0sJbFCiRUoCkolb+Hfv16hlDsar3KeIrbMbKZXXQY5J6KlotNl4s5yoCtcePZYAXu wm75OSK0fCqL4oyGKz5vOA8DzDbVlJUc7isKJyIgKa+kyHZNY57ETPgKUNWIOYMMN6hL QPtn5k/z5AMGRv+aJNAAlWM2iYAzOOYuE+iPNc2+bX5j3z2cjEUNUrnaPtbN57SAIgbo xX7g== X-Gm-Message-State: APt69E0ABr+QvYNJmku06j/TOhGyHTPxp4LnVEpMKCMMRH2LdP0xsEOL IFxHOZO3P5EJbYRw37mn0fELmbYA2s7PhbtkuunNbA== X-Google-Smtp-Source: ADUXVKKwxouaMeH1i1KFm5EvEjfahAUjbjPwLd/HvAkC4TmMNgztBILVSWTp77mKUtWCLZP56tVQHOp+HGfYNcVxDvQ= X-Received: by 2002:a24:b510:: with SMTP id v16-v6mr10645158ite.87.1529344695887; Mon, 18 Jun 2018 10:58:15 -0700 (PDT) MIME-Version: 1.0 References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> In-Reply-To: <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> From: Ben Schwartz Date: Mon, 18 Jun 2018 13:58:03 -0400 Message-ID: To: Sara Dickinson Cc: Patrick McManus , nusenu-lists@riseup.net, DoH WG , bert.hubert@powerdns.com Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000005efe5c056eee4f63" Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:58:21 -0000 --0000000000005efe5c056eee4f63 Content-Type: multipart/alternative; boundary="00000000000056f8e3056eee4f66" --00000000000056f8e3056eee4f66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 18, 2018 at 12:36 PM Sara Dickinson wrote: > > > On 18 Jun 2018, at 15:25, Patrick McManus wrote: > > In the interest of moving forward, given that we've completed wglc a > couple of times, I'm going to incorporate this as a ietf last-call commen= t > and include text as part of that cycle.. there is surely something useful > that can be written > > > Erm, did you mean IESG not IETF LC? > > > in the big picture, this is something that I would like to see handled by > BCP56-bis, but doesn't seem to be addressed at all there. That's probably= a > good comment for that draft. > > some more specific things to consider when writing text that come to my > mind: > * content negotiation is something doh clients will want to do as a norma= l > part of http, and most of this information is related.. e.g. accept-langu= age > * many headers leak state but are tied to http features that clients migh= t > choose to participate in anyhow (e.g. cache revalidation headers) > * versioning information helps prevent bugs from becoming defacto feature= s > forever. > * authentication is a normal thing to do > * there are lots of headers that we don't know about - and that's ok. > Let's provide advice rather than be a whitelisting firewall. > * entities other than DoH clients and DoH servers participate in a DoH > exchange (proxies, lb, etc) so be aware that there is an asymmetry betwee= n > send and recv in this spec. (i.e. you can say a DoH client cannot send Fo= o, > but you cannot say that a DoH server receiving Foo is a protocol error > because generic HTTP in between might add it.) > > > Thanks for the list=E2=80=A6 it certainly provides context to understand = that HTTP > as a substrate brings a significant overhead (as well as all the benefits > of such bells and whistles). > > So I think what I am hearing here is that the use of DoH effectively come= s > at the price of accepting that additional overhead and all its potential > privacy/tracking issues because in practice it is rather impossible and/o= r > impractical to have =E2=80=98bare=E2=80=99 DoH that transmits only as muc= h information > about the user as, for example, typical DNS-over-TLS? > > I see the trade-offs here, I just want to make sure I understood > correctly=E2=80=A6. > > > wrt Sara's specific comment about the differences between connection > contexts - that's not a difference the core semantic layer of HTTP > presents. from that pov HTTP is stateless. its often not something the > client interface exposes very well, and is certainly not necessarily an e= nd > to end property. So any text in that neighborhood probably needs to be > along the lines of fyi. > > > So I think DoH will need to say something fairly generic along the lines > of "think about the meta data tradeoffs and explicitly enable features yo= u > need=E2=80=9D. > > > So from a privacy point of view there is no clear way at the protocol > level to separate DoH traffic from other HTTPS traffic? In other words an= y > considerations of data minimisation would have to be framed in that conte= xt > (i.e. DoH traffic can=E2=80=99t necessarily be isolated)? > Depending on the client architecture, isolation may or may not be feasible. Depending on the use case, isolation may or may not increase privacy. For example, multiplexing DOH traffic into a single HTTP session with non-DOH HTTP traffic might provide a stronger defense against length and timing analysis. There is very little that we can recommend categorically across the wide variety of potential uses for DOH, but I'm glad the authors are planning to add some text on this topic to help implementers avoid accidental disclosures. > > Sara. > > > > > On Mon, Jun 18, 2018 at 9:47 AM, Sara Dickinson wrote: > >> >> >> On 18 Jun 2018, at 13:49, nusenu wrote: >> >> Signed PGP part >> >> As noted, I don't know if this has a place in the draft, but I'd recomme= nd >> DoH clients to: >> >> * Set their Agent to 'DoH client', no matter what browser/library >> * Do not pass non-essential HTTP headers (like language) >> * Do not allow the DoH server to set cookies >> * Ponder TLS sessions resumption data settings >> * Think about all other ways in which HTTP can be tracked (HSTS?) >> >> Thoughts? >> >> >> Thanks for this, I find it rather important to avoid introducing new dat= a >> collection opportunities (at the resolver) that haven't been there on >> plain DNS >> and support your recommendations to minimize data exposure. >> >> Ideally all DoH clients look the same from the DoH server perspective. >> This this will never be completely the case but we should try to minimiz= e >> the DoH client fingerprintability. >> >> I hope the minimization of the DoH client fingerprint becomes a mandator= y >> part >> in the document. >> >> >> +1 on this. DNSOP and DPRIVE have both acknowledged that client >> identifiers in DNS messages directly compromise user privacy and have >> attempted to minimise or mitigate their use (for example see RFC7626, >> RFC7871 or draft-tale-dnsop-edns0-clientid). The DoH WG should be doing >> the same (or at least no less). >> >> >> This is also in-line with the spirit of RFC6973 >> Privacy Considerations for Internet Protocols >> >> specifically section 6.1 and 7.1 >> https://tools.ietf.org/html/rfc6973#section-6.1 >> >> https://tools.ietf.org/html/rfc6973#section-7.1 >> >> "What identifiers could be omitted or be made less >> identifying while still fulfilling the protocol's goals?" >> is always a good question to ask. >> >> >> And given that the charter says >> =E2=80=9CThe working group will analyze the security and privacy issues = that >> could arise from accessing DNS over HTTPS. =E2=80=9C >> >> it suddenly strikes me that this draft doesn=E2=80=99t contain a Privacy >> Considerations section. I would suggest that one is added to address thi= s >> issue and offer to help with text on that. >> >> On a technical note do we have 2 use cases to deal with? >> - one where dedicated connections are used for DoH (i.e. where only DoH >> requests are made) >> - one where DoH requests are intermingled on the same connection with >> existing traffic (which will most likely include headers already >> identifying the client) >> >> Sara. >> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> >> > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000056f8e3056eee4f66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Jun 18, 2018 at 12:36 PM Sara Dickinson <sara@sinodun.com> wrote:


On 18 Jun 2018, at 15:25, Patrick McM= anus <pmcmanus= @mozilla.com> wrote:

In the interest of moving for= ward, given that we've completed wglc a couple of times, I'm going = to incorporate this as a ietf last-call comment and include text as part of= that cycle.. there is surely something useful that can be written

Erm, did you mean IESG not IE= TF LC?


in the big picture, this is something that I would like to see han= dled by BCP56-bis, but doesn't seem to be addressed at all there. That&= #39;s probably a good comment for that draft.

= some more specific things to consider when writing text that come to my min= d:
* content negotiation is something doh clients will want to do= as a normal part of http, and most of this information is related.. e.g. a= ccept-language
* many headers leak state but are tied to http= features that clients might choose to participate in anyhow (e.g. cache re= validation headers)
* versioning information helps prevent bugs f= rom becoming defacto features forever.
* authentication is a norm= al thing to do
* there are lots of headers that we don't = know about - and that's ok. Let's provide advice rather than be a w= hitelisting firewall.
* entities other than DoH clients and D= oH servers participate in a DoH exchange (proxies, lb, etc) so be aware tha= t there is an asymmetry between send and recv in this spec. (i.e. you can s= ay a DoH client cannot send Foo, but you cannot say that a DoH server recei= ving Foo is a protocol error because generic HTTP in between might add it.)=

Thanks for the list= =E2=80=A6 it certainly provides context to understand that HTTP as a substr= ate brings a significant overhead (as well as all the benefits of such bell= s and whistles).

So I think what I am hearing here= is that the use of DoH effectively comes at the price of accepting that ad= ditional overhead and all its potential privacy/tracking issues because in = practice it is rather impossible and/or impractical to have =E2=80=98bare= =E2=80=99 DoH that transmits only as much information about the user as, fo= r example, typical DNS-over-TLS?

I see the trade-o= ffs here, I just want to make sure I understood correctly=E2=80=A6.

wrt S= ara's specific comment about the differences between connection context= s - that's not a difference the core semantic layer of HTTP presents. f= rom that pov HTTP is stateless. its often not something the client interfac= e exposes very well, and is certainly not necessarily an end to end propert= y. So any text in that neighborhood probably needs to be along the lines of= fyi.

So I think DoH will need to say something fair= ly generic along the lines of "think about the meta data tradeoffs and= explicitly enable features you need=E2=80=9D.

So from a privacy point of view there is no clear= way at the protocol level to separate DoH traffic from other HTTPS traffic= ? In other words any considerations of data minimisation would have to be f= ramed in that context (i.e. DoH traffic can=E2=80=99t necessarily be isolat= ed)?

Depending on the cli= ent architecture, isolation may or may not be feasible.=C2=A0 Depending on = the use case, isolation may or may not increase privacy.=C2=A0 For example,= multiplexing DOH traffic into a single HTTP session with non-DOH HTTP traf= fic might provide a stronger defense against length and timing analysis.

There is very little that we can recommend categoric= ally across the wide variety of potential uses for DOH, but I'm glad th= e authors are planning to add some text on this topic to help implementers = avoid accidental disclosures.
=C2=A0

Sara.=C2=A0




On Mon, Jun 18, 2018 at 9:47 AM, Sara Dickinson <s= ara@sinodun.com> wrote:
=

<= br>
On 18 Jun 2018, at 13:49, nusenu <nusenu-lists@riseu= p.net> wrote:

Signed PGP part
As noted, I don't know if this has a place in the d= raft, but I'd recommend
DoH clients to:

* Set their Agent to = 'DoH client', no matter what browser/library
* Do not pass non-e= ssential HTTP headers (like language)
* Do not allow the DoH server to s= et cookies
* Ponder TLS sessions resumption data settings
* Think abo= ut all other ways in which HTTP can be tracked (HSTS?)

Thoughts?
=

Thanks for this, I find it rather important to avoid intro= ducing new data
collection opportunities (at the resolver) that haven&#= 39;t been there on plain DNS
and support your recommendations to minimi= ze data exposure.

Ideally all DoH clients look the same from the DoH= server perspective.
This this will never be completely the case but we = should try to minimize
the DoH client fingerprintability.

I hope = the minimization of the DoH client fingerprint becomes a mandatory part
= in the document.

+1 on this. DNSOP and DPRIVE have both acknowledged that client id= entifiers in DNS messages directly compromise user privacy and have attempt= ed to minimise or mitigate their use (for example see RFC7626, RFC7871 or= =C2=A0draft-tale-dns= op-edns0-clientid). The DoH WG should be doing the same (or at least= no less).


This is also in-line= with the spirit of RFC6973
Privacy Considerations for Internet Protocol= s

specifically section 6.1 and 7.1
https://tools.ietf.org/htm= l/rfc6973#section-6.1
https://tools.ietf.org/html/rfc6973#section= -7.1

"What identifiers could be omitted or be made less
= identifying while still fulfilling the protocol's goals?"
is al= ways a good question to ask.

= And given that the charter says=C2=A0
=E2=80=9CThe working group = will analyze the security and privacy issues that
could arise fro= m accessing DNS over HTTPS. =E2=80=9C

it suddenly = strikes me that this draft doesn=E2=80=99t contain a Privacy Considerations= section. I would suggest that one is added to address this issue and offer= to help with text on that.=C2=A0

On a technical n= ote do we have 2 use cases to deal with?
- one where dedicated co= nnections are used for DoH (i.e. where only DoH requests are made)
- one where DoH requests are intermingled on the same connection with exi= sting traffic (which will most likely include headers already identifying t= he client)

Sara.=C2=A0


_= ______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


_______________________________________________
Doh mailing list
Doh@ietf.org
https://ww= w.ietf.org/mailman/listinfo/doh

_= ______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--00000000000056f8e3056eee4f66-- --0000000000005efe5c056eee4f63 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCpuRzITB+01f89pDFUmcZg +M2EMFwfJAbliYi1RycW7jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA2MTgxNzU4MTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAXSWf9bTwtIL5LbG792jdz/lYzps059Z2Avd0Kdrn VW156FjWtgIFDtEXz33ditwh5uVAxBTCqeDAg0B1rlEUdnOpruKVvtN6fQaWfP9JHmcsUEVhiphn qipJO1tLbgZ8it5JnjNwTSJo/0ryt46LJMTjgo951WeeSEtpuJEGL9zrW9nuR0uq36rzUKah/Abc Qfj2i/rJMzsmU75Iov2kByinVm3qxcSDsp27vGiyPV0ngEzzYGzBBA97vb4F9D/7i4H2zp17tpw5 w66vHbLfCJuFf6ppp78D6cL2zOzP7dTilKcm2NNECWbwR5mR6HuPGBwTIUhzhFlf1YJ25zxncw== --0000000000005efe5c056eee4f63-- From nobody Mon Jun 18 11:04:10 2018 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 C4BDF130EFF for ; Mon, 18 Jun 2018 11:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 zB8Y8SIpclMq for ; Mon, 18 Jun 2018 11:04:04 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC91130EE2 for ; Mon, 18 Jun 2018 11:04:04 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 540E53A041 for ; Mon, 18 Jun 2018 14:04:02 -0400 (EDT) Received: by mail-oi0-f51.google.com with SMTP id d5-v6so15672238oib.5 for ; Mon, 18 Jun 2018 11:04:02 -0700 (PDT) X-Gm-Message-State: APt69E3G6bu6TBwP/Qn7JiVm1DPVUKG+aUfar7bYq56apcHtrTBLVb8Z SmY8Z8hd6QqyAVnpXRuTW0H8fCANPc8BkFhud4A= X-Google-Smtp-Source: ADUXVKIqwdFFJyLshRQDJCxDgFsLerEnr75J/WuTz/E9GWgL8WCK73P+rxlQIJgQRFGJj7ulZ7LezMtZtYq3fef6c7Y= X-Received: by 2002:aca:d7d6:: with SMTP id o205-v6mr7095451oig.347.1529345041973; Mon, 18 Jun 2018 11:04:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 11:04:01 -0700 (PDT) In-Reply-To: <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> From: Patrick McManus Date: Mon, 18 Jun 2018 14:04:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: Patrick McManus , nusenu , DoH WG , bert hubert Content-Type: multipart/alternative; boundary="000000000000f746aa056eee6345" Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 18:04:08 -0000 --000000000000f746aa056eee6345 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 18, 2018 at 12:36 PM, Sara Dickinson wrote: > > > On 18 Jun 2018, at 15:25, Patrick McManus wrote: > > In the interest of moving forward, given that we've completed wglc a > couple of times, I'm going to incorporate this as a ietf last-call commen= t > and include text as part of that cycle.. there is surely something useful > that can be written > > > Erm, did you mean IESG not IETF LC? > > I think we're talking about the same thing. After the WG shepherd submits the doc to the iesg, they will issue a ietf-wide last call. We can make the additions we're talking about here as part of those inevitable updates. > > in the big picture, this is something that I would like to see handled by > BCP56-bis, but doesn't seem to be addressed at all there. That's probably= a > good comment for that draft. > > some more specific things to consider when writing text that come to my > mind: > * content negotiation is something doh clients will want to do as a norma= l > part of http, and most of this information is related.. e.g. accept-langu= age > * many headers leak state but are tied to http features that clients migh= t > choose to participate in anyhow (e.g. cache revalidation headers) > * versioning information helps prevent bugs from becoming defacto feature= s > forever. > * authentication is a normal thing to do > * there are lots of headers that we don't know about - and that's ok. > Let's provide advice rather than be a whitelisting firewall. > * entities other than DoH clients and DoH servers participate in a DoH > exchange (proxies, lb, etc) so be aware that there is an asymmetry betwee= n > send and recv in this spec. (i.e. you can say a DoH client cannot send Fo= o, > but you cannot say that a DoH server receiving Foo is a protocol error > because generic HTTP in between might add it.) > > > Thanks for the list=E2=80=A6 it certainly provides context to understand = that HTTP > as a substrate brings a significant overhead (as well as all the benefits > of such bells and whistles). > > So I think what I am hearing here is that the use of DoH effectively come= s > at the price of accepting that additional overhead and all its potential > privacy/tracking issues because in practice it is rather impossible and/o= r > impractical to have =E2=80=98bare=E2=80=99 DoH that transmits only as muc= h information > about the user as, for example, typical DNS-over-TLS? > more impractical than impossible - at the extreme, you would be building a mere tunnel rather than really building an HTTP application. But its totally appropriate to highlight that there are various tradeoffs that can be made by implementations. e.g. firefox will not accept server cookies right now on DoH transactions nor will it allow authentication. But, in a different circumstance, a DoH client might want to use cookie-drive auth totally reasonably (imagine a subscription based DoH service) - so its not something the protocol should prohibit but we can mention. > > I see the trade-offs here, I just want to make sure I understood > correctly=E2=80=A6. > > > wrt Sara's specific comment about the differences between connection > contexts - that's not a difference the core semantic layer of HTTP > presents. from that pov HTTP is stateless. its often not something the > client interface exposes very well, and is certainly not necessarily an e= nd > to end property. So any text in that neighborhood probably needs to be > along the lines of fyi. > > > So I think DoH will need to say something fairly generic along the lines > of "think about the meta data tradeoffs and explicitly enable features yo= u > need=E2=80=9D. > > > So from a privacy point of view there is no clear way at the protocol > level to separate DoH traffic from other HTTPS traffic? In other words an= y > considerations of data minimisation would have to be framed in that conte= xt > (i.e. DoH traffic can=E2=80=99t necessarily be isolated)? > > I think you're right - especially when you consider the "HTTP chain" is more than just the originating client. Also note that mixing has very good sides for privacy as well - indeed while there are pros and cons I think mixing is a net good. (it deters traffic analysis, it minimizes handshakes and sni, etc.. while separation tends to be more easily defeated by IP analysis or behavioral correlation by the terminating server) --000000000000f746aa056eee6345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 18, 2018 at 12:36 PM, Sara Dickinson <= sara@sinodun.com&= gt; wrote:


On 18 Jun 2018, at 15:25, Patrick McManus <<= a href=3D"mailto:pmcmanus@mozilla.com" target=3D"_blank">pmcmanus@mozilla.c= om> wrote:

In the interest of moving forward, give= n that we've completed wglc a couple of times, I'm going to incorpo= rate this as a ietf last-call comment and include text as part of that cycl= e.. there is surely something useful that can be written

Erm, did you mean IESG not IETF = LC?


I think we're talking about the same thing. After the WG shepher= d submits the doc to the iesg, they will issue a ietf-wide last call. We ca= n make the additions we're talking about here as part of those inevitab= le updates.
=C2=A0
=

<= /div>
in the big picture, this is something that I would like to see ha= ndled by BCP56-bis, but doesn't seem to be addressed at all there. That= 's probably a good comment for that draft.

some more specific things to consider when writing text that come to my mi= nd:
* content negotiation is something doh clients will want to d= o as a normal part of http, and most of this information is related.. e.g. = accept-language
* many headers leak state but are tied to htt= p features that clients might choose to participate in anyhow (e.g. cache r= evalidation headers)
* versioning information helps prevent bugs = from becoming defacto features forever.
* authentication is a nor= mal thing to do
* there are lots of headers that we don't= know about - and that's ok. Let's provide advice rather than be a = whitelisting firewall.
* entities other than DoH clients and = DoH servers participate in a DoH exchange (proxies, lb, etc) so be aware th= at there is an asymmetry between send and recv in this spec. (i.e. you can = say a DoH client cannot send Foo, but you cannot say that a DoH server rece= iving Foo is a protocol error because generic HTTP in between might add it.= )

Thanks for t= he list=E2=80=A6 it certainly provides context to understand that HTTP as a= substrate brings a significant overhead (as well as all the benefits of su= ch bells and whistles).

So I think what I am heari= ng here is that the use of DoH effectively comes at the price of accepting = that additional overhead and all its potential privacy/tracking issues beca= use in practice it is rather impossible and/or impractical to have =E2=80= =98bare=E2=80=99 DoH that transmits only as much information about the user= as, for example, typical DNS-over-TLS?
=

more impractical than impossible - at the ext= reme, you would be building a mere tunnel rather than really building an HT= TP application. But its totally appropriate to highlight that there are var= ious tradeoffs that can be made by implementations. e.g. firefox will not a= ccept server cookies right now on DoH transactions nor will it allow authen= tication. But, in a different circumstance, a DoH client might want to use = cookie-drive auth totally reasonably (imagine a subscription based DoH serv= ice) - so its not something the protocol should prohibit but we can mention= .
=C2=A0

I= see the trade-offs here, I just want to make sure I understood correctly= =E2=80=A6.


wrt Sara's specific comment about the dif= ferences between connection contexts - that's not a difference the core= semantic layer of HTTP presents. from that pov HTTP is stateless. its ofte= n not something the client interface exposes very well, and is certainly no= t necessarily an end to end property. So any text in that neighborhood prob= ably needs to be along the lines of fyi.

So I think = DoH will need to say something fairly generic along the lines of "thin= k about the meta data tradeoffs and explicitly enable features you need=E2= =80=9D.

So fro= m a privacy point of view there is no clear way at the protocol level to se= parate DoH traffic from other HTTPS traffic? In other words any considerati= ons of data minimisation would have to be framed in that context (i.e. DoH = traffic can=E2=80=99t necessarily be isolated)?


I think you're right - especially when you cons= ider the "HTTP chain" is more than just the originating client. A= lso note that mixing has very good sides for privacy as well - indeed while= there are pros and cons I think mixing is a net good. (it deters traffic a= nalysis, it minimizes handshakes and sni, etc.. while separation tends to b= e more easily defeated by IP analysis or behavioral correlation by the term= inating server)

=C2=A0

--000000000000f746aa056eee6345-- From hyc@symas.com Mon Jun 18 11:47:54 2018 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 DB4B31294D0 for ; Mon, 18 Jun 2018 11:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 xqjP4YEHg20m for ; Mon, 18 Jun 2018 11:47:50 -0700 (PDT) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [52.201.171.122]) (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 390DB130E29 for ; Mon, 18 Jun 2018 11:47:49 -0700 (PDT) Received: from zmcc-5-mta-1.zmailcloud.com (zmcc-5-mta-1.zmailcloud.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 5F32040553 for ; Mon, 18 Jun 2018 13:56:44 -0500 (CDT) Received: from zmcc-5-mta-1.zmailcloud.com (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 29C34C0726 for ; Mon, 18 Jun 2018 13:47:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 1CD05C0670 for ; Mon, 18 Jun 2018 13:47:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H_jH19-01V_3 for ; Mon, 18 Jun 2018 13:47:48 -0500 (CDT) Received: from [192.168.1.204] (unknown [83.136.45.97]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPSA id ADC07C04DD for ; Mon, 18 Jun 2018 13:47:47 -0500 (CDT) To: doh@ietf.org From: Howard Chu Message-ID: <30a7dbe0-96c3-a0bd-c630-42c972d0a732@symas.com> Date: Mon, 18 Jun 2018 19:47:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 SeaMonkey/2.53a1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 18:50:55 -0000 I was asked to poke my head into this conversation. Fwiw I think Sara=20 Dickinson has already raised several valid concerns, but I haven't seen t= hem=20 all being addressed. Sara Dickinson Mon, 18 June 2018 13:47 UTC >=20 >=20 >> On 18 Jun 2018, at 13:49, nusenu ; wrote: >>=20 >> Signed PGP part >>> As noted, I don't know if this has a place in the draft, but I'd reco= mmend >>> DoH clients to: >>>=20 >>> * Set their Agent to 'DoH client', no matter what browser/library >>> * Do not pass non-essential HTTP headers (like language) >>> * Do not allow the DoH server to set cookies >>> * Ponder TLS sessions resumption data settings >>> * Think about all other ways in which HTTP can be tracked (HSTS?) >>>=20 >>> Thoughts? My preference would be that only bare-minimum HTTP requests are ever=20 generated. The whole point of this is to enhance user privacy, you can't = just=20 immediately toss user privacy out the door at step 1. GET foo HTTP/1.1 Host: foo.bar.com I might even go further and drop the "Host:" header: GET foo HTTP/1.0 If this is really going to replace plain DNS over UDP, everything else is= not=20 only breaking privacy but also useless overhead. >> Thanks for this, I find it rather important to avoid introducing new d= ata=20 >> collection opportunities (at the resolver) that haven't been there on = plain DNS=20 >> and support your recommendations to minimize data exposure. >>=20 >> Ideally all DoH clients look the same from the DoH server perspective. >> This this will never be completely the case but we should try to minim= ize >> the DoH client fingerprintability. >>=20 >> I hope the minimization of the DoH client fingerprint becomes a mandat= ory part >> in the document. >=20 > +1 on this. DNSOP and DPRIVE have both acknowledged that client identif= iers in DNS messages directly compromise user privacy and have attempted = to minimise or mitigate their use (for example see RFC7626, RFC7871 or dr= aft-tale-dnsop-edns0-clientid). The DoH WG should be doing the same (or a= t least no less). >=20 >>=20 >> This is also in-line with the spirit of RFC6973 >> Privacy Considerations for Internet Protocols >>=20 >> specifically section 6.1 and 7.1 >> https://tools.ietf.org/html/rfc6973#section-6.1 >> https://tools.ietf.org/html/rfc6973#section-7.1 >>=20 >> "What identifiers could be omitted or be made less >> identifying while still fulfilling the protocol's goals?" >> is always a good question to ask. >=20 > And given that the charter says=20 > =E2=80=9CThe working group will analyze the security and privacy issues= that > could arise from accessing DNS over HTTPS. =E2=80=9C >=20 > it suddenly strikes me that this draft doesn=E2=80=99t contain a Privac= y Considerations section. I would suggest that one is added to address th= is issue and offer to help with text on that. Absolutely. These sections are mandatory now, it's surprising the draft h= as=20 gotten this far without one. > On a technical note do we have 2 use cases to deal with? > - one where dedicated connections are used for DoH (i.e. where only DoH= requests are made) > - one where DoH requests are intermingled on the same connection with e= xisting traffic (which will most likely include headers already identifyi= ng the client) This sounds quite implementation-specific and not really within scope of = this=20 spec. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From nobody Mon Jun 18 14:02:20 2018 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 75189130E39 for ; Mon, 18 Jun 2018 14:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 ubl7Rji9PVdg for ; Mon, 18 Jun 2018 14:02:14 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 9FEAB127148 for ; Mon, 18 Jun 2018 14:02:14 -0700 (PDT) Received: from hydrogen.local (j48230.upc-j.chello.nl [24.132.48.230]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 906748F70 for ; Mon, 18 Jun 2018 23:02:11 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1529355731; bh=XBKv3yrlG33V2x6B6Slg7AZ7WUYpu4TH+c+NkzWkjU4=; h=Subject:To:References:From:Date:In-Reply-To; b=wHIGp3LHIbo7I4kD6/UWNnJjgEILAhr+1lbzr7oQ41FbBnM4Rb5hTaAE7/8frntvk YAL6RcVnGIcRHAY2uflUR7UBrmfjgdNCBm4be5mEZAnKMmKJ0b2BqzqXKyCJsHUbXM Ebwm2LhACOqlxDeYoFFlvEAYLCpWx29MJr1jW1/I= To: doh@ietf.org References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> From: Benno Overeinder Openpgp: preference=signencrypt Message-ID: <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> Date: Mon, 18 Jun 2018 23:02:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:02:18 -0000 On 18/06/2018 20:04, Patrick McManus wrote: > > > On Mon, Jun 18, 2018 at 12:36 PM, Sara Dickinson > wrote: > > Thanks for the list… it certainly provides context to understand > that HTTP as a substrate brings a significant overhead (as well as > all the benefits of such bells and whistles). > > So I think what I am hearing here is that the use of DoH effectively > comes at the price of accepting that additional overhead and all its > potential privacy/tracking issues because in practice it is rather > impossible and/or impractical to have ‘bare’ DoH that transmits only > as much information about the user as, for example, typical > DNS-over-TLS? > > > > more impractical than impossible - at the extreme, you would be building > a mere tunnel rather than really building an HTTP application. But its > totally appropriate to highlight that there are various tradeoffs that > can be made by implementations. e.g. firefox will not accept server > cookies right now on DoH transactions nor will it allow authentication. > But, in a different circumstance, a DoH client might want to use > cookie-drive auth totally reasonably (imagine a subscription based DoH > service) - so its not something the protocol should prohibit but we can > mention.. Thank you, I would certainly appreciate some wording about the consideration (or trade-off) between the various implementation decisions. I understand it is difficult to cover all variants, but as you mention above, one can describe the extremes and how these relate to, for example, privacy considerations used in the DPRIVE WG RFCs and Internet drafts. -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From nobody Mon Jun 18 14:39:59 2018 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 8735A130E45 for ; Mon, 18 Jun 2018 14:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RoxsfqNK0YqA for ; Mon, 18 Jun 2018 14:39:53 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD0E129C6B for ; Mon, 18 Jun 2018 14:39:52 -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; Mon, 18 Jun 2018 14:39:51 -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; Mon, 18 Jun 2018 14:39:51 -0700 From: Paul Hoffman To: Benno Overeinder CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] some privacy ponderings wrt HTTPs and plain DNS Thread-Index: AQHUB0zjWCHz8GK0x0CSSDrpxOrvLg== Date: Mon, 18 Jun 2018 21:39:51 +0000 Message-ID: References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> In-Reply-To: <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> 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: <7CE0AB9256A5E94C8B0482C537B9D443@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:39:56 -0000 On Jun 18, 2018, at 2:02 PM, Benno Overeinder wrote: >=20 > I understand it is difficult to cover all variants, but as > you mention above, one can describe the extremes and how these relate > to, for example, privacy considerations used in the DPRIVE WG RFCs and > Internet drafts. Note that what is being asked for here are a set of privacy considerations = that go beyond what was considered in the DPRIVE WG for DNS-over-TLS, RFC 7= 858. The type of user profiling that triggered this thread also applies to = things like TLS extensions, ordering of messages, TCP behavior in the setup= , and so on, but those considerations were not listed in RFC 7858. --Paul Hoffman= From nobody Mon Jun 18 14:44:16 2018 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 A0903130FEB for ; Mon, 18 Jun 2018 14:44:09 -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 NjNU5IufC48k for ; Mon, 18 Jun 2018 14:44: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 11D34130FD9 for ; Mon, 18 Jun 2018 14:44:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 48B42BE49; Mon, 18 Jun 2018 22:44:01 +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 SNe_4Z1bB64h; Mon, 18 Jun 2018 22:43:59 +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 C2EEFBE39; Mon, 18 Jun 2018 22:43:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1529358239; bh=2+PA//cfKYeeJCSlNOi6f8WBbe8sUMwXc0kFbxelD9U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=igPXA6AcKNUP9zfrRV5vHmylSAzDkMgqnjZ4nAu1+Cd2FsaaUfXwubkonH1VP4Exl nXbpk/r4X4RVsamL0DfvD9K2byDIQmN3+kSVU7iEn1tO8BohtI/yRyEhbNZ59MpkQC B+clAMbslyZvTy5U4yv2OKF6bwZ0cx3g2DPYDbIE= To: Paul Hoffman , Benno Overeinder Cc: "doh@ietf.org" References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ 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+2RuFnxM7BTQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <45d445e5-afbb-907b-ffee-77588ab688fa@cs.tcd.ie> Date: Mon, 18 Jun 2018 22:43:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HzefBT5Z9xVqsCRyBxFbqZW7oKBWzLW72" Archived-At: Subject: Re: [Doh] [Ext] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:44:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HzefBT5Z9xVqsCRyBxFbqZW7oKBWzLW72 Content-Type: multipart/mixed; boundary="999jBYWnYVEaIYzVlXROkXQ1i4cocFLii"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman , Benno Overeinder Cc: "doh@ietf.org" Message-ID: <45d445e5-afbb-907b-ffee-77588ab688fa@cs.tcd.ie> Subject: Re: [Doh] [Ext] some privacy ponderings wrt HTTPs and plain DNS References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> In-Reply-To: --999jBYWnYVEaIYzVlXROkXQ1i4cocFLii Content-Type: multipart/mixed; boundary="------------501E283CCA51004DBDE0341B" Content-Language: en-GB This is a multi-part message in MIME format. --------------501E283CCA51004DBDE0341B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18/06/18 22:39, Paul Hoffman wrote: > On Jun 18, 2018, at 2:02 PM, Benno Overeinder > wrote: >>=20 >> I understand it is difficult to cover all variants, but as you >> mention above, one can describe the extremes and how these relate=20 >> to, for example, privacy considerations used in the DPRIVE WG RFCs >> and Internet drafts. >=20 > Note that what is being asked for here are a set of privacy > considerations that go beyond what was considered in the DPRIVE WG > for DNS-over-TLS, RFC 7858. The type of user profiling that triggered > this thread also applies to things like TLS extensions, ordering of > messages, TCP behavior in the setup, and so on, but those > considerations were not listed in RFC 7858. FWIW, I support the WG doing as much on this as can be done. That that requires additional effort is ok, even if that slows things down a little IMO - I think that's the correct reaction to what I think is new information - new in that we (or me at least;-) didn't consider the delta between DNS/TLS and DNS/HTTPs in these terms before. Cheers, S. >=20 > --Paul Hoffman _______________________________________________ Doh > mailing list Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh >=20 --------------501E283CCA51004DBDE0341B 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/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------501E283CCA51004DBDE0341B-- --999jBYWnYVEaIYzVlXROkXQ1i4cocFLii-- --HzefBT5Z9xVqsCRyBxFbqZW7oKBWzLW72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlsoJ58ACgkQWrL68XsX K+qsWw/+Mku8zMcFcxQrg+qiK0gNnH8M7cKo2RYxU/WWOz2/PafL9R5IkIW2EJm5 AotQsf4wTgrR9CaINWIK47dPQ+0qBWJO3l37SsuSFIQZrhQQwpDpgQDM1zg7uZLl fyZROO0G/Z9JspOG/cIOZZEk6HHY0kabdUc98ANKYopJjFele5ULylQu7XBzcx85 FBxLbCjWBPHSHOWl/1XDrP8BYEndaSwAJ3P54taaAYisElcE83ISunIooIg+AUuY fb2HDoJnI6jIPC3/cHdpYRKmr7X8GMcrrkGxO9cMQXmLoHshxdrbMjDNrxM8rqwp AfIzEh7CTcpw59K9Rq7Pkx6Fb6Wy0k/qY1juLbTQdZRtmuLoVxEyl3b2uibLYD6z jnQaIEwpIFn7PlhtdnLvHY5HUQptgCQGda6SAGqeRvAwuNwbtv7Dti1bQ7nOmqhc e192AwW/EI0QWuduVVbbeyFbXbsiHYyldq/XgHkCLT/jXgYWaKBefhTpKSxJbl9H 3HnD+hskthQQJ4vsfmYmCI0R7IfASfdS6bNKhyDCrqZ9KHSKPj4t5PBzpldyysWh +KvZZF399emqtYU/fajOO73+yjf6/uL01tBUdD+BvJxiNDg9GcPtN4qQfksF0QbE KGaAFsdt2eGkacC0+ULIxqjQMcGNzwn+Qtdb1jzYhPo6rRtidp4= =BXnQ -----END PGP SIGNATURE----- --HzefBT5Z9xVqsCRyBxFbqZW7oKBWzLW72-- From nobody Mon Jun 18 16:29:47 2018 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 EBBB2130E55 for ; Mon, 18 Jun 2018 16:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 8RYf9hKdY8Sl for ; Mon, 18 Jun 2018 16:29:42 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF7F130DBE for ; Mon, 18 Jun 2018 16:29:42 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 1B9011A0D12 for ; Mon, 18 Jun 2018 16:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529364582; bh=6E4sFc5iuxMLi1kqcvxb4FhSxON3PVvcZRB+jYWdkGs=; h=From:Subject:To:References:Date:In-Reply-To:From; b=HTcAwpisTFROwBzQKK7KQc87z1PpM6npsDbqNXRjIRnDiMVBZI7GstdzqnkITW4gr xTUaZOrekJw2Maf+x3jaVGzYO8k+9yGbMxKsyM913AsJNQ3biIcXeg9D/M2hHFy50k ABKIQvgn55oxNDHEuqU0AqL28GsOyj7wW4/PupIM= X-Riseup-User-ID: F140D8EBA0C557ED64777C50AD302A399FC2C86CB472D2A596DBCDEE99F6A0C6 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 42CC6C70D0 for ; Mon, 18 Jun 2018 16:29:40 -0700 (PDT) From: nusenu To: doh@ietf.org References: <20180618112116.GB9195@server.ds9a.nl> 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: <0f89ddf1-4f26-b025-b769-415b74f91b94@riseup.net> Date: Mon, 18 Jun 2018 23:29:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 23:29:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > I don't think we should not make it default, because most people need > these things. We shouldn't include these in the standard either, > since it is purely implementation dependent. > > You may want to disable these features for your own preference. And > you may develop, use, or recommend a client software that has options > to disable these features. Defining the user-agent in the specification is a direct possibility to avoid additional metadata/identifier that is not there in current DNS and _not_ needed to fulfill the protocol goals. By saying "ok those that want to have privacy can set the agent to 'DoH client'" will reduce the anonymity set and therefore the privacy of users. (In fact if you are the only one setting it to 'DoH client' it is worse than doing nothing.) DNS did pretty well without an user agent until now, lets ot add one now in a protocol that aims to enhance privacy. If MUST is not feasible, lets have at least a SHOULD for a static user agent string to encourage a privacy-by-default setting (opt-out, not opt-in). Specifying the user agent string in the draft will increase the likelihood that multiple implementations will look the same at *some* level for the DoH server, which increases the anonymity set and therefore the user's privacy. >> * Set their Agent to 'DoH client', no matter what browser/library > > Usually we need to include the software versions, mainly because > older software may contain bugs, we need to take special care of > them. I agree that data like user-agent strings is helpful for debugging and to implement server-side workarounds for client-side bugs or error handling but the privacy of users - in a protocol that's primary goal is to provide privacy for end users - should be more important than ease-of-debugging for us operators of DoH servers. >> * Do not pass non-essential HTTP headers (like language) > > For browsers, we usually cannot control it through XHR API. > > For standalone clients, nobody would send extra headers since that > requires extra code. I'd suggest to add the recommendation to send minimal headers even if it might be obvious to some. >> * Do not allow the DoH server to set cookies > > Do you know RFC7873? Yes, there is already a Cookie system for > traditional DNS protocol. And many public DNS services are already > using it to protect against DDoS attack. > > Additionally, since DoH protocol usually relies on Keep-Alive > connections (otherwise it would be painfully slow), a single > connection usually correspond to a single user or a single group of > users, isn't it? That will not be the case for all DoH clients. I guess there is no expectation of unlinkability within multiple DNS queries going over a single TCP connection. The concern with cookies is more about linking multiple TCP connections based on the cookie. >> * Ponder TLS sessions resumption data settings > > I am not familiar with this protocol. I guess disabling it will make > connections much slower? (200x CPU time according to CloudFlare > blog.) > > Anyhow either enabling or disabling it does not affect security, > because again, DoH usually relies on Keep-Alive connections and the > user's IP can be tracked. Not all DoH clients will use a single connection to maintain unlinkability properties between some queries. The IP address might not be a meaningful identifier if you do DoH over Tor or it might not be available at all for DoH servers accessed via onion services. https://blog.cloudflare.com/welcome-hidden-resolver/ > Extra A: Keep-Alive and Tor > > I just talked about Keep-Alive. Since DoH runs over HTTP/2, > Keep-Alive is normally enabled. If you are worried about it, you can > run a non-standard DoH client with HTTP/1.0 over HTTPS. Please be > warned that this is non-standard The current draft RECOMMENDS HTTP/2 but does not require it, or did I overlook the HTTP/2 requirement elsewhere? "HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH" - -- https://mastodon.social/@nusenu twitter: @nusenu_ -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsoQFoACgkQrWE4wkXN Qn4K3w//WXsUMviGlqtt/B5PxSY8G6+UftUAdz8049X+nzBCG08VZG2utig1clao ODoWCPfI159HYjOy8ad+nn58zetzVlKFDhbxyZ/UxpjyJMs92pXrjzGQ9gjapQzh /XD29eF8o1t2i1N9fSbvZKWYS4/9skqrootUd40jcDPs0FVL7aXTZI6pHjxP21g9 ZLDUbbGaTwuFf5Gw6g2xBl3Z3Sm2XK4SHZFLPFnl4otynvRIo6ty9txe1+/zSULp lwEjqIRW4rSSlUY4VPsNR8luOp6ojlWFM9EXyvQ8rinbAJEB66Yv0Mp+wT7lKnrM vfeb3O5waKQMTJhydCm+KvDtk+NRRMa0uFMgSPOlNjcELPCpma9fpKFpkEW2jksz Nl21t2itf/r3iG8au4xBbkozadYMghNoEENjFM0NZ56IZxbIye7ASInuCCcMmEOe aciTg/rU512hRNx0lNddJOo2xCLw3qRFtm24qKx3zFhpTS2tKwt5gdJiPY05WC2R hxXdx9dPiV4eu7dLW8JxGu2lkaSDHf+BVLNpko5f6cnlD7U1HSS0FjEBe1RwlBFk sjeO2mD8yiE1Rl7hArmhAKVbMYYC7JzJ/IDPqEjVwgzY8RFbz0F4KzaLwS0lcz7v K0QJLUw+2O5mG6P20G8CGs2ZuWfyqcdEj6Kq3cEfysfcGALntlI= =sYdo -----END PGP SIGNATURE----- From nobody Mon Jun 18 17:34:45 2018 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 DA871130E62 for ; Mon, 18 Jun 2018 17:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 uN5LUYfLFGlr for ; Mon, 18 Jun 2018 17:34:37 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BF6130E79 for ; Mon, 18 Jun 2018 17:34:37 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 01FCA1A0B2B for ; Mon, 18 Jun 2018 17:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529368477; bh=xBBb/fYlff8RTU44k2twlCEduhBhtNxSnKxu81uh5OU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NHGu1tq8Bgu4si7V84PNetNzAue59OVlAL3x/Uke0x5L2bXreKDEvtLVugDugqQDl SlIYcoX+52SIGfZBZdqfWGAqY61eA4dR867h4YR8PRzRm4F5Ner2f35GnbSx1InEwj KhRgtbT94/i5MLYstZ3Xvfw0N5SJmoigt/FZfx6w= X-Riseup-User-ID: A74D305107C8107B1CD6E2C39EA26D0C5D2D00A16A7E8B5E12A11E665AE2F0BE Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 679DBC7011 for ; Mon, 18 Jun 2018 17:34:34 -0700 (PDT) To: doh@ietf.org References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> <45d445e5-afbb-907b-ffee-77588ab688fa@cs.tcd.ie> 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: Tue, 19 Jun 2018 00:34:00 +0000 MIME-Version: 1.0 In-Reply-To: <45d445e5-afbb-907b-ffee-77588ab688fa@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ui6wbfB2qTopH2fKNjGpJNgK8lrTJZmhb" Archived-At: Subject: Re: [Doh] [Ext] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 00:34:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ui6wbfB2qTopH2fKNjGpJNgK8lrTJZmhb Content-Type: multipart/mixed; boundary="7ZSVzkirpRwpufzwQ5hlQbWzRTkB4k6Cx"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: Subject: Re: [Doh] [Ext] some privacy ponderings wrt HTTPs and plain DNS References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> <45d445e5-afbb-907b-ffee-77588ab688fa@cs.tcd.ie> In-Reply-To: <45d445e5-afbb-907b-ffee-77588ab688fa@cs.tcd.ie> --7ZSVzkirpRwpufzwQ5hlQbWzRTkB4k6Cx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable >> Note that what is being asked for here are a set of privacy >> considerations that go beyond what was considered in the DPRIVE WG >> for DNS-over-TLS, RFC 7858. The type of user profiling that triggered >> this thread also applies to things like TLS extensions, ordering of >> messages, TCP behavior in the setup, and so on, but those >> considerations were not listed in RFC 7858. Maybe lets start with the easier things like user-agent and then work towards harder to tackle identifiers? > FWIW, I support the WG doing as much on this as can be done. > That that requires additional effort is ok, even if that slows > things down a little IMO - I think that's the correct reaction > to what I think is new information - new in that we (or me at > least;-) didn't consider the delta between DNS/TLS and DNS/HTTPs > in these terms before. Thanks! The prioritization of strong privacy properties over a faster completion of the specification process is much appreciated. --=20 https://twitter.com/nusenu_ --7ZSVzkirpRwpufzwQ5hlQbWzRTkB4k6Cx-- --Ui6wbfB2qTopH2fKNjGpJNgK8lrTJZmhb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsoT48ACgkQrWE4wkXN Qn6LvhAAt6yoocDzL+swOMxOvZta819LsoIYGrmw1p3PN1Iynag6B9k5OAg1LRvG pJDIG/XqUr6K/VvmmPlEblawqdPMF8DKXmlJJ38jxG9TVyKHf3KxmlDQzzYV5P9Q yDWqgWRzauIW6gWraE4Yi2bbI+NKSIwpH1ZFGpZGn29XywYs8J35yDgqbOFHeVTS ONRCKXYJ/aoRYT+AtyUdi44+AybBzGBM1kO1hrbZHJCJKVUG1ZCrU5D4MzTpCbgo haC7EfmUdE1kPTMcIYpavaZlJG1FvX9FKSXYtoTKFWKFOtKrUYKas9EMQAOWnPy0 s4TVXjv6s0uCSOGFG7/Tgt5vrlN/FNwYZxp6WBaLk9bCduAyxTd+DdxdGGTptvK1 LYE6CeDVRruDb+9G+vi8DihHW2KQ79axfdKWPjeAMxJ3o6Gr8J480zbZMAVeX7n9 tddqlSDFu6b/XQ4WZ0WKAPEaD7R3bXxbsVYOR08GDGomuNdUQhSBV1A93S6XCRRx JIQvLiBdRpOv+ugINW/ktyECd3um7E7bz0ntwuQjH7tqtL+QIcL58XuPbw8b4uZL kbNnejLx9Zk/TiP/9TPSayFAYmdqbmbDUby6Wqb2qiHq8XuvmaHej9mIH0FuamHq 0vNZ0NdDOn9XIvMhU4Gr+/YDoVIyDb0PffgwWORhDaerfDoVIWs= =VGDL -----END PGP SIGNATURE----- --Ui6wbfB2qTopH2fKNjGpJNgK8lrTJZmhb-- From nobody Mon Jun 18 21:45:19 2018 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 6A3A5130ED0 for ; Mon, 18 Jun 2018 21:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 gpZfrntfxFNa for ; Mon, 18 Jun 2018 21:45:16 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-oln040092011066.outbound.protection.outlook.com [40.92.11.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231F7130EB9 for ; Mon, 18 Jun 2018 21:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uiFOf+khB1L0DYkNhmRXAihT0ZwZ7wNzVb3oOKaxNYc=; b=RM9no+rIeIwNSYbKzrTLbO/8I5zp4ZnN6+RtBVHNcP2/bna3+8q/tnVPZRIs21+ZhihfA9sBWfjlHwLmTv3J6Gp16eBHhju0NQVJg8mkdD5dGqDBt6rdbxbQPWM2PY1CHmDKn+GAK8PAiEoAJONZw+fkbz4a1OyksEnZzWroKqsysxMrsiiMC+9zlaRPZGnmvhwv93LdmabZErO0G97PT5MYZoS836FTxnI3Vf2Mk6E4FlTq316V7d9eya05lz+ELJLpATIxe55c8rHdI+yFX0GRY8xdKpxyIcNC+PwE/SbZQrDezuUf5TEDxreqdRn+FIppiOBm9NB+JVLrdVq/1g== Received: from SN1NAM04FT037.eop-NAM04.prod.protection.outlook.com (10.152.88.55) by SN1NAM04HT142.eop-NAM04.prod.protection.outlook.com (10.152.88.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.863.11; Tue, 19 Jun 2018 04:45:14 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.88.56) by SN1NAM04FT037.mail.protection.outlook.com (10.152.88.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.884.17 via Frontend Transport; Tue, 19 Jun 2018 04:45:14 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::4067:c141:d328:eca3]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::4067:c141:d328:eca3%3]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 04:45:14 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] [Ext] some privacy ponderings wrt HTTPs and plain DNS Thread-Index: AQHUB02EGbW+uNcgw02XNu0nBCAwqKRmu9MAgABAyhk= Date: Tue, 19 Jun 2018 04:45:14 +0000 Message-ID: References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> <910b8990-d962-ffd1-caa6-591d60e93e7e@NLnetLabs.nl> <45d445e5-afbb-907b-ffee-77588ab688fa@cs.tcd.ie>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1C35FDDD0B98792CA7C82420E89BEE9192F45FCADF43C6CFCAFDA7835A30DFF6; UpperCasedChecksum:5D2858D0E685C41E5F910E3C6B4A33156FF1B83C96EC2B025F5D7607AA743EC1; SizeAsReceived:7632; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [kRgOsC9mfWjWoH5f+kUAWmBmgKlq86uHIqkflqh8cKF4Ke8sBy0Y+w==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT142; 7:u8qpIieX6VJYwgeVHSACnWzwqQV9pCIMGrXhzLFUCyZ2NQ2DV+EoXHn9H9q2NKk27QY1Z5pnNVFQjh0KiyRJZ4cU+3BBomBJWDM4xgQiRZkbVNOBCZqp6raW7Kkd7c/hAVg3JRGZ+XFXfUnJybfIpe2wg6HyLt24G5Ny/1/irAiqU310iErBSX4jVhlR93xekEKKfu3XlACEUZwx8zvy7iCj/8uXW7dBe5cyXlHJPnWYUm8PH62arTx8tWbee4dN x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045); SRVR:SN1NAM04HT142; x-ms-traffictypediagnostic: SN1NAM04HT142: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM04HT142; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT142; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(2351001)(5640700003)(446003)(82202002)(73972006)(33656002)(102836004)(76176011)(5660300001)(25786009)(7696005)(104016004)(6506007)(68736007)(59450400001)(87572001)(6346003)(486006)(229853002)(6436002)(11346002)(20460500001)(476003)(97736004)(55016002)(1730700003)(46003)(8676002)(93886005)(81156014)(83332001)(2501003)(2900100001)(9686003)(8936002)(3660700001)(5250100002)(6916009)(99286004)(105586002)(14454004)(106356001)(86362001)(305945005)(3280700002)(6246003)(74316002)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT142; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: DYHCbLlNOEfWopec+CAweWQ2ZaGCfXfipOJ63OsfwfdqadJXh8JfzVAezlyORInZvyOCXCu5ZySmZwnX3tX0+606XcguVLeupVjkdfJ7k1BWSjbth7blDwVU4xO4B2ej4oN9WxrVRn8cCco88cfIsBpesoWb/iiE6O65GDmoc/RXXf1aEqiJI6+pZkT0nV3F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: 9b1c83b6-1a1a-4ab9-89b4-08d5d59f72c4 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 04:45:14.3541 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT142 Archived-At: Subject: Re: [Doh] [Ext] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 04:45:18 -0000 >> Extra A: Keep-Alive and Tor >>=20 >> I just talked about Keep-Alive. Since DoH runs over HTTP/2, >> Keep-Alive is normally enabled. If you are worried about it, you can >> run a non-standard DoH client with HTTP/1.0 over HTTPS. Please be >> warned that this is non-standard > >The current draft RECOMMENDS HTTP/2 but does not require it, or >did I overlook the HTTP/2 requirement elsewhere? > >"HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use >with DoH" Sorry I remembered the old text. (It was once a "MUST" in the past.) But what are you expecting with a DoH protocol running over HTTP/1.0? I mean, it is nothing better than a DNS-over-TLS-without-session-resumption= . > I agree that data like user-agent strings is helpful for debugging > and to implement server-side workarounds for client-side bugs or error ha= ndling but > the privacy of users - in a protocol that's primary goal is to provide > privacy for end users - should be more important than ease-of-debugging > for us operators of DoH servers. If you think User-Agent can be a problem, then you shouldn't use TLS either= . When you look at the Client Hello packet, you will find different browsers = have different things in it. Even different versions of a same browser are = not identical. As far as I know, Chinese government use this technique to block certain TL= S protocols, including Tor and OpenVPN. This is far far far more "plaintext fingerprintable" than a User-Agent. Additionally, detecting a server or a client's software version is actually= very easy. I knew there is a certain bug that can't handle ECS headers well in a certa= in version of miekg/dns Go library. I constructed a packet containing this certain header and sent it to CloudF= lare. They crashed and returned nothing. Now I knew CloudFlare's DNS implementation was written in Go. And they even= were even using the old version! (I'm not sure about now.) The client side is the same, as far as I know, miekg/dns has some difficult= y processing some Rcode values. To conclude: Hiding User-Agent does nothing to protect privacy. Oppositely,= hiding User-Agent reduces user's security and service availability. > I guess there is no expectation of unlinkability within multiple > DNS queries going over a single TCP connection. The concern > with cookies is more about linking multiple TCP connections > based on the cookie. Let me explain my worries: I run a public DoH service. Now it is healthy be= cause few people are using. I am afraid it may receive DDoS attack in the f= uture, so I planned to use Cookie challenge (with 2 minutes lifetime) whene= ver I got attacked. What should I do now if I am not allowed to use Cookies?= From nobody Tue Jun 19 05:31:24 2018 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 847F9130EEB for ; Tue, 19 Jun 2018 05:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TfxRtZzKUL8c for ; Tue, 19 Jun 2018 05:31:18 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAEF130EEC for ; Tue, 19 Jun 2018 05:31:17 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 106AD1A0E60 for ; Tue, 19 Jun 2018 05:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529411477; bh=OvUuctYs3fBZg8q84PxgqTdWJAqu1OKZItxzhLzJUpY=; h=To:From:Subject:Date:From; b=rNqyU7q3/um32YuGruR6jJ/ynkk6Ys2CfbeRUn6DUdNL72wBPnkng7SdXbo9zBcg9 jEs+3E6I3L+tAkRcGLvPfNMqBfGs5yV7xNkTJyfLC3qKGyMKxWqGL2Cnwk03T7+jYe pFNbLI7n3wwwY9tjiybKRxJu9hMVSWcM10GGPl6U= X-Riseup-User-ID: E0755984383EF6340187A50AED30BAD3BDCB49786AEA4D6B11DCE28253781DD0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id EDE3DC72C6 for ; Tue, 19 Jun 2018 05:31:15 -0700 (PDT) To: doh@ietf.org 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: <82bf1799-1045-5e68-52e3-7d284e33c414@riseup.net> Date: Tue, 19 Jun 2018 12:31:00 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7ASXGYSeVxdefgIbeFP9K13k30k7PUzJC" Archived-At: Subject: [Doh] Is privacy a DoH protocol goal? (was: some privacy ponderings wrt HTTPs and plain DNS) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 12:31:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7ASXGYSeVxdefgIbeFP9K13k30k7PUzJC Content-Type: multipart/mixed; boundary="Y77R3cP0cZyfY55MQPNrfIVDi8EVig53e"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <82bf1799-1045-5e68-52e3-7d284e33c414@riseup.net> Subject: Is privacy a DoH protocol goal? (was: some privacy ponderings wrt HTTPs and plain DNS) --Y77R3cP0cZyfY55MQPNrfIVDi8EVig53e Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable (split from the original thread to clarify some general questions before talking about how specific issues could be addressed) > If you think User-Agent can be a problem, then you shouldn't use TLS > either. Privacy is about risk reduction there is no 100% safe solution. User-Agent strings are likely to be logged since many/most webserver conf= igurations log it by default. Many operators might store that data even if they have no use for it or n= ot even an intention to store it. I see a value in minimizing fingerprintability (and data collection) even= if it doesn't make it impossible.=20 It boils down to the following question: Is privacy a DoH protocol goal? If privacy is a DoH protocol goal: - Privacy against whom?=20 - Your random eavesdropper on the wire?=20 - Your eavesdropper + resolver? - if the resolver is in scope: sending a non-hardcoded user-agent is cou= nter the protocol goal. - What are reasonable privacy expectations a user might have when using D= oH? Note: It is not entirely clear to me if privacy is a DoH protocol goal si= nce the word "privacy" does not appear in the current draft (11).=20 Sara pointed to the relevant part in the charter: > The working group will analyze the security and privacy issues that > could arise from accessing DNS over HTTPS. I guess "analyze" doesn't include to mitigate privacy issues(?), but the = document aims at giving a overview of what the privacy implications=20 of doing DNS over HTTPS are? Is this a correct interpretation? If DoH's adversary model does not include the resolver: Lets make it clear that the resolver might be able to learn more and trac= k DoH clients more than a current non-DoH resolver is able to track non-DoH clients due to a= ll the privacy implications HTTP has and that people who's threat model includes the resolver might w= ant to use other protocols that don't use HTTP? kind regards, nusenu --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu > Sorry I remembered the old text. (It was once a "MUST" in the past.) >=20 > But what are you expecting with a DoH protocol running over=20 > HTTP/1.0? Nothing, I was merely pointing out that HTTP/2 is not required and clients do not require HTTP/2 for DoH as of the current draft (11). > When you look at the Client Hello packet, you will find different=20 > browsers have different things in it. Even different versions of a=20 > same browser are not identical. As far as I know, Chinese government > use this technique to block certain TLS protocols, including Tor and > OpenVPN. This is far far far more "plaintext fingerprintable" than a > User-Agent. I agree that TLS provides identifiers for fingerprintability, I disagree with "you shouldn't use TLS" because of it or 'we shouldn't care about us= er-agent strings since there are fingerprintability issues in TLS' > Additionally, detecting a server or a client's software version is=20 > actually very easy. I knew there is a certain bug that can't handle=20 > ECS headers well in a certain version of miekg/dns Go library. I=20 > constructed a packet containing this certain header and sent it to=20 > CloudFlare. They crashed and returned nothing. Now I knew=20 > CloudFlare's DNS implementation was written in Go. And they even were > even using the old version! (I'm not sure about now.) The client side > is the same, as far as I know, miekg/dns has some difficulty=20 > processing some Rcode values. >=20 > To conclude: Hiding User-Agent does nothing to protect privacy.=20 It is a well understood that user agent strings provide identifying bits for fingerprinting: https://panopticlick.eff.org/static/browser-uniqueness.pdf https://panopticlick.eff.org/about https://panopticlick.eff.org/ Our disagreement probably arises from non-matching threat models. That is the reason I like to have threat model definitions before discussing mitigations.=20 --Y77R3cP0cZyfY55MQPNrfIVDi8EVig53e-- --7ASXGYSeVxdefgIbeFP9K13k30k7PUzJC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlso94sACgkQrWE4wkXN Qn5l/RAAqRq9FA2rk4RWjyKl6PD639+nagoPPEizkUQWv4/95edxbRlpglE5k2Rq KoXPiXHIJCUgpRRptAJ7wrpUuh1XvM9AUmZOtM5FFPGe66h3FUtBWyQuCc+Ai3ts sugzC2r/GtfVIwbWwzsnp96KAvmwupD62w/YkeeRYUzTvIvz9FRoUGwgt1TYUxMu 1HUXl4agbtQoef2rGWxEJqn7su7nYFSQRrHaX6vwiR5ll1sr0prMyYCAB82ZFJPY ixUg5n+dq3x/vpoV9tqIiEObDyrdxlfONbxmm1p9whi2RyIGBAqAjmra0OtUOZDU Alpw3+UVgf1iVbQ7LQ8Ss9N+y1W9oiT7yQuOi3FZmHoDU4CMEsyT9UwKj+VF+T5K /462kb5A2+6pGve1i1XfJw81WqJXHVc9JkngmakiXJ+9btYcfkXLOd0+ODJKP0zu W46xG/pcyZKdKCRpaSb1rlh/TfxM33ucP2UWeewxlW4Lzu8P6Z0dqdn5vjKrKPA/ v2nHR+ENihzTku1kaEfIfcXItpfb9MNx/WFI+GU0Hdo6K58K1dGx9crJqj7flUC/ S+IG5we7G9VNXjXACJ4fOSmVYpoCzID81E5tn9e1rW3f14kt0mv+j2+szYljkh/F wOKSwfBryq9qc1SEdlprTkjlB54VRseAfB1vJjno8QTXSzXgHaw= =em/x -----END PGP SIGNATURE----- --7ASXGYSeVxdefgIbeFP9K13k30k7PUzJC-- From nobody Tue Jun 19 08:04:13 2018 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 D2AE4130E9F for ; Tue, 19 Jun 2018 08:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 vZB1GezTjAl7 for ; Tue, 19 Jun 2018 08:04:07 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 C8956130DE5 for ; Tue, 19 Jun 2018 08:04:06 -0700 (PDT) Received: from [62.232.251.194] (port=3605 helo=[192.168.12.23]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fVIAq-00083m-Vx; Tue, 19 Jun 2018 16:04:05 +0100 From: Sara Dickinson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3AC9852F-CC1F-4182-A0A2-5EAA7264A86F" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 19 Jun 2018 16:03:54 +0100 In-Reply-To: Cc: nusenu , DoH WG , bert hubert To: Patrick McManus References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:04:10 -0000 --Apple-Mail=_3AC9852F-CC1F-4182-A0A2-5EAA7264A86F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jun 2018, at 19:04, Patrick McManus = wrote: >> On 18 Jun 2018, at 15:25, Patrick McManus > wrote: >>=20 >> In the interest of moving forward, given that we've completed wglc a = couple of times, I'm going to incorporate this as a ietf last-call = comment and include text as part of that cycle.. there is surely = something useful that can be written >=20 > Erm, did you mean IESG not IETF LC? >=20 >=20 > I think we're talking about the same thing. After the WG shepherd = submits the doc to the iesg, they will issue a ietf-wide last call. We = can make the additions we're talking about here as part of those = inevitable updates. Ok, but my point was going to be that=E2=80=A6 doesn=E2=80=99t the = decision on when this issue gets dealt lie with the WG and chairs, not = the document authors? > So I think what I am hearing here is that the use of DoH effectively = comes at the price of accepting that additional overhead and all its = potential privacy/tracking issues because in practice it is rather = impossible and/or impractical to have =E2=80=98bare=E2=80=99 DoH that = transmits only as much information about the user as, for example, = typical DNS-over-TLS? >=20 >=20 > more impractical than impossible - at the extreme, you would be = building a mere tunnel rather than really building an HTTP application. = But its totally appropriate to highlight that there are various = tradeoffs that can be made by implementations. e.g. firefox will not = accept server cookies right now on DoH transactions nor will it allow = authentication. But, in a different circumstance, a DoH client might = want to use cookie-drive auth totally reasonably (imagine a subscription = based DoH service) - so its not something the protocol should prohibit = but we can mention.. OK - so essentially in this specification of DoH the DoH protocol = inherits the privacy qualities of HTTPS, it is not attempting to = maintain or impose those of existing DNS over UDP/TCP/TLS wrt user = identifiability. =20 Given that, here is some text as a proposed starting point for a Privacy = Considerations section - it is intended mainly as an =E2=80=98analysis=E2=80= =99 of the current situation and I fully expect the recommendations at = the end to be the subject of debate :-) Privacy Considerations ---------------------------- When considering how the use of DoH affects user privacy (for example, = compared with DNS over UDP, TCP or TLS) it is helpful to follow the = analysis in both RFC7626 (DNS Privacy Considerations) and RFC6973 = (Privacy Considerations for Internet Protocols).=20 With reference to Section 2.4 of RFC7626 =E2=80=9COn the wire=E2=80=9D: The privacy expectations of a user of DoH are relatively = straightforward: + DoH encrypts DNS traffic and requires authentication of the server. = This clearly mitigates passive surveillance and active attacks = attempting to divert DNS traffic to rogue servers. + The use of port 443 by default and the ability to intermingle DNS = traffic with HTTP traffic on the same connection can preventing on-path = devices from interfering with DNS operations and make DNS traffic = analysis more difficult. With reference to Section 2.5 of RFC7626 =E2=80=9CIn the Servers=E2=80=9D:= HTTP and DNS are very different protocols. There exists a natural = tension between=20 * the wide practice in HTTP to use various headers to optimise HTTP = connections, functionality and behaviour (which can facilitate user = identification and tracking) * and the fact that currently DNS is very tightly encoded and contains = no standardized user identifiers (since they are acknowledged as = compromising user privacy).=20 DNS-over-TLS, for example, would normally contain no client identifiers = in the DNS messages and a resolver would see only a stream of DNS = queries originating from a client IP address. Whereas if DoH clients = commonly include several headers in a DNS message (e.g. user-agent and = accept-language) this could lead to the resolver being able to identify = the source of individual DNS requests not only to a specific end user = device but to a specific application.=20 Additionally, depending on the client architecture, isolation of DNS = queries from other HTTP traffic may or may not be feasible or desirable. = Depending on the use case, isolation of DNS queries from other HTTP = traffic may or may not increase privacy.=20 The picture for privacy considerations and user expectations here is = complex and will require a more detailed analysis for each particular = use case. At the extremes, there may be use cases that attempt to = achieve parity with DNS-over-TLS from a privacy perspective at the cost = of using no identifiable headers, there might be others that provide = feature rich data flows where the low-level origin of the DNS query is = easily identifiable.=20 As guidance, implementors should consider the following: 1. RFC6973 discusses data minimisation in detail and says: =E2=80=9CData minimization mitigates the following threats: = surveillance, stored data compromise, correlation, identification, = secondary use, and disclosure." 2. Implementors should evaluate what identifiers could be omitted or be = made less identifying while still fulfilling the protocol's goals.=20 a. Specifically, implementors SHOULD not use non-essential HTTP = headers in DoH messages and SHOULD set the user agent string to =E2=80=98D= oH client=E2=80=99. b. Implementations SHOULD only accept cookies or allow client = authentication when it is required to fulfil the protocols goals (e.g. a = subscription service with user opt-in). Sara.=20 --Apple-Mail=_3AC9852F-CC1F-4182-A0A2-5EAA7264A86F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 Jun 2018, at 19:04, Patrick McManus <pmcmanus@mozilla.com> wrote:
On 18 Jun 2018, at 15:25, Patrick McManus = <pmcmanus@mozilla.com> wrote:

In the interest = of moving forward, given that we've completed wglc a couple of times, = I'm going to incorporate this as a ietf last-call comment and include = text as part of that cycle.. there is surely something useful that can = be written

Erm, did you mean = IESG not IETF LC?


I think we're talking about the same = thing. After the WG shepherd submits the doc to the iesg, they will = issue a ietf-wide last call. We can make the additions we're talking = about here as part of those inevitable updates.

Ok, but my point was going to be that=E2=80=A6 = doesn=E2=80=99t the decision on when this issue gets dealt lie with the = WG and chairs, not the document authors?

<snip>

So I think what I am hearing = here is that the use of DoH effectively comes at the price of accepting = that additional overhead and all its potential privacy/tracking issues = because in practice it is rather impossible and/or impractical to have = =E2=80=98bare=E2=80=99 DoH that transmits only as much information about = the user as, for example, typical = DNS-over-TLS?


more= impractical than impossible - at the extreme, you would be building a = mere tunnel rather than really building an HTTP application. But its = totally appropriate to highlight that there are various tradeoffs that = can be made by implementations. e.g. firefox will not accept server = cookies right now on DoH transactions nor will it allow authentication. = But, in a different circumstance, a DoH client might want to use = cookie-drive auth totally reasonably (imagine a subscription based DoH = service) - so its not something the protocol should prohibit but we can = mention..

OK - so essentially in this specification of DoH = the DoH protocol inherits the privacy qualities of HTTPS, it is not = attempting to maintain or impose those of existing DNS over UDP/TCP/TLS = wrt user identifiability.  

Given= that, here is some text as a proposed starting point for a Privacy = Considerations section - it is intended mainly as an =E2=80=98analysis=E2=80= =99 of the current situation and I fully expect the recommendations at = the end to be the subject of debate :-)



Privacy Considerations
----------------------------

When = considering how the use of DoH affects user privacy (for example, = compared with DNS over UDP, TCP or TLS) it is helpful to follow the = analysis in both RFC7626 (DNS Privacy Considerations) and RFC6973 = (Privacy Considerations for Internet Protocols). 

With reference to Section 2.4 of RFC7626 =E2=80=9C= On the wire=E2=80=9D:

The privacy expectations of a user of DoH are relatively = straightforward:

+ = DoH encrypts DNS traffic and requires authentication of the server. This = clearly mitigates passive surveillance and active attacks attempting to = divert DNS traffic to rogue servers.
+ The use of = port 443 by default and the ability to intermingle DNS traffic with HTTP = traffic on the same connection can preventing on-path devices from = interfering with DNS operations and make DNS traffic analysis more = difficult.

With = reference to Section 2.5 of RFC7626 =E2=80=9CIn the = Servers=E2=80=9D:

HTTP and DNS are very different protocols. There exists a = natural tension between 
* the wide practice = in HTTP to use various headers to optimise HTTP connections, = functionality and behaviour (which can facilitate user identification = and tracking)
* and the fact that = currently DNS is very tightly encoded and contains no standardized = user identifiers (since they are acknowledged as compromising user = privacy). 

DNS-over-TLS, for example, would normally contain no = client identifiers in the DNS messages and a resolver would see only a = stream of DNS queries originating from a client IP address. Whereas if = DoH clients commonly include several headers in a DNS message (e.g. = user-agent and accept-language) this could lead to the resolver being = able to identify the source of individual DNS requests not only to a = specific end user device but to a specific application. 

Additionally, depending = on the client architecture, isolation of DNS queries from other HTTP = traffic may or may not be feasible or desirable.  Depending on the = use case, isolation of DNS queries from other HTTP traffic may or may = not increase privacy. 

The picture for privacy considerations and user expectations = here is complex and will require a more detailed analysis for each = particular use case. At the extremes, there may be use cases that = attempt to achieve parity with DNS-over-TLS from a privacy perspective = at the cost of using no identifiable headers, there might be others that = provide feature rich data flows where the low-level origin of the DNS = query is easily identifiable. 

As guidance, implementors should = consider the following:

1.  RFC6973 discusses data minimisation in detail and = says:

=E2=80=9CD= ata minimization mitigates the following threats: surveillance, stored = data compromise, correlation, identification, secondary use, and = disclosure."

2. = Implementors should evaluate what identifiers could be omitted or be = made less identifying while still fulfilling the protocol's = goals. 

  a. Specifically, implementors SHOULD not use = non-essential HTTP headers in DoH messages and SHOULD set the user agent = string to =E2=80=98DoH client=E2=80=99.

  b. Implementations SHOULD only = accept cookies or allow client authentication when it is required to = fulfil the protocols goals (e.g. a subscription service with user = opt-in).



Sara. 

= --Apple-Mail=_3AC9852F-CC1F-4182-A0A2-5EAA7264A86F-- From nobody Tue Jun 19 08:28:13 2018 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 9A73C1310FF for ; Tue, 19 Jun 2018 08:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 SvqYFZtBRW9S for ; Tue, 19 Jun 2018 08:28:09 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id BB837130F56 for ; Tue, 19 Jun 2018 08:28:09 -0700 (PDT) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0C3693A055 for ; Tue, 19 Jun 2018 11:28:09 -0400 (EDT) Received: by mail-ot0-f175.google.com with SMTP id a5-v6so79213otf.12 for ; Tue, 19 Jun 2018 08:28:09 -0700 (PDT) X-Gm-Message-State: APt69E0TdW1woKE6YEHJajgX1871eN+dSM0Pi7a5OwokfwpoxPyyWVBj l5pewoONesirYD2FJfQwW9CENQPP4vC70Ob0e8M= X-Google-Smtp-Source: ADUXVKL4d5OcVHa6O/Rf/XTf95Bab55OQsV8Xze6EQvhZCoqshmV1cehV1y56I2CqyFCUdRYb31Ifr4JshFPjtyu95Q= X-Received: by 2002:a9d:2f2a:: with SMTP id h39-v6mr10040560otb.214.1529422088749; Tue, 19 Jun 2018 08:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 08:28:07 -0700 (PDT) In-Reply-To: References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> From: Patrick McManus Date: Tue, 19 Jun 2018 11:28:07 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: Patrick McManus , nusenu , DoH WG , bert hubert Content-Type: multipart/alternative; boundary="0000000000004fe487056f00546d" Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:28:12 -0000 --0000000000004fe487056f00546d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 19, 2018 at 11:03 AM, Sara Dickinson wrote: > > > Ok, but my point was going to be that=E2=80=A6 doesn=E2=80=99t the decisi= on on when this > issue gets dealt lie with the WG and chairs, not the document authors? > Of course! But Ben already announced we were moving to the next phase on May 29th. So I'm just trying to communicate how we get the new issue integrated given where we're at. OK - so essentially in this specification of DoH the DoH protocol inherits > the privacy qualities of HTTPS, it is not attempting to maintain or impos= e > those of existing DNS over UDP/TCP/TLS wrt user identifiability. > I broadly agree. > > Given that, here is some text as a proposed starting point for a Privacy > Considerations section - it is intended mainly as an =E2=80=98analysis=E2= =80=99 of the > current situation and I fully expect the recommendations at the end to be > the subject of debate :-) > > thanks for text! That's helpful... --0000000000004fe487056f00546d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 11:03 AM, Sara Dickinson <= sara@sinodun.com&= gt; wrote:

Ok, but my point was going to be that=E2=80=A6 doesn=E2= =80=99t the decision on when this issue gets dealt lie with the WG and chai= rs, not the document authors?

Of course! But Ben already announced we were moving to the = next phase on May 29th. So I'm just trying to communicate how we get th= e new issue integrated given where we're at.

OK - so essentially in this specification = of DoH the DoH protocol inherits the privacy qualities of HTTPS, it is not = attempting to maintain or impose those of existing DNS over UDP/TCP/TLS wrt= user identifiability. =C2=A0

=

I broadly agree.
=C2=A0

Given that, here is some text as a propos= ed starting point for a Privacy Considerations section - it is intended mai= nly as an =E2=80=98analysis=E2=80=99 of the current situation and I fully e= xpect the recommendations at the end to be the subject of debate :-)
<= div>

thanks for text!= That's helpful...
=C2=A0

--0000000000004fe487056f00546d-- From nobody Tue Jun 19 08:46:27 2018 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 105A8130DE8 for ; Tue, 19 Jun 2018 08:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_DKIMWL_WL_HIGH=-0.01, 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 xzXkyKl2u7Lt for ; Tue, 19 Jun 2018 08:46:23 -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 A6560130DC0 for ; Tue, 19 Jun 2018 08:46:23 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5JFgKM2028403 for ; Tue, 19 Jun 2018 16:46:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Deo2iXA3bT9DNvMLTTeE2E3BXGIgVjEkfmXOdfgvPA8=; b=PvN/He5PthV9EZtHXAR2rtP8pfN287N0wxRtqmHAxIFVo0clnr6nkj7xPhN2ZUOeajfU 6dmtaWrvq/UuqCME9hxbDUjy0BYwsiJjjx8raJfb7xNDq80tvW/tkZlbo0Qu/10Aa8ED WtXJWIR7tQRjKjQg0KBmsf+LgHbeb+zd97IsR27BLGK1z7SQEIPiIZihSTtEoVlVL7Ux ckzxoQ1gxgci834PP6H6EZKLeL4mou+olIRnp2QSh+DJ83LMlNNHFmNr0bOlkzkzZg44 PAbVpK7961U5RmMa1dCfKWSYDSm9utHJrYwZIANpgl4ps+P9ufbzwIvBzqkvb9C6VydN Lg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2jpgqbjsj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Jun 2018 16:46:22 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5JFjicm000795 for ; Tue, 19 Jun 2018 11:46:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jmwvuhnpb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 19 Jun 2018 11:46:20 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 19 Jun 2018 08:46:13 -0700 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 19 Jun 2018 11:46:12 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Tue, 19 Jun 2018 11:46:12 -0400 From: "Hewitt, Rory" To: "doh@ietf.org" Thread-Topic: [Doh] Is privacy a DoH protocol goal? (was: some privacy ponderings wrt HTTPs and plain DNS) Thread-Index: AQHUB8l0SfbunJgsXEifuIV5kdxqMqRntuzw Date: Tue, 19 Jun 2018 15:46:12 +0000 Message-ID: <21a7c2e1b9fc45e0990fd77dcc0c49cd@usma1ex-dag1mb3.msg.corp.akamai.com> References: <82bf1799-1045-5e68-52e3-7d284e33c414@riseup.net> In-Reply-To: <82bf1799-1045-5e68-52e3-7d284e33c414@riseup.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.246] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0117_01D407A9.F932F200" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_08:, , 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-1805220000 definitions=main-1806190176 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_08:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806190175 Archived-At: Subject: Re: [Doh] Is privacy a DoH protocol goal? (was: some privacy ponderings wrt HTTPs and plain DNS) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:46:26 -0000 ------=_NextPart_000_0117_01D407A9.F932F200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Of course it depends on what you mean by 'privacy' versus 'security' versus...well, whatever. Personally I think privacy (as _I_ define it) is a goal of the members of the DoH WG and this mailing list in general, but not necessarily of DoH itself. That all being said, I'm not clear on whether this discussion belongs as part of drafting this spec. If we're not going to include REQUIREMENTS in the spec to limit e.g. which request headers can be sent to a DoH server (which we're not even considering, I hope!), then it seems to me that all this discussion boils down to whether we should include a non-normative section in the spec about "best practices". If that's the case, then two things are clear to me: a) the wording of such a section is relatively unimportant and should be as generic as possible, probably based off Bert Hubert's original bullet points b) it's probably simpler/better to provide references to one or more existing documents which discuss general privacy practices (if they exist) At any rate, I'd hate to see this discussion hold up a final draft. Thanks, Rory -----Original Message----- From: nusenu [mailto:nusenu-lists@riseup.net] Sent: Tuesday, June 19, 2018 5:31 AM To: doh@ietf.org Subject: [Doh] Is privacy a DoH protocol goal? (was: some privacy ponderings wrt HTTPs and plain DNS) (split from the original thread to clarify some general questions before talking about how specific issues could be addressed) > If you think User-Agent can be a problem, then you shouldn't use TLS > either. Privacy is about risk reduction there is no 100% safe solution. User-Agent strings are likely to be logged since many/most webserver configurations log it by default. Many operators might store that data even if they have no use for it or not even an intention to store it. I see a value in minimizing fingerprintability (and data collection) even if it doesn't make it impossible. It boils down to the following question: Is privacy a DoH protocol goal? If privacy is a DoH protocol goal: - Privacy against whom? - Your random eavesdropper on the wire? - Your eavesdropper + resolver? - if the resolver is in scope: sending a non-hardcoded user-agent is counter the protocol goal. - What are reasonable privacy expectations a user might have when using DoH? Note: It is not entirely clear to me if privacy is a DoH protocol goal since the word "privacy" does not appear in the current draft (11). Sara pointed to the relevant part in the charter: > The working group will analyze the security and privacy issues that > could arise from accessing DNS over HTTPS. I guess "analyze" doesn't include to mitigate privacy issues(?), but the document aims at giving a overview of what the privacy implications of doing DNS over HTTPS are? Is this a correct interpretation? If DoH's adversary model does not include the resolver: Lets make it clear that the resolver might be able to learn more and track DoH clients more than a current non-DoH resolver is able to track non-DoH clients due to all the privacy implications HTTP has and that people who's threat model includes the resolver might want to use other protocols that don't use HTTP? kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu > Sorry I remembered the old text. (It was once a "MUST" in the past.) > > But what are you expecting with a DoH protocol running over > HTTP/1.0? Nothing, I was merely pointing out that HTTP/2 is not required and clients do not require HTTP/2 for DoH as of the current draft (11). > When you look at the Client Hello packet, you will find different > browsers have different things in it. Even different versions of a > same browser are not identical. As far as I know, Chinese government > use this technique to block certain TLS protocols, including Tor and > OpenVPN. This is far far far more "plaintext fingerprintable" than a > User-Agent. I agree that TLS provides identifiers for fingerprintability, I disagree with "you shouldn't use TLS" because of it or 'we shouldn't care about user-agent strings since there are fingerprintability issues in TLS' > Additionally, detecting a server or a client's software version is > actually very easy. I knew there is a certain bug that can't handle > ECS headers well in a certain version of miekg/dns Go library. I > constructed a packet containing this certain header and sent it to > CloudFlare. They crashed and returned nothing. Now I knew > CloudFlare's DNS implementation was written in Go. And they even were > even using the old version! (I'm not sure about now.) The client side > is the same, as far as I know, miekg/dns has some difficulty > processing some Rcode values. > > To conclude: Hiding User-Agent does nothing to protect privacy. It is a well understood that user agent strings provide identifying bits for fingerprinting: https://panopticlick.eff.org/static/browser-uniqueness.pdf https://panopticlick.eff.org/about https://panopticlick.eff.org/ Our disagreement probably arises from non-matching threat models. That is the reason I like to have threat model definitions before discussing mitigations. ------=_NextPart_000_0117_01D407A9.F932F200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDYxOTE1NDYxMVowIwYJKoZIhvcNAQkEMRYEFJtKpx+qyt72CUfVHw4jpVSQvByqMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAJ9ZMg6c+f4kYOC142tZmUf64CFnjsgn1x7J7qytRvasTmQ2Z2h95cx65F4v oEgt9NM7pnJqctH/zrs3Olwdo2mvXnXkMgh8rOfrIm6HQDGe2EoGmqWN0Z6Pm5iN49jHJOt8f1kp EEhxp1GNmOFrl2Gvw6cntQF5MbVer3mtoYXQhPMns7eiBTF7BivWGuHVweHzEn8eBNtc+vaXIj2j +pfheWv22NVQR8Jxas5TeCA5JQQgZMMq3D3r4sJtBT+kieTxT19RF4QnHEpdwAY2/8bCmg9uqyic sYvkj/NWvDXYP10MmpGPQO2Gn8aqSkJNSdW3ttPkWul132/5GG2vFEoAAAAAAAA= ------=_NextPart_000_0117_01D407A9.F932F200-- From nobody Tue Jun 19 08:49:12 2018 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 A7230130DE8 for ; Tue, 19 Jun 2018 08:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lkfqvGIPk0eK for ; Tue, 19 Jun 2018 08:49:06 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 CEA0813110F for ; Tue, 19 Jun 2018 08:49:05 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id u4-v6so655731iof.2 for ; Tue, 19 Jun 2018 08:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2dQPGHNMXycLgs8ha69QaKfWpg37hz5hvFPrrmNKMYI=; b=JtKOWdL1ZxD/VMYYvxZrc6cQC360N05UFKuO+gyLuJdjYOdM0pUnXyNuNSu4oBbl+9 TdKZcamjybjEJ7J1DJumFiypHsnSIIwfdK5Rw6N8sYzx+1kv/UBTFjg8Ob1wr3Lev+8T qdwZafSXGUOBC2K9hWQ+iudVUMZPGQx9pIC6rilhoNbQjdIKtaQBe/GgAL+vDxHxi3Kl s8wQMrK0r4FuWscn6S9dS9izOT6sW7cHhjMvthSn9FJf6ZtxR8ugTXgLWC8ND9TnoSDQ nepgqhwMSsxfZsEweNUxEHcCXVEPmqdG9uqBu5QyzxCFXaGWp75snPc9qR9Qj4K3Lu/z eBtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2dQPGHNMXycLgs8ha69QaKfWpg37hz5hvFPrrmNKMYI=; b=f8LZfDg7z5aY6bQVQwgcD714zNbqLbEYNnDXvpKEOm9Tq7pSqemERJTUfXfyl2+/KV 3dREvcksd1dKQSuNe5BfQeZ7vlnKcSfPm2sjWfI8i6v1RxACpy29dFzOwlVMakvLp+EE MZiI8QAn16hZhAXKJ80e4BevnWDh2sIUd0Y1VXf44WTgKoMClWexMMAsYxWaHhyTj8Zv 4PgSGn3VD8n5ss70n513joi0q8RswbZeInF6ZrfjwOdKlMpX95LeZbbWpv35CdM8pz2X IfLwsmQ0qorkSWh84dwDpScywyYsVaSk3uYF7Y8UWEm4kEoy9b3VXRpdE15jzlQaiHGK g99g== X-Gm-Message-State: APt69E2rAUtI0rB5s6LMJcKiMp9J5f8XFZD9p40qxQBnt5CX0xPKh46h R+OGDlu1g17OJuLtWDQgwayVxHt0mQwAFuIUhrM= X-Google-Smtp-Source: ADUXVKKhztzxNd/MHk+z7PwEg0gQkH7L/TSW532GChyUb6sHce2RKNnaXXYBXShHCnn/qw+Y/Jh19PtcxLwRLU8WaXs= X-Received: by 2002:a6b:e619:: with SMTP id g25-v6mr13798176ioh.198.1529423345057; Tue, 19 Jun 2018 08:49:05 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 2002:a4f:d1cc:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 08:49:03 -0700 (PDT) In-Reply-To: References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> From: Erik Nygren Date: Tue, 19 Jun 2018 11:49:03 -0400 X-Google-Sender-Auth: SrR5vR1eimcgnC029Lkf7HGeHsk Message-ID: To: Sara Dickinson Cc: Patrick McManus , nusenu , DoH WG , bert hubert Content-Type: multipart/alternative; boundary="0000000000003184d0056f009fff" Archived-At: Subject: Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:49:08 -0000 --0000000000003184d0056f009fff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 19, 2018 at 11:03 AM, Sara Dickinson wrote: > > > 2. Implementors should evaluate what identifiers could be omitted or be > made less identifying while still fulfilling the protocol's goals. > > a. Specifically, implementors SHOULD not use non-essential HTTP headers > in DoH messages and SHOULD set the user agent string to =E2=80=98DoH clie= nt=E2=80=99. > > b. Implementations SHOULD only accept cookies or allow client > authentication when it is required to fulfil the protocols goals (e.g. a > subscription service with user opt-in). > I'd think we'd want to avoid normative language in the Privacy Considerations? We should be careful about what "non-essential HTTP headers" mean, especially without being much more specific about these. and providing clear guidance in the core specification. Implementations leaving out required headers without clear guidance seems likely to lead to interoperable implementations. Separately on privacy considerations... >From a related thread on DNSOP where Colm MacC=C3=A1rthaigh raised this, do= we need to provide guidance on the rrset ordering side-channel? Or does that apply as a general issue for DPRIVE? The relevant issue is that since cached rrset responses will have a stable ordering of IP addresses to try, if clients receive the same rrset over DoH and go through the IPs in the same order, this makes it visible to an external observer which cached response the two clients received, especially if the same set of IPs share a wide variety of different hostnames. Recommending the client permute the (unordered-by-specification) rrset received and try responses in a pseudo-random order (absent local performance information preferring some over others) both reduces opportunities for this side-channel attack. Regardless of the side-channel privacy issues here, since DoH responses may be cached by design and won't get randomized/roundrobin/etc rrset-sorting applied to each response it likely makes sense to give the guidance that DoH clients should do pseudo-random sorting of received rrsets of only for better load balancing across IPs in the rrsets. Erik --0000000000003184d0056f009fff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 19, 2018 at 11:03 AM, Sara Dickinson <sara@sinodun.com> wrote:
2. Implementors should evaluate what identifiers could be omitt= ed or be made less identifying while still fulfilling the protocol's go= als.=C2=A0

=C2=A0 a. Specifically, implementors SH= OULD not use non-essential HTTP headers in DoH messages and SHOULD set the = user agent string to =E2=80=98DoH client=E2=80=99.

=C2=A0 b. Implementations SHOULD only accept cookies or allow client authe= ntication when it is required to fulfil the protocols goals (e.g. a subscri= ption service with user opt-in).
<= br>
I'd think we'd want to avoid normative language in th= e Privacy Considerations?
We should be careful about what "n= on-essential HTTP headers" mean, especially without being much more sp= ecific about these. and providing clear guidance in the core specification.= =C2=A0 Implementations leaving out required headers without clear guidance = seems likely to lead to interoperable implementations.

Separately on privac= y considerations...

From a rel= ated thread on DNSOP where Colm MacC=C3=A1rthaigh raised this, do we need t= o provide guidance on the rrset ordering side-channel?=C2=A0 Or does that a= pply as a general issue for DPRIVE?=C2=A0 The relevant issue is that since = cached rrset responses will have a stable ordering of IP addresses to try, = if clients receive the same rrset over DoH and go through the IPs in the sa= me order, this makes it visible to an external observer which cached respon= se the two clients received, especially if the same set of IPs share a wide= variety of different hostnames.=C2=A0=C2=A0 Recommending the client permut= e the (unordered-by-specification) rrset received and try responses in a ps= eudo-random order (absent local performance information preferring some ove= r others) both reduces opportunities for this side-channel attack.=C2=A0 Re= gardless of the side-channel privacy issues here, since DoH responses may b= e cached by design and won't get randomized/roundrobin/etc rrset-sortin= g applied to each response it likely makes sense to give the guidance that = DoH clients should do pseudo-random sorting of received rrsets of only for = better load balancing across IPs in the rrsets.

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

=C2=A0
--0000000000003184d0056f009fff-- From nobody Tue Jun 19 17:14:42 2018 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 DCA991311DB for ; Tue, 19 Jun 2018 17:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3sGOOR7SjXuV for ; Tue, 19 Jun 2018 17:14:39 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088B61311D8 for ; Tue, 19 Jun 2018 17:14:38 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 6EF921A0178 for ; Tue, 19 Jun 2018 17:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529453678; bh=8In444HkkzcOAUJkkGDdjUIA3X9Nc4njb85tAx3G95k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kCKV9sO7sbZgFfwOlEzPSDuuhbDEV2cM42YD50+TPo/j1w4Hba5ZBTbM/wVumWQEi JFLvPF4ijd+JyRNDvpsDlo2HEHFDYw7iYzmOARUN02LHfu0eJwz5aQan9lgsn3XYgv NjSlWnP0oBqtHeI3fCknnPLrfnApWrPEVX4F9Grk= X-Riseup-User-ID: 0BF6192DFDF884E8CF2C3C430A9A2E346750DB689D41F6BE3657D18CBF935914 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 815AAC75A5 for ; Tue, 19 Jun 2018 17:14:37 -0700 (PDT) To: doh@ietf.org References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.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: <664439bc-a8f4-1c2f-a43d-dc2b2108a7db@riseup.net> Date: Wed, 20 Jun 2018 00:14:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PqL82Yo1KsZhZvVdoBEYIOZDzXJvsfQIS" Archived-At: Subject: Re: [Doh] Privacy Considerations Section X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 00:14:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PqL82Yo1KsZhZvVdoBEYIOZDzXJvsfQIS Content-Type: multipart/mixed; boundary="ZsZ3loETW7NHi4ftadYhNDDS27PRPVL5U"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <664439bc-a8f4-1c2f-a43d-dc2b2108a7db@riseup.net> Subject: Re: [Doh] Privacy Considerations Section References: <20180618112116.GB9195@server.ds9a.nl> <0D08F629-1719-440D-B4B4-A474CF90B865@sinodun.com> In-Reply-To: --ZsZ3loETW7NHi4ftadYhNDDS27PRPVL5U Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Sara Dickinson wrote: > Privacy Considerations > ---------------------------- thanks for writing this section. I copied it to the file [1] changed the formatting a bit [2] and made some minor changes [3]: - add reference to RFC7858 - be more specific about where DNS traffic is encrypted Should we add recursive-to-recursive as well? (since that can be done with DoH as well) - replace 'resolver' with 'DoH server' - SHOULD not -> SHOULD NOT (RFC2119) These are individual tiny commits so it is easier to cherry pick what one likes and what not. [1] https://github.com/nusenu/draft-ietf-doh-dns-over-https/commit/dde0af= 2d97b92c65f0d2ded239a98c15824e2650 [2] https://github.com/nusenu/draft-ietf-doh-dns-over-https/commit/93f5da= be5197323f568a61c4f5d4f2313c7260d5 [3] https://github.com/nusenu/draft-ietf-doh-dns-over-https/commits/priva= cy_considerations --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --ZsZ3loETW7NHi4ftadYhNDDS27PRPVL5U-- --PqL82Yo1KsZhZvVdoBEYIOZDzXJvsfQIS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlspnGUACgkQrWE4wkXN Qn7Ffw//UcYQONaRb2SnG7F16HhJn8oopWGcEyGXvg/pNZAjLJY3cglFb6iGMJdg TwjR2qQ0ZGnmFWCNP/+h0H2ShZFV9uJcHgI/+LDLNy9qPdglzVbfRwRdb4wpeuEd z6RiaFXNhFiX9heuFYj5IloDMlxTJ8Mhpk5P6oSLF4VJyLX9FyplX3uxs0D1xlSn 5AKoqqg8YtfIPqoTEPmaAoLx2s4OkbcjVroxsd+85E9wESL7Vgeb+u5tbFN/enQf uXff1iN9GkSURqlAmm/GTFW7sPqH1XGh6o/fApG2zTujSiMtNuj53o15QmS+3ZqS VUihtum0IsLqnUqCYtKtaW0hzz8ZpqFi1+mf5Zi3fz+oWB2P4Kw3vvqN/VSaUlj4 a2rREi9gIlI5yBcQUW1w9RQ73AMBrutGTy8wz+Hu1x38tUco/6HW53PxxwUuwTiP Fefi4iRVVdk5TWkJvdqapnwmQDbE5DvPU5rMHVtdtbZpI6GE+I9QDQb2Jp/pLLm1 pyeCSLhoeLJCnYVix7QaAHhcWp2E0fftVIExOvOx5JeYtHtIn9ksY9OhodISz13d KazI/2AjRCdfmFC6zFkisOYF96uemV8U/C75xgiuNAFNUkz/q+Acu4GDvlBkoTDC 070WzalM6Waw72m6xILdDBZxo+E1+LjFnm5xAzqpd0rCfc7uxLg= =uUUh -----END PGP SIGNATURE----- --PqL82Yo1KsZhZvVdoBEYIOZDzXJvsfQIS-- From nobody Wed Jun 20 01:38:59 2018 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 ED383130E55 for ; Wed, 20 Jun 2018 01:38:58 -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 DLrBFyaybpqX for ; Wed, 20 Jun 2018 01:38:57 -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 C5730124BE5 for ; Wed, 20 Jun 2018 01:38:56 -0700 (PDT) Received: from [172.20.6.227] (unknown [172.20.6.227]) by mail.nic.cz (Postfix) with ESMTPSA id 0117360527 for ; Wed, 20 Jun 2018 10:38:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1529483935; bh=jH5uYgzOUGlmM1XauveDLa7dYHQI2o6iP3e0NSqympI=; h=To:From:Date; b=DgMMwZDtU6Vhszf2QG+Bhyuh1XGebxU2iAQusK7xzj0h2LSIb4xQ4vAoe7ZIbjXKB KehQfewR0ZkJQBh3SYZ3tLv0qjSIsSJlrIX7+CRZJAsupznLVB2T5eXtz07ApNI9RN oKpU99ytd82Myq9GuK4qhBkuazXojuVycxae/zUY= To: doh@ietf.org References: <20180618112116.GB9195@server.ds9a.nl> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Wed, 20 Jun 2018 10:38:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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] some privacy ponderings wrt HTTPs and plain DNS X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 08:38:59 -0000 On 18.6.2018 18:00, Star Brilliant wrote: >> * Do not allow the DoH server to set cookies > > Do you know RFC7873? Yes, there is already a Cookie system for traditional DNS protocol. And many public DNS services are already using it to protect against DDoS attack. It is very important to note that DNS cookies are, unlike HTTP cookies, designed to just verify IP addresses and nothing else. I.e. an properly implemented DNS cookies will change once client's IP address changes so DNS cookies cannot be used to track client who is moving across different networks. This is very different property when compared to traditional HTTP cookies which easily facilitate tracking. > Additionally, since DoH protocol usually relies on Keep-Alive connections (otherwise it would be painfully slow), a single connection usually correspond to a single user or a single group of users, isn't it? > > Similar to RFC7873 Cookie, HTTP Cookie also serves as a tool to defend servers from DDoS attacks, and is already widely adapted by many leading CDN providers. > > My suggestions is to give the user an option to disable Cookies, or limit Cookies to a very short lifetime (e.g. 2 minutes). Wouldn't it cause all the DDoS mitigations work only for two minutes? -- Petr Špaček @ CZ.NIC From stappers@stappers.nl Wed Jun 20 01:58:02 2018 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 F161012D7F8 for ; Wed, 20 Jun 2018 01:58:01 -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 XxV4nCnHFGXv for ; Wed, 20 Jun 2018 01:57:59 -0700 (PDT) Received: from gpm.stappers.nl (gpm.stappers.nl [82.161.218.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96D124BE5 for ; Wed, 20 Jun 2018 01:57:59 -0700 (PDT) Received: by gpm.stappers.nl (Postfix, from userid 1000) id 17866304031; Wed, 20 Jun 2018 10:57:57 +0200 (CEST) Date: Wed, 20 Jun 2018 10:57:56 +0200 From: Geert Stappers To: Nicolas Cavallari , Please send any replies to the DoH mailing list at Cc: Kurt H Maier , Mateusz Jo??czyk , dnsmasq-discuss@lists.thekelleys.org.uk Message-ID: <20180620085756.GY30489@gpm.stappers.nl> References: <360883b6-2d1a-a68b-81a2-c7902e29e0f2@o2.pl> <20180614203224.GA45519@wopr> <7da6219a-9ceb-4563-5077-116b6dec6f96@green-communications.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7da6219a-9ceb-4563-5077-116b6dec6f96@green-communications.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Wed, 20 Jun 2018 10:19:05 -0700 Subject: Re: [Doh] [Dnsmasq-discuss] Implementation of DOH in dnsmasq X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 08:59:32 -0000 On Wed, Jun 20, 2018 at 10:11:53AM +0200, Nicolas Cavallari wrote: > On 14/06/2018 22:32, Kurt H Maier wrote: > > On Thu, Jun 14, 2018 at 09:38:42PM +0200, Mateusz Jo??czyk wrote: > >> > >> How difficult would it be to add support to DNS over HTTP/2.0 in dnsmasq, for > >> example in constrained environments like home routers? > >> > > > > This should be handled with a wrapper program. HTTP/2.0 is an enormous > > and ill-defined specification and it would not be appropriate to bolt it > > directly into dnsmasq. A dedicated HTTP/2.0 daemon can talk to dnsmasq > > on the backend to provide this service. Home routers are not > > particularly constrained in this regard, since they generally have web > > services running to begin with. > > It's much more than that. To be secure, TLS requires time, entropy and a CA > list. Many home routers fails at having all three, or require the DNS to get > time and CAs... > > >> Please send any replies to the DoH mailing list at . > > > > Why? > > Because by doing so you will be subjected to the various IETF policies that > applies to anyone participating on the IETF mailing list, which includes > copyright grants, patents disclosure and other things that should be read by a > lawyer. > No new text, just doing the } Please send any replies to the DoH mailing list at . Groeten Geert Stappers Subscriber of mailinglist dnsmasq-discuss@lists.thekelleys.org.uk -- Leven en laten leven From nobody Wed Jun 20 15:05:56 2018 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 58623130EED for ; Wed, 20 Jun 2018 15:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 oVhNChmBlL8D for ; Wed, 20 Jun 2018 15:05:42 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 69C50130F14 for ; Wed, 20 Jun 2018 15:05:42 -0700 (PDT) Received: from mail-ot0-f173.google.com (mail-ot0-f173.google.com [74.125.82.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 50F443A03B for ; Wed, 20 Jun 2018 18:05:40 -0400 (EDT) Received: by mail-ot0-f173.google.com with SMTP id 101-v6so1277771oth.4 for ; Wed, 20 Jun 2018 15:05:40 -0700 (PDT) X-Gm-Message-State: APt69E3bIMnfJ+EOa2Z261/LD2hMlLzlp9K6qIdZX4GAAFhcWaJ+WHtU hq0V/NWCzcOmoy/q3Rk3QijN++SZyI1+dgWrM84= X-Google-Smtp-Source: ADUXVKKmVLIyFFGTmQ00RCFvVpkjkdBfCbZPy6ifRl62C39voY2wSzmF5QwiCEZwVBAM98yTT+jdNRvhB9HLju9P8ZQ= X-Received: by 2002:a9d:2f2a:: with SMTP id h39-v6mr13356484otb.214.1529532340003; Wed, 20 Jun 2018 15:05:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 15:05:39 -0700 (PDT) From: Patrick McManus Date: Wed, 20 Jun 2018 18:05:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: DoH WG Content-Type: multipart/alternative; boundary="000000000000cc686c056f19ff3b" Archived-At: Subject: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:05:54 -0000 --000000000000cc686c056f19ff3b Content-Type: text/plain; charset="UTF-8" Hi All, The authors have a proposed privacy considerations section available as a PR at: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and a snapshot is also included at the end of this email. (though obviously the PR will be a living document). First, thanks for the all the comments and especially to Sara for some of the significant text that made its way into the draft text. The text does not, cannot really, describe the whole universe of http/tls/tcp/ip fingerprinting - but it does raise it as an issue and try to give enough illustrative examples to motivate consideration of these things in your implementation. And in the end, that's its recommendation - consider these things and don't use them blindly. The construction that "DoH inherits the HTTPS profile so understand that please" seems most apt and in scope. It would be really great if we had something published in the HTTP space that deal with this. We don't AFAICT, and that's feedback Mark and I have already started noodling over for HTTPbis. (If we had it, the DoH text would be shorter :)) Comments and discussion are of course welcome - its just a pull request. -Patrick --- # Privacy Considerations {#PrivacyConsiderations} {{RFC7626}} discusses DNS Privacy Considerations in both "On the wire" (Section 2.4), and "On the server" (Section 2.5) contexts. This is also a useful framing for DoH's privacy considerations. ## On The Wire {#OnTheWire} DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance {{RFC7258}} and active attacks attempting to divert DNS traffic to rogue servers ({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides similar protections, while direct UDP and TCP based transports are vulnerable to this class of information leak. Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. ## On The Server {#OnTheServer} A DoH application is built on IP, TCP, TLS, and HTTP. Each layer contains one or more common features that can be used to correlate different queries to the same identity. DoH inherits the privacy properties of the HTTPS stack and is not known to introduce new concerns beyond that of HTTPS. At the IP level, the client address provides obvious correlation information. This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time. It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity. TCP-based solutions may seek performance through the use of TCP Fast Open {{RFC7413}}. The cookies used in TCP Fast Open allow servers to correlate different TCP sessions together. TLS based implementations often achieve better handshake performance through the use of some form of session resumption mechanism such as session tickets {{RFC5077}}. Session resumption creates trivial mechanisms for a server to correlate different TLS connections together. HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, authentication request header fields explicitly identify profiles in use, and HTTP Cookies are designed as an explicit state tracking mechanism between the client and serving site and often are used as an authentication mechanism. Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale. This facilitates content negotiation and operational work-arounds for implementation bugs. Request header fields that control caching can expose state information about a subset of the client's history. Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. --000000000000cc686c056f19ff3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

The authors have a p= roposed privacy considerations section available as a PR at: https://githu= b.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and a snapshot is al= so included at the end of this email. (though obviously the PR will be a li= ving document).

First, thanks for the all the comm= ents and especially to Sara for some of the significant text that made its = way into the draft text.

The text does not, cannot= really, describe the whole universe of http/tls/tcp/ip fingerprinting - bu= t it does raise it as an issue and try to give enough illustrative examples= to motivate consideration of these things in your implementation. And in t= he end, that's its recommendation - consider these things and don't= use them blindly. The construction that "DoH inherits the HTTPS profi= le so understand that please" seems most apt and in scope.

It would be really great if we had something published in= the HTTP space that deal with this. We don't AFAICT, and that's fe= edback Mark and I have already started noodling over for HTTPbis. (If we ha= d it, the DoH text would be shorter :))

Commen= ts and discussion are of course welcome - its just a pull request.

-Patrick

---

# Privacy Conside= rations {#PrivacyConsiderations}

{{RFC7626}} discusses DNS Privacy Considerations in both "On the
wire" (Section 2.4), and "On the server" (Section 2.5) conte= xts. This
is also a useful framing for DoH's privacy considerations.

## On The Wire {#OnTheWire}

DoH encrypts DNS traffic and requires authentication of the
server. This mitigates both passive surveillance {{RFC7258}} and
active attacks attempting to divert DNS traffic to rogue servers
({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides
similar protections, while direct UDP and TCP based transports are
vulnerable to this class of information leak.

Additionally, the use of the HTTPS default port 443 and the ability to
mix DoH traffic with other HTTPS traffic on the same connection can
deter on-path devices from interfering with DNS operations and make
DNS traffic analysis more difficult.

## On The Server {#OnTheServer}

A DoH application is built on IP, TCP, TLS, and HTTP. Each layer
contains one or more common features that can be used to correlate
different queries to the same identity. DoH inherits the privacy
properties of the HTTPS stack and is not known to introduce new
concerns beyond that of HTTPS.

At the IP level, the client address provides obvious correlation
information. This can be mitigated by use of a NAT, proxy, VPN, or
simple address rotation over time. It may be aggra= vated by use of a
DNS server that can correlate real-time addressing information with<= br> other personal identifiers, such as when a DNS server and DHCP server
are operated by the same entity.

TCP-based solutions may seek performance through the use of TCP Fast=
Open {{RFC7413}}. The cookies used in TCP Fast Ope= n allow servers to
correlate different TCP sessions together.

TLS based implementations often achieve better handshake performance
through the use of some form of session resumption mechanism such as
session tickets {{RFC5077}}. Session resumption creates trivial
mechanisms for a server to correlate different TLS= connections
together.

HTTP's feature set can also be used for identification and track= ing in
a number of different ways. For example, authentic= ation request header
fields explicitly identify profiles in use, and HTTP Cookies are
designed as an explicit state tracking mechanism between the client
and serving site and often are used as an authentication mechanism.

Additionally, the User-Agent and Accept-Language request header fields
often convey specific information about the client version or locale.
This facilitates content negotiation and operational work-arounds fo= r
implementation bugs. Request header fields that co= ntrol caching
can expose state information about a subset of the client's
history. Mixing DoH requests with other HTTP reque= sts on the same
connection also provides an opportunity for richer data correlation.

Implementations of DoH clients and servers need to consider the bene= fit
and privacy impact of all these features, and their deployment context,
when deciding whether or not to en= able them.




--000000000000cc686c056f19ff3b-- From nobody Wed Jun 20 15:14:57 2018 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 F3D7A130E73 for ; Wed, 20 Jun 2018 15:14:54 -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 4bIwpnOIsjLF for ; Wed, 20 Jun 2018 15:14:52 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 B410A130E22 for ; Wed, 20 Jun 2018 15:14:52 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id a5-v6so1270667otf.12 for ; Wed, 20 Jun 2018 15:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YI7IdsLwsmR0/tPptMNoE7gmlixJnObLaVmGiR3uW+U=; b=cU/qGutEcEepyaur4dM8dFB73UXcqDTMUKBcrlcHWMJLx8wFK7dblvjWcNpQoi4kVC yZUh7jN5W2dordfvq7L12nEioA/XrpXH8cDjqkuZyBzt93/MWWqSa0Z74GRuDSHesu/6 MT11fs3eK2w6FoAsLxDS1DBB0xwAuT5bw/yKZB8QH+Ns0/PqHKqpF+t7dIzKLlYzXnMs G0rKz31hJ4SHDExkLzej3hbM/swclDVKRIkzlXoJq+49shGlAR9ryJQsTQxNTMQ/n++F muN6nHoKLRfBufcd/Luni6gY1xCMg9tFnygzoT8ROeP31EhXHpK56xCueP9yZ2SfaJCt 9I9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YI7IdsLwsmR0/tPptMNoE7gmlixJnObLaVmGiR3uW+U=; b=S6uoVqZb68I5yMt4U2aye/wzPjeq6uwXbJXQpxV0tmAiWfCd4QsUnCJol2tiwMdfOd Se87JDZnXjxZ64Rt6NjspqAXmqTCAE9W9bXWhfmAVDFobldvDFOG14MYWYb1e5DHiTam 7RtC/rDm6vXoDXzPKdyt/6U3/9f7pV1xCNgh+BKbbQWLNDK/5FSRFChuN27McvZKrcUq boOe4ljGg6FGaZJN4etbhvD2gg5WUZqAA3Qq76xYgNw19SGZ2Fj3o3e9g5iK8VveVnQE /gM2teSDMkbkxrCDUiI4GPPoiXyeVriiwnbHkcrZEsupSZsrxa+jMePDstG+fnQe7wQj k9/A== X-Gm-Message-State: APt69E0SYhAe+5ZT4drIJyWd/gj1b4ggJgwnFIIAZgKz3PKwGfnChe6W cZnr4aDMj12OzIM7FGrNboY1w9uK37c5Sd3mvF4elw== X-Google-Smtp-Source: ADUXVKLPK7d+zx8hkyLkSuDPV/1kPdhyShW39z4nL+YBswTe/vddyNDfvfT1T0RKWYNGjn1xy+ee5lZBdNr9sjo4kC0= X-Received: by 2002:a9d:5b49:: with SMTP id e9-v6mr15111274otj.193.1529532891646; Wed, 20 Jun 2018 15:14:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 15:14:21 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 20 Jun 2018 15:14:21 -0700 Message-ID: To: Patrick McManus Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000add002056f1a209c" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:14:55 -0000 --000000000000add002056f1a209c Content-Type: text/plain; charset="UTF-8" Repeating the comment I made at Github: Is there a reason not to make a recommendation for the case of a DOH-only service? The current text says: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."? Ted On Wed, Jun 20, 2018 at 3:05 PM, Patrick McManus wrote: > Hi All, > > The authors have a proposed privacy considerations section available as a > PR at: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 > and a snapshot is also included at the end of this email. (though obviously > the PR will be a living document). > > First, thanks for the all the comments and especially to Sara for some of > the significant text that made its way into the draft text. > > The text does not, cannot really, describe the whole universe of > http/tls/tcp/ip fingerprinting - but it does raise it as an issue and try > to give enough illustrative examples to motivate consideration of these > things in your implementation. And in the end, that's its recommendation - > consider these things and don't use them blindly. The construction that > "DoH inherits the HTTPS profile so understand that please" seems most apt > and in scope. > > It would be really great if we had something published in the HTTP space > that deal with this. We don't AFAICT, and that's feedback Mark and I have > already started noodling over for HTTPbis. (If we had it, the DoH text > would be shorter :)) > > Comments and discussion are of course welcome - its just a pull request. > > -Patrick > > --- > > # Privacy Considerations {#PrivacyConsiderations} > > {{RFC7626}} discusses DNS Privacy Considerations in both "On the > wire" (Section 2.4), and "On the server" (Section 2.5) contexts. This > is also a useful framing for DoH's privacy considerations. > > ## On The Wire {#OnTheWire} > > DoH encrypts DNS traffic and requires authentication of the > server. This mitigates both passive surveillance {{RFC7258}} and > active attacks attempting to divert DNS traffic to rogue servers > ({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides > similar protections, while direct UDP and TCP based transports are > vulnerable to this class of information leak. > > Additionally, the use of the HTTPS default port 443 and the ability to > mix DoH traffic with other HTTPS traffic on the same connection can > deter on-path devices from interfering with DNS operations and make > DNS traffic analysis more difficult. > > ## On The Server {#OnTheServer} > > A DoH application is built on IP, TCP, TLS, and HTTP. Each layer > contains one or more common features that can be used to correlate > different queries to the same identity. DoH inherits the privacy > properties of the HTTPS stack and is not known to introduce new > concerns beyond that of HTTPS. > > At the IP level, the client address provides obvious correlation > information. This can be mitigated by use of a NAT, proxy, VPN, or > simple address rotation over time. It may be aggravated by use of a > DNS server that can correlate real-time addressing information with > other personal identifiers, such as when a DNS server and DHCP server > are operated by the same entity. > > TCP-based solutions may seek performance through the use of TCP Fast > Open {{RFC7413}}. The cookies used in TCP Fast Open allow servers to > correlate different TCP sessions together. > > TLS based implementations often achieve better handshake performance > through the use of some form of session resumption mechanism such as > session tickets {{RFC5077}}. Session resumption creates trivial > mechanisms for a server to correlate different TLS connections > together. > > HTTP's feature set can also be used for identification and tracking in > a number of different ways. For example, authentication request header > fields explicitly identify profiles in use, and HTTP Cookies are > designed as an explicit state tracking mechanism between the client > and serving site and often are used as an authentication mechanism. > > Additionally, the User-Agent and Accept-Language request header fields > often convey specific information about the client version or locale. > This facilitates content negotiation and operational work-arounds for > implementation bugs. Request header fields that control caching > can expose state information about a subset of the client's > history. Mixing DoH requests with other HTTP requests on the same > connection also provides an opportunity for richer data correlation. > > Implementations of DoH clients and servers need to consider the benefit > and privacy impact of all these features, and their deployment context, > when deciding whether or not to enable them. > > > > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000add002056f1a209c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Repeating the comment I made at Github:
Is there a reason not to make a recommendation for the case of = a DOH-only service?=C2=A0 The current text says:

Implementations of = DoH clients and servers need to consider the benefit
and privacy impact = of all these features, and their deployment context,
when deciding wheth= er or not to enable them.

Would you consider a recommendation like &= quot;For DOH clients which do not intermingle DOH requests with other HTTP = suppression of these headers and other potentially identifying headers is a= n appropriate data minimization strategy."?

T= ed

On Wed, Jun 20, 2018 at 3:05 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
<= div>Hi All,

The authors have a proposed privacy co= nsiderations section available as a PR at: https://githu= b.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and a snap= shot is also included at the end of this email. (though obviously the PR wi= ll be a living document).

First, thanks for the al= l the comments and especially to Sara for some of the significant text that= made its way into the draft text.

The text does n= ot, cannot really, describe the whole universe of http/tls/tcp/ip fingerpri= nting - but it does raise it as an issue and try to give enough illustrativ= e examples to motivate consideration of these things in your implementation= . And in the end, that's its recommendation - consider these things and= don't use them blindly. The construction that "DoH inherits the H= TTPS profile so understand that please" seems most apt and in scope.

It would be really great if we had something pu= blished in the HTTP space that deal with this. We don't AFAICT, and tha= t's feedback Mark and I have already started noodling over for HTTPbis.= (If we had it, the DoH text would be shorter :))

<= div>Comments and discussion are of course welcome - its just a pull request= .

-Patrick

---
=
# Privacy Considerations {#PrivacyConsiderations}

{{RFC7626}} discusses DNS Privacy Considerations in both "On the
wire" (Section 2.4), and "On the server" (Section 2.5) conte= xts. This
is also a useful framing for DoH's privacy considerations.

## On The Wire {#OnTheWire}

DoH encrypts DNS traffic and requires authentication of the
server. This mitigates both passive surveillance {{RFC7258}} and
active attacks attempting to divert DNS traffic to rogue servers
({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides
similar protections, while direct UDP and TCP based transports are
vulnerable to this class of information leak.

Additionally, the use of the HTTPS default port 443 and the ability to
mix DoH traffic with other HTTPS traffic on the same connection can
deter on-path devices from interfering with DNS operations and make
DNS traffic analysis more difficult.

## On The Server {#OnTheServer}

A DoH application is built on IP, TCP, TLS, and HTTP. Each layer
contains one or more common features that can be used to correlate
different queries to the same identity. DoH inherits the privacy
properties of the HTTPS stack and is not known to introduce new
concerns beyond that of HTTPS.

At the IP level, the client address provides obvious correlation
information. This can be mitigated by use of a NAT, proxy, VPN, or
simple address rotation over = time. It may be aggravated by use of a
DNS server that can correlate real-time addressing information with<= br> other personal identifiers, such as when a DNS server and DHCP server
are operated by the same enti= ty.

TCP-based solutions may seek performance through the use of TCP Fast=
Open {{RFC7413}}. The cookies= used in TCP Fast Open allow servers to
correlate different TCP sessions together.

TLS based implementations often achieve better handshake performance
through the use of some form of session resumption mechanism such as
session tickets {{RFC5077}}. Session resumption creates trivial
mechanisms for a server to co= rrelate different TLS connections
together.

HTTP's feature set can also be used for identification and track= ing in
a number of different ways. F= or example, authentication request header
fields explicitly identify profiles in use, and HTTP Cookies are
designed as an explicit state tracking mechanism between the client
and serving site and often are used as an authentication mechanism.

Additionally, the User-Agent and Accept-Language request header fields
often convey specific information about the client version or locale.
This facilitates content negotiation and operational work-arounds fo= r
implementation bugs. Request = header fields that control caching
can expose state information about a subset of the client's
history. Mixing DoH requests = with other HTTP requests on the same
connection also provides an opportunity for richer data correlation.

Implementations of DoH clients and servers need to consider the bene= fit
and privacy impact of all these features, and their deployment context,
when deciding whether or not to enable them.





_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--000000000000add002056f1a209c-- From nobody Wed Jun 20 15:26:12 2018 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 E4BDE1277BB for ; Wed, 20 Jun 2018 15:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 q6i5Pfcel3t6 for ; Wed, 20 Jun 2018 15:26:09 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EDD127148 for ; Wed, 20 Jun 2018 15:26:09 -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; Wed, 20 Jun 2018 15:26:07 -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; Wed, 20 Jun 2018 15:26:07 -0700 From: Paul Hoffman To: Ted Hardie CC: DoH WG Thread-Topic: [Ext] [Doh] New Privacy Considerations Section Proposal Thread-Index: AQHUCOWuWYRKmbUUfUmQgJXMMaykuQ== Date: Wed, 20 Jun 2018 22:26:07 +0000 Message-ID: References: In-Reply-To: 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: <90BB3ABB1DE6AE4BB6245C1AE18A0D66@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:26:11 -0000 On Jun 20, 2018, at 3:14 PM, Ted Hardie wrote: >=20 > Repeating the comment I made at Github: >=20 > Is there a reason not to make a recommendation for the case of a DOH-only= service? The current text says: >=20 > Implementations of DoH clients and servers need to consider the benefit > and privacy impact of all these features, and their deployment context, > when deciding whether or not to enable them. >=20 > Would you consider a recommendation like "For DOH clients which do not in= termingle DOH requests with other HTTP suppression of these headers and oth= er potentially identifying headers is an appropriate data minimization stra= tegy."? That could be added, but it would need a *lot* more text because your propo= sed text only deals with one layer (HTTP) while the text above it also talk= s about fingerprinting with TLS, TCP, and IP (in reverse order). The WG can= decide whether adding recommendations for just one layer is worthwhile or = possibly misleading about the overall privacy. --Paul Hoffman= From nobody Wed Jun 20 15:30:19 2018 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 CBE23130E41 for ; Wed, 20 Jun 2018 15:30:17 -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 AfDoMMl-sQda for ; Wed, 20 Jun 2018 15:30:16 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 EABE5130E37 for ; Wed, 20 Jun 2018 15:30:15 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id 101-v6so1338694oth.4 for ; Wed, 20 Jun 2018 15:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7J5pv9suUoM6/FWgTIpUE0gVQnqDOHQNQmbQJVn7qJ4=; b=QIn5TZ4rLEhSdmTAWezcINLDIRtkFUA5qgI6v7kBpeU75BhDGD/5oI94F2tw6JI8WX gPZw6aIpO/FzBKmbb+CvniLe6+UQQokjjNSzB0SRlwDk2usStQWbxAWwHVEvEhdad0Bw iaYdJkUh0xDuWShVrMUTT2jcncS9AzaBZg9JimhJFgyI1haUBXSbZdQuVMViJUUtb0gn 6+X5MUMa4LYOgabNr5qfjDhcGolrjhayivzXK5iFO1YzyHgEurRiMruem2YSq/RvjdT+ OuJ7C5kai7jSXSSl398QfLy5E7CSat48YvLYDGbG6RNqp1fSxO0ikJwm7iU8h5FL5V+m WLdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7J5pv9suUoM6/FWgTIpUE0gVQnqDOHQNQmbQJVn7qJ4=; b=sJk80SddriM58ckL25VP5Fnrhr4lNjBeBOpW6aaBmeszTXryGVlkpKrJGic3BGnWcv FpP3FkDgweeO7aPPmV1HMp1W2DTj5snpj3v4ObECdsKINY0mXtSCEEmy+ijDqt4aO6ms nBXaUf/bQzEpaYKsd1y8sFtJjE/7V6Rk9Wp0sIAvNjRllY02Ti2u4h3yx7iv8pr35qrJ WuUCYqSN3gaxODDB3dWXAxaB6eUDprLEWqsoXBG5e902SemWdqn+3EMQk0BhevbiJIMA ijxyxlRP4aiFXQAg4r++lpajXPEqo0Rw9VptEHRlKXQ9xsOsT5i5iHQOD/CgtRs2tYk0 Cubg== X-Gm-Message-State: APt69E1DtRne+hghI0ENmldLtqbTj5Eo7ewNdhpCuoku9u7Cdbmn+Nc2 BX6EyhIk098cpqCoSzwbgpl6Hfonqxh0410xuwA= X-Google-Smtp-Source: ADUXVKKGzwqXuwiTjyxctLzxisjhrBKfxPKdw67CTrFTiyzq5CBDzSPWUYngo9OnPZVGVDbcGbs8zlISvFatrveoJC8= X-Received: by 2002:a9d:3866:: with SMTP id r35-v6mr15360945otd.329.1529533815080; Wed, 20 Jun 2018 15:30:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 15:29:44 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 20 Jun 2018 15:29:44 -0700 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000b84dad056f1a5714" Archived-At: Subject: Re: [Doh] [Ext] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:30:18 -0000 --000000000000b84dad056f1a5714 Content-Type: text/plain; charset="UTF-8" Hmm, we should probably pick one place to have this conversation. In the mean time, here's my reply to Paul: It was only an example, and I would be happy to expand. That said, I think this is the most likely source of leakage: folks using a general purpose HTTP subsystem that carries information not needed for DOH requests. Actually recommending data minimization there, rather than saying "it should be considered" seems like a worthwhile thing to do in my personal opinion. Ted On Wed, Jun 20, 2018 at 3:26 PM, Paul Hoffman wrote: > On Jun 20, 2018, at 3:14 PM, Ted Hardie wrote: > > > > Repeating the comment I made at Github: > > > > Is there a reason not to make a recommendation for the case of a > DOH-only service? The current text says: > > > > Implementations of DoH clients and servers need to consider the benefit > > and privacy impact of all these features, and their deployment context, > > when deciding whether or not to enable them. > > > > Would you consider a recommendation like "For DOH clients which do not > intermingle DOH requests with other HTTP suppression of these headers and > other potentially identifying headers is an appropriate data minimization > strategy."? > > That could be added, but it would need a *lot* more text because your > proposed text only deals with one layer (HTTP) while the text above it also > talks about fingerprinting with TLS, TCP, and IP (in reverse order). The WG > can decide whether adding recommendations for just one layer is worthwhile > or possibly misleading about the overall privacy. > > --Paul Hoffman --000000000000b84dad056f1a5714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm, we should probably pick one place to have this c= onversation.=C2=A0 In the mean time, here's my reply to Paul:

It was only an example, and I would be happy to expand. Th= at said, I=20 think this is the most likely source of leakage: folks using a general=20 purpose HTTP subsystem that carries information not needed for DOH=20 requests. Actually recommending data minimization there, rather than=20 saying "it should be considered" seems like a worthwhile thing to= do in=20 my personal opinion.

Ted

On Wed, Jun 20, 2018 at 3:2= 6 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Jun 20, 2018, at 3:14 PM,= Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Repeating the comment I made at Github:
>
> Is there a reason not to make a recommendation for the case of a DOH-o= nly service?=C2=A0 The current text says:
>
> Implementations of DoH clients and servers need to consider the benefi= t
> and privacy impact of all these features, and their deployment context= ,
> when deciding whether or not to enable them.
>
> Would you consider a recommendation like "For DOH clients which d= o not intermingle DOH requests with other HTTP suppression of these headers= and other potentially identifying headers is an appropriate data minimizat= ion strategy."?

That could be added, but it would need a *lot* more text because you= r proposed text only deals with one layer (HTTP) while the text above it al= so talks about fingerprinting with TLS, TCP, and IP (in reverse order). The= WG can decide whether adding recommendations for just one layer is worthwh= ile or possibly misleading about the overall privacy.

--Paul Hoffman

--000000000000b84dad056f1a5714-- From nobody Wed Jun 20 16:03:32 2018 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 4DE37130EDE for ; Wed, 20 Jun 2018 16:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 zjbdnhz9Ops1 for ; Wed, 20 Jun 2018 16:03:18 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 4E851130F07 for ; Wed, 20 Jun 2018 16:03:18 -0700 (PDT) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by linode64.ducksong.com (Postfix) with ESMTPSA id E34B83A042 for ; Wed, 20 Jun 2018 19:03:16 -0400 (EDT) Received: by mail-ot0-f178.google.com with SMTP id l15-v6so1400870oth.6 for ; Wed, 20 Jun 2018 16:03:16 -0700 (PDT) X-Gm-Message-State: APt69E3NjOzwc5OtLhS+SfX9spxNnm28pFxU8mxq5N0tGRDpfwCpy7Iz gZf4qdx4gR8ErI7J06Nrwz2GoGw6Wqhsj93hch0= X-Google-Smtp-Source: ADUXVKIdx36L8qIhzrGSMuXuQUjaiKIPmKk/Rgu7KwBqVBnU6utNfT0ELaxsZjRZ/MANQBWGYP2gUFl339iRKJ0baGA= X-Received: by 2002:a9d:1bd6:: with SMTP id v22-v6mr14943886otv.85.1529535796586; Wed, 20 Jun 2018 16:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 16:03:15 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Wed, 20 Jun 2018 19:03:15 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: Patrick McManus , DoH WG Content-Type: multipart/alternative; boundary="000000000000d3af34056f1acd00" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 23:03:30 -0000 --000000000000d3af34056f1acd00 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie wrote: > Repeating the comment I made at Github: > > Is there a reason not to make a recommendation for the case of a DOH-only > service? The current text says: > > Implementations of DoH clients and servers need to consider the benefit > and privacy impact of all these features, and their deployment context, > when deciding whether or not to enable them. > > Would you consider a recommendation like "For DOH clients which do not > intermingle DOH requests with other HTTP suppression of these headers and > other potentially identifying headers is an appropriate data minimization > strategy."? > > there are some practical problems there. Big picture you need to weigh the reasons these things get used in your implementation decisions. Its not like TLS didn't know they had built a tracker with session tickets, yet dprive recommended its use anyhow :) every http feature has a reason an implementation might want want it in doh. cookies can do useful things for auth. new compression algorithms (which create a fingerprint on introduction just as surely as UA does) enable better performance. etc.. UA strings have kept the web runinng, for good and bad, across many unanticipated bugs for many years.. I'm not saying those arguments win the day but its not really DoH's place to change the properties of HTTP. Alt-Service provides great load balancing and protocol evolution, but its basically a cache with a tracking implication too. It is an important goal of this work to leverage the HTTP ecosystem - stripping out all the HTTP parts and leaving a tunnel doesn't give it any value. The picture is also complicated by the end to end message semantics of http headers and how they interact with the hop to hop transport semantics of the client or server. i.e. the notion of intermingle is not e2e, but headers are. That's not really a driver, but something to keep in mind when considering the limitations of text. I'm more inclined in general to use words along the lines of "should use the minimal set of data that can achieve the desired feature set." if that's helpful, but I'm not eager to start working through individual design decisions. --000000000000d3af34056f1acd00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie <ted.ietf@gmail.com&g= t; wrote:
Re= peating the comment I made at Github:

Is there a reason not to make a recommendation for the case of a DOH-= only service?=C2=A0 The current text says:

Implementations of DoH cl= ients and servers need to consider the benefit
and privacy impact of all= these features, and their deployment context,
when deciding whether or = not to enable them.

Would you consider a recommendation like = "For DOH clients which do not intermingle DOH requests with other HTTP= suppression of these headers and other potentially identifying headers is = an appropriate data minimization strategy."?


there are some practical problems there. Big picture you need to weigh = the reasons these things get used in your implementation decisions. Its not= like TLS didn't know they had built a tracker with session tickets, ye= t dprive recommended its use anyhow :)

=
every http feature has a reason an impleme= ntation might want want it in doh. cookies can do useful things for auth. n= ew compression algorithms (which create a fingerprint on introduction just = as surely as UA does) enable better performance. etc.. UA strings have kept= the web runinng, for good and bad, across many unanticipated bugs for many= years.. I'm not saying those arguments win the day but its not really = DoH's place to change the properties of HTTP. Alt-Service provides grea= t load balancing and protocol evolution, but its basically a cache with a t= racking implication too.

It is an important goal of this work to leverage the= HTTP ecosystem - stripping out all the HTTP parts and leaving a tunnel doe= sn't give it any value.

<= div class=3D"gmail_extra">The picture is also complicated by the end to end= message semantics of http headers and how they interact with the hop to ho= p transport semantics of the client or server. i.e. the notion of interming= le is not e2e, but headers are. That's not really a driver, but somethi= ng to keep in mind when considering the limitations of text.

I'm more incline= d in general to use words along the lines of "should use the minimal s= et of data that can achieve the desired feature set." if that's he= lpful, but I'm not eager to start working through individual design dec= isions.


--000000000000d3af34056f1acd00-- From nobody Wed Jun 20 16:54:43 2018 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 433C8130E46 for ; Wed, 20 Jun 2018 16:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 OhNheY9Xl5t7 for ; Wed, 20 Jun 2018 16:54:39 -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 CBE12130E3D for ; Wed, 20 Jun 2018 16:54:39 -0700 (PDT) Received: from Svantevit.local (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 w5KNsaVQ053084 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Jun 2018 18:54:38 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Patrick McManus , Ted Hardie Cc: DoH WG References: From: Adam Roach Message-ID: Date: Wed, 20 Jun 2018 18:54:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D48EE96DDB5989D52CBEA0FF" Content-Language: en-US Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 23:54:43 -0000 This is a multi-part message in MIME format. --------------D48EE96DDB5989D52CBEA0FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as an individual] I agree with Patrick's analysis here, and think the proposed text (plus the "minimal set of data" statement below) is likely to serve the purpose well. In particular, I agree with Patrick that the various features that have been cited so far each serve a useful purpose, and that such purposes may have a place in DoH deployments. Giving implementors a heads up about the privacy trade-offs seems appropriate. Mandating (MUST or SHOULD) that DoH runs over a minimal profile of HTTP seems to remove several of the advantages of using HTTP at all. /a On 6/20/18 6:03 PM, Patrick McManus wrote: > > > On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie > wrote: > > Repeating the comment I made at Github: > > Is there a reason not to make a recommendation for the case of a > DOH-only service? The current text says: > > Implementations of DoH clients and servers need to consider the > benefit > and privacy impact of all these features, and their deployment > context, > when deciding whether or not to enable them. > > Would you consider a recommendation like "For DOH clients which do > not intermingle DOH requests with other HTTP suppression of these > headers and other potentially identifying headers is an > appropriate data minimization strategy."? > > > there are some practical problems there. Big picture you need to weigh > the reasons these things get used in your implementation decisions. > Its not like TLS didn't know they had built a tracker with session > tickets, yet dprive recommended its use anyhow :) > > every http feature has a reason an implementation might want want it > in doh. cookies can do useful things for auth. new compression > algorithms (which create a fingerprint on introduction just as surely > as UA does) enable better performance. etc.. UA strings have kept the > web runinng, for good and bad, across many unanticipated bugs for many > years.. I'm not saying those arguments win the day but its not really > DoH's place to change the properties of HTTP. Alt-Service provides > great load balancing and protocol evolution, but its basically a cache > with a tracking implication too. > > It is an important goal of this work to leverage the HTTP ecosystem - > stripping out all the HTTP parts and leaving a tunnel doesn't give it > any value. > > The picture is also complicated by the end to end message semantics of > http headers and how they interact with the hop to hop transport > semantics of the client or server. i.e. the notion of intermingle is > not e2e, but headers are. That's not really a driver, but something to > keep in mind when considering the limitations of text. > > I'm more inclined in general to use words along the lines of "should > use the minimal set of data that can achieve the desired feature set." > if that's helpful, but I'm not eager to start working through > individual design decisions. > > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh --------------D48EE96DDB5989D52CBEA0FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as an individual]

I agree with Patrick's analysis here, and think the proposed text (plus the "minimal set of data" statement below) is likely to serve the purpose well. In particular, I agree with Patrick that the various features that have been cited so far each serve a useful purpose, and that such purposes may have a place in DoH deployments. Giving implementors a heads up about the privacy trade-offs seems appropriate. Mandating (MUST or SHOULD) that DoH runs over a minimal profile of HTTP seems to remove several of the advantages of using HTTP at all.

/a

On 6/20/18 6:03 PM, Patrick McManus wrote:


On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Repeating the comment I made at Github:

Is there a reason not to make a recommendation for the case of a DOH-only service?  The current text says:

Implementations of DoH clients and servers need to consider the benefit
and privacy impact of all these features, and their deployment context,
when deciding whether or not to enable them.

Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?


there are some practical problems there. Big picture you need to weigh the reasons these things get used in your implementation decisions. Its not like TLS didn't know they had built a tracker with session tickets, yet dprive recommended its use anyhow :)

every http feature has a reason an implementation might want want it in doh. cookies can do useful things for auth. new compression algorithms (which create a fingerprint on introduction just as surely as UA does) enable better performance. etc.. UA strings have kept the web runinng, for good and bad, across many unanticipated bugs for many years.. I'm not saying those arguments win the day but its not really DoH's place to change the properties of HTTP. Alt-Service provides great load balancing and protocol evolution, but its basically a cache with a tracking implication too.

It is an important goal of this work to leverage the HTTP ecosystem - stripping out all the HTTP parts and leaving a tunnel doesn't give it any value.

The picture is also complicated by the end to end message semantics of http headers and how they interact with the hop to hop transport semantics of the client or server. i.e. the notion of intermingle is not e2e, but headers are. That's not really a driver, but something to keep in mind when considering the limitations of text.

I'm more inclined in general to use words along the lines of "should use the minimal set of data that can achieve the desired feature set." if that's helpful, but I'm not eager to start working through individual design decisions.




_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--------------D48EE96DDB5989D52CBEA0FF-- From nobody Wed Jun 20 17:03:03 2018 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 C940E130F35 for ; Wed, 20 Jun 2018 17:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] 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 UIsSazpCleLK for ; Wed, 20 Jun 2018 17:02:49 -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 C8942130F25 for ; Wed, 20 Jun 2018 17:02:46 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5L02TJD032262 for ; Thu, 21 Jun 2018 01:02:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=YOm8rkNvO8adEKS9TKKjixaGkG2Rs6UOBbpF4ZZdpgw=; b=b+ER2S4i5TE23t8ZEpZlkTa8x/EShLfjP1wkkgbptvGEHPRDf5exvXa2xr2LehhgxQ5n s75qxPjENU+V56f0CJkc3bvBJkAdwmA3CjrtRSv4gDNkswiozWbLCImSXdkZuLnV8oRU JOWh3LPulovvpEKl84daUpiT6ipIsTQR4/bw/zBCE6xjjy0T7Mc9CRA6Ve+OPUthtV2k +usr48xFOHg6RB2xrwWUA5CxKG4Km3Mr0g/jCkcKatV9Y8q5Gr+tzK7tWs5RrV4U1L9B RveFtNKBgtS0emdvnfgRY8Kc96Ce8XwHwAOoZiD6dpDtCfHSSE0wm7TnGtzeMdgjXx5Z zg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2jqdg8auds-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Jun 2018 01:02:45 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5L01FEs003459 for ; Wed, 20 Jun 2018 20:02:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jmwwcbbj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 20 Jun 2018 20:02:44 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 20 Jun 2018 20:02:43 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Wed, 20 Jun 2018 20:02:42 -0400 From: "Hewitt, Rory" To: DoH WG Thread-Topic: [Doh] New Privacy Considerations Section Proposal Thread-Index: AQHUCOLizcet6foASEaLXJ/0XvgPYqRp+VuAgAANqoCAAA5TgP//vcdg Date: Thu, 21 Jun 2018 00:02:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.211] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0087_01D408B8.7FD3D220" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-20_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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806200258 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-20_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806200258 Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 00:03:02 -0000 ------=_NextPart_000_0087_01D408B8.7FD3D220 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0088_01D408B8.7FD3D220" ------=_NextPart_001_0088_01D408B8.7FD3D220 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I like Patrick's proposed wording along the lines of "...should use the minimal set of data that can achieve the desired feature set.", but I also like Ted's more explicit suggestion. Perhaps this combination?: "DoH clients should use the minimal set of data (e.g. headers, cookies) that can achieve the desired feature set whilst minimizing potentially identifying information being passed." Just my $0.02... Thanks, Rory From: Adam Roach [mailto:adam@nostrum.com] Sent: Wednesday, June 20, 2018 4:55 PM To: Patrick McManus ; Ted Hardie Cc: DoH WG Subject: Re: [Doh] New Privacy Considerations Section Proposal [as an individual] I agree with Patrick's analysis here, and think the proposed text (plus the "minimal set of data" statement below) is likely to serve the purpose well. In particular, I agree with Patrick that the various features that have been cited so far each serve a useful purpose, and that such purposes may have a place in DoH deployments. Giving implementors a heads up about the privacy trade-offs seems appropriate. Mandating (MUST or SHOULD) that DoH runs over a minimal profile of HTTP seems to remove several of the advantages of using HTTP at all. /a On 6/20/18 6:03 PM, Patrick McManus wrote: On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie > wrote: Repeating the comment I made at Github: Is there a reason not to make a recommendation for the case of a DOH-only service? The current text says: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."? there are some practical problems there. Big picture you need to weigh the reasons these things get used in your implementation decisions. Its not like TLS didn't know they had built a tracker with session tickets, yet dprive recommended its use anyhow :) every http feature has a reason an implementation might want want it in doh. cookies can do useful things for auth. new compression algorithms (which create a fingerprint on introduction just as surely as UA does) enable better performance. etc.. UA strings have kept the web runinng, for good and bad, across many unanticipated bugs for many years.. I'm not saying those arguments win the day but its not really DoH's place to change the properties of HTTP. Alt-Service provides great load balancing and protocol evolution, but its basically a cache with a tracking implication too. It is an important goal of this work to leverage the HTTP ecosystem - stripping out all the HTTP parts and leaving a tunnel doesn't give it any value. The picture is also complicated by the end to end message semantics of http headers and how they interact with the hop to hop transport semantics of the client or server. i.e. the notion of intermingle is not e2e, but headers are. That's not really a driver, but something to keep in mind when considering the limitations of text. I'm more inclined in general to use words along the lines of "should use the minimal set of data that can achieve the desired feature set." if that's helpful, but I'm not eager to start working through individual design decisions. _______________________________________________ Doh mailing list Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh ------=_NextPart_001_0088_01D408B8.7FD3D220 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

= I like Patrick's proposed wording along the lines of = "...should use the minimal set of data that can achieve the = desired feature set.= ", but I also like Ted's more explicit = suggestion.

=  

= Perhaps this combination?:

=  

= "DoH clients = should use the minimal set of data (e.g. headers, cookies) that can = achieve the desired feature set whilst minimizing potentially = identifying information being passed.= "

=  

= Just my $0.02...

=  

= Thanks,

=  

= Rory=

=  

From: Adam Roach [mailto:adam@nostrum.com] =
Sent: Wednesday, June 20, 2018 4:55 PM
To: Patrick = McManus <pmcmanus@mozilla.com>; Ted Hardie = <ted.ietf@gmail.com>
Cc: DoH WG = <doh@ietf.org>
Subject: Re: [Doh] New Privacy = Considerations Section Proposal

 

[as an = individual]

I agree with Patrick's analysis here, and think the = proposed text (plus the "minimal set of data" statement below) = is likely to serve the purpose well. In particular, I agree with Patrick = that the various features that have been cited so far each serve a = useful purpose, and that such purposes may have a place in DoH = deployments. Giving implementors a heads up about the privacy trade-offs = seems appropriate. Mandating (MUST or SHOULD) that DoH runs over a = minimal profile of HTTP seems to remove several of the advantages of = using HTTP at all.

/a

On 6/20/18 6:03 PM, Patrick McManus = wrote:

 

 

On Wed, = Jun 20, 2018 at 6:14 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Repeating the comment I made at = Github:

 

Is there a reason not to make a recommendation for the = case of a DOH-only service?  The current text = says:

Implementations of DoH clients and servers need to consider = the benefit
and privacy impact of all these features, and their = deployment context,
when deciding whether or not to enable = them.

Would you consider a recommendation like "For DOH = clients which do not intermingle DOH requests with other HTTP = suppression of these headers and other potentially identifying headers = is an appropriate data minimization = strategy."?

 

 

there are some practical problems there. Big picture = you need to weigh the reasons these things get used in your = implementation decisions. Its not like TLS didn't know they had built a = tracker with session tickets, yet dprive recommended its use anyhow = :)

 

every http feature has a reason an implementation = might want want it in doh. cookies can do useful things for auth. new = compression algorithms (which create a fingerprint on introduction just = as surely as UA does) enable better performance. etc.. UA strings have = kept the web runinng, for good and bad, across many unanticipated bugs = for many years.. I'm not saying those arguments win the day but its not = really DoH's place to change the properties of HTTP. Alt-Service = provides great load balancing and protocol evolution, but its basically = a cache with a tracking implication too.

 

It is an important goal of this work to leverage the = HTTP ecosystem - stripping out all the HTTP parts and leaving a tunnel = doesn't give it any value.

 

The picture is also complicated by the end to end = message semantics of http headers and how they interact with the hop to = hop transport semantics of the client or server. i.e. the notion of = intermingle is not e2e, but headers are. That's not really a driver, but = something to keep in mind when considering the limitations of = text.

 

I'm more inclined in general to use words along the = lines of "should use the minimal set of data that can achieve the = desired feature set." if that's helpful, but I'm not eager to start = working through individual design decisions.

 

 




_______________________=
________________________
Doh mailing =
list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh=

 

------=_NextPart_001_0088_01D408B8.7FD3D220-- ------=_NextPart_000_0087_01D408B8.7FD3D220 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDYyMTAwMDI0MVowIwYJKoZIhvcNAQkEMRYEFFqt/9tlbhJh+feRYNF9341s/2U5MHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAORXxYa2IJuP3faPEBhdaVSWa8ZbbvlCQkU9b9FspUXfn9e6YZhRgzFXhptF Tq9jFrB+x64ReKhoWuLwcEr/SGNdbJqZntdRTFabxdJMNvmrfnegYJgeC9BC4Yjy6Ja8oyN2TqRt O4DqFSNPjKkSBegueALCwpRchr2Fq33ROeuEkICGtW0zrsqHAIGbTKygS2GVyQ4wBEJm4gZF0tDw c16Pd/vBL3eR+hC210q1YLmtsrooruVyB+BcnI6UpzSznnHaS/YoY3kVyIwoYhMPwfc4eesNTBbL tgq2xvcH1M46Ff/MpOPofIyxcbGGvoN+rSDBG2QEPKF2LRGGy2W6IY0AAAAAAAA= ------=_NextPart_000_0087_01D408B8.7FD3D220-- From nobody Wed Jun 20 17:06:47 2018 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 9F532130E3D for ; Wed, 20 Jun 2018 17:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 acZBfgz8NfMI for ; Wed, 20 Jun 2018 17:06:44 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A7F130ECA for ; Wed, 20 Jun 2018 17:06:44 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 616431A05B6 for ; Wed, 20 Jun 2018 17:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529539604; bh=m3c2gV5NUwkZyfRvX7aoJh2SGwi/zNZDSFepqmTOuhk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=froig3GylYF2SDx04rbGUcWY8K6YhFymW+XZdLpIOC/smJBlnqWMVHwx9b9eBC0qe XnUSHTlJkk07u2aU37+tE6iCx5oaSOZsC2GdqVaiLPi/PW+4uXZmst+qIOMxKT415H PsO4GbFjeEC8uoYlFBYOng2Eef5ny9TDG9weCnrM= X-Riseup-User-ID: 6388DAA6A1A12DB24E4D4F945AC5AFF60F073B0E94A352060CDF6F3C94228BB1 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 4EC1DC3B17 for ; Wed, 20 Jun 2018 17:06:42 -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: Date: Thu, 21 Jun 2018 00:06:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BXWuqDAqwYKzYrXJT6ovC2pW3ZUo1NmVW" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 00:06:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BXWuqDAqwYKzYrXJT6ovC2pW3ZUo1NmVW Content-Type: multipart/mixed; boundary="JJu5Iqjnr3zcPZlDCCBl3xd0YsLFmwjZZ"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: Subject: Re: [Doh] New Privacy Considerations Section Proposal References: In-Reply-To: --JJu5Iqjnr3zcPZlDCCBl3xd0YsLFmwjZZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I like the proposal but I agree with Ted, that it should be expanded and data minimization should be explicitly recommended instead of conside= red. I also found the comparison of DoH with DoT (RFC7858) from a privacy perspective in Sara's text [1] useful to help understand the privacy delta of these protocols. "DNS-over-TLS {{RFC7858}}, for example, would normally contain no client = identifiers in the DNS messages and a recursive resolver would see only a= =20 stream of DNS queries originating from a client IP address. Whereas if Do= H=20 clients commonly include several headers in a DNS message (e.g. user-agen= t=20 and accept-language) this could lead to the DoH server being able to iden= tify=20 the source of individual DNS requests not only to a specific end user dev= ice=20 but to a specific application." > DoH inherits the privacy properties of the HTTPS stack and=20 > is not known to introduce new concerns beyond that of HTTPS. It does not introduce new concerns when compared with HTTPS=20 but it does introduce new privacy converns when compared with=20 DNS over UDP, TCP or TLS (RFC7858), namely the significantly increased fingerprintability of the DoH DNS clie= nt when compared to other types of DNS clients=20 and the direct linking of DNS with HTTP traffic when a DoH server is not exclusively used for DoH. > At the IP level, the client address provides obvious correlation > information. This can be mitigated by ... >=20 > TCP-based solutions ... >=20 > TLS based implementations ... >=20 > HTTP's feature set can also be used for identification and tracking The IP layer paragraph includes mitigations, the paragraphs about=20 the other layers are missing mitigations. > Implementations of DoH clients and servers need to consider the benefit= > and privacy impact of all these features, and their deployment context,= > when deciding whether or not to enable them. I think it would be better to at least recommend privacy-by-default setti= ngs and values=20 instead of leaving it completely up to the implementors - even if we can = not enumerate all possible privacy issues and mitigations. [1] https://mailarchive.ietf.org/arch/msg/doh/BFYfWTrnxU0iHeGVqvbIMlGJ6lA= =20 --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --JJu5Iqjnr3zcPZlDCCBl3xd0YsLFmwjZZ-- --BXWuqDAqwYKzYrXJT6ovC2pW3ZUo1NmVW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsq7AoACgkQrWE4wkXN Qn7YcRAArItrF5MZNcVVaqBPhGBQgQ32CSIV7YgegN5RPSGlH/MXjROJuIzsJylS CMcQBOLY8AW6FWiooI06Rb3aVWPwDIfmDJzeYUJcNpYIgbw6PXQ1IEx0v9KK6zsJ jUt3L/Lv2W3Fo9jD62LEgNPn+Z+iZIhR1YB9mNTqBwEk7N4lCHoAzRFNW1XbaC+A PEKhc4FRuMnzW7tRTauAzX+A5zL2pgNxmU6d/heiuDUMSoHeDAvWxNv8nxHiW4j6 maoNwIYLmlSTgKIZN9uJGfJIOUepX3XxXcfFnsbQW9eLeGoVnsO0xCZ5HaMYOhzJ uiy8mp2smhfGJ2lfsCzIJY9wkfk/56njXzLlFD+iVUDK9XGRQrcAS38rjlb+zOW4 5xz7KS3k9RS7Mlm2cbdvk+1I7SxG+XbRs35qBtg0HrYSAYbrpwDAU/VEmLWDMEKd uUlmosVKfWNzgrDiyoj6+8Kmo0aoDF36Kq6FBfAMSyS61lQYwrT7iyETQWJsiXiL AeZWZhkry6Xjc8TWSostL8SLawyr3b/AJPY0XTTzGd7YQsvGK0QPfjwSCtoOfHkj FFjcT98kBUf+2am/wf/ryua5PDguLty7HHXZT0pLBNNlJckLx5pCKJelQm08xbv0 nFcYHyrR7R3OkwVF2BUQGrO6D8od4c5HSXhWWgS0LOPN2n42RbU= =qKKN -----END PGP SIGNATURE----- --BXWuqDAqwYKzYrXJT6ovC2pW3ZUo1NmVW-- From nobody Wed Jun 20 17:58:15 2018 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 7FE51130F49 for ; Wed, 20 Jun 2018 17:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 tqYJOY7c3nR8 for ; Wed, 20 Jun 2018 17:58:12 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE15130ED3 for ; Wed, 20 Jun 2018 17:58:12 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 94F2D3A03B for ; Wed, 20 Jun 2018 20:58:10 -0400 (EDT) Received: by mail-oi0-f41.google.com with SMTP id 14-v6so1365131oie.3 for ; Wed, 20 Jun 2018 17:58:10 -0700 (PDT) X-Gm-Message-State: APt69E3nDcR80pEzPQY1fkHVD4rOUDWYodiDcz6sGt4hrFcPwz8ZhelV kRVbpMrOHv9ZfLeMxicRrq5MTPqlp5lgGIXeS4M= X-Google-Smtp-Source: ADUXVKLzUHZvr2otUEUJd2qTrE1wloFuicgZECueyDKGV1myWL0fe4Zqg3YrSHHzhaWmL68CpTWe4ZRM8Qs2v3aF9PE= X-Received: by 2002:aca:acb:: with SMTP id k72-v6mr12274769oiy.132.1529542690340; Wed, 20 Jun 2018 17:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 17:58:09 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Wed, 20 Jun 2018 20:58:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: nusenu Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000ba136c056f1c68ba" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 00:58:14 -0000 --000000000000ba136c056f1c68ba Content-Type: text/plain; charset="UTF-8" Hi Nusenu, On Wed, Jun 20, 2018 at 8:06 PM, nusenu wrote: > > It does not introduce new concerns when compared with HTTPS > but it does introduce new privacy converns when compared with > DNS over UDP, TCP or TLS (RFC7858), > I started to go down this path, but it pretty quickly became clear that comprehensive treatment of this kind of comparison is a different document - though I think describing things in layers does a decent job of pointing out where these various properties come into play. DoH needs to describe the properties of DoH.. the proposed text certainly doesn't try and hide from the fingerprintability of the http system doh is using. The IP layer paragraph includes mitigations, the paragraphs about > the other layers are missing mitigations. > > those mitigations are there to provide context/scope to the addressing problem - not advice on how to mitigate it :) For most of the other features the mitigation is "don't use it" which of course has a cost. --000000000000ba136c056f1c68ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nusenu,

On Wed, Jun 20, 2018 at 8:06 PM, nusenu <nusenu-l= ists@riseup.net> wrote:

It does not introduce new concerns when compared with HTTPS
but it does introduce new privacy converns when compared with
DNS over UDP, TCP or TLS (RFC7858),

I s= tarted to go down this path, but it pretty quickly became clear that compre= hensive treatment of this kind of comparison is a different document - thou= gh I think describing things in layers does a decent job of pointing out wh= ere these various properties come into play. DoH needs to describe the prop= erties of DoH.. the proposed text certainly doesn't try and hide from t= he fingerprintability of the http system doh is using.


The IP layer paragraph includes mitigations, the paragraphs about the other layers are missing mitigations.


those mitigati= ons are there to provide context/scope to the addressing problem - not advi= ce on how to mitigate it :) For most of the other features the mitigation i= s "don't use it" which of course has a cost.

--000000000000ba136c056f1c68ba-- From nobody Thu Jun 21 04:08:57 2018 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 A24C2130F00 for ; Thu, 21 Jun 2018 04:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 or5fTaayvEo4 for ; Thu, 21 Jun 2018 04:08:53 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF5D12F295 for ; Thu, 21 Jun 2018 04:08:53 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 466EF1A037D for ; Thu, 21 Jun 2018 04:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529579333; bh=nlbZcBtFkMJT/2JANOaFUEoA/MsmTgUHS0d+3JfZJIY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qVG0sLeV4dutOiS184DwCCDFWijs2D+SUbAGwwKK0IgYR9ETZ9VT2SmyFgGs2EPHd vQRLv9g+EodUVHj3VXNnQSRAuAKx3kal2DQogYlsHi0cmmHWw6IerE1KEC5EhSRqhg cFrOGafRORO5CaS2XnOXf3RtfACYSN8L55zkhGUQ= X-Riseup-User-ID: 2581D54CDF1CB1A0FAA2BB03136613D8F85853E0CD2ED663C9C65FAC8F789AAF Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 3C487C7B3E for ; Thu, 21 Jun 2018 04:08:51 -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: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> Date: Thu, 21 Jun 2018 11:08:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wG9IkxBoXwfpaVGQRIEq6VlwNA2vuZdB6" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:08:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wG9IkxBoXwfpaVGQRIEq6VlwNA2vuZdB6 Content-Type: multipart/mixed; boundary="LmBmNizj8ouCNEUyl58NFhAv2XT1Luawf"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> Subject: Re: [Doh] New Privacy Considerations Section Proposal References: In-Reply-To: --LmBmNizj8ouCNEUyl58NFhAv2XT1Luawf Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable >> It does not introduce new concerns when compared with HTTPS >> but it does introduce new privacy converns when compared with >> DNS over UDP, TCP or TLS (RFC7858), >> >=20 > I started to go down this path, but it pretty quickly became clear that= > comprehensive treatment of this kind of comparison is a different docum= ent > - though I think describing things in layers does a decent job of point= ing > out where these various properties come into play. DoH needs to describ= e > the properties of DoH.. the proposed text certainly doesn't try and hid= e > from the fingerprintability of the http system doh is using. So because a comprehensive treatment is hard and obviously not the primar= y goal of the document a comparative statement of the privacy implications of DoH wrt o= ther DNS protocols=20 from Sara's text is no longer mentioned at all? > The IP layer paragraph includes mitigations, the paragraphs about >> the other layers are missing mitigations. >> >> > those mitigations are there to provide context/scope to the addressing > problem - not advice on how to mitigate it :) For most of the other > features the mitigation is "don't use it" which of course has a cost. I don't think privacy is a binary all or nothing decision. I'd like to understand the reasoning for NOT including specific privacy f= riendly=20 recommendations in the document, because currently the document mentions the high level issues but doesn't give specific advise on what to do abou= t it - the implementors are basically on their own - and there have already been given specific statements from multiple perso= ns on this=20 list on what could be done to at least address the most obvious issues (i= =2Ee. UA) [1][2] [1] https://mailarchive.ietf.org/arch/msg/doh/vHjITrOMhWSdrozGFe4-eGNMEJc= [2] https://mailarchive.ietf.org/arch/msg/doh/BFYfWTrnxU0iHeGVqvbIMlGJ6lA= --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --LmBmNizj8ouCNEUyl58NFhAv2XT1Luawf-- --wG9IkxBoXwfpaVGQRIEq6VlwNA2vuZdB6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsrhz8ACgkQrWE4wkXN Qn5p1xAAoIq8Sa2TK14zPiJtH6KnCq2gvzYbxliwuC535zyUXXjs/Yux7RAlUKRA +EIufeYjsHUJMom92Nnw+tqMe6quB9Voa08rHuahRUzGIyKOKMXsAAp9halftKyx ZsO43x21e1VoRIXToCWS2lkwameoUdjfKCqxNFrR2NR7GGjkH6Rylz93IWb5rI+x faeyJUYGW6JP6oOO921QN9oKVXhJM5vObmg11wKQSPgcEDfiP43flJJHlvj6DH7k 6ZYVP4pXByYBG9mtbN5y9WS32trWwtM/Xxm4rIzaXW9D3m/BD17B3s98alNSr2Hb 8ikK1qRRZGgsT6AUXrniqS0gJbwFX8c/Oi+0CG2nI1OziLSZfLUWKbre9f7sLqhX Ty45AsEYCcLvgBZnXR2NBVBew+d+Lxq7tq5q12aOt0iGHoYumsLXEoMV4ZJyLPRm W3oXBECKaOTiTZI/puRAXqaHFovY4njniJOM0rNZ18bebZbz1R4UtAtUiHCCWkGH gp78SKwke+FcLw7PkUybTt4NP33kPMR+ekFDmZIDqq0LWIK0akvrHf9TTLoh9eKQ E0UfHphqRzPbAsB7Kec7/F3LGDKTqkQyV1lc8r9y9/mZXElvhu8L7Ifvf9/QO4QS W8s+Eso9YOOULZlCurI+9O3dImvVnUH6qKHcLDGsjstt5oPRxSw= =qNuc -----END PGP SIGNATURE----- --wG9IkxBoXwfpaVGQRIEq6VlwNA2vuZdB6-- From nobody Thu Jun 21 04:22:22 2018 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 D62A6131221 for ; Thu, 21 Jun 2018 04:22:10 -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 um2y9ulkrllr for ; Thu, 21 Jun 2018 04:22:05 -0700 (PDT) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [52.201.171.122]) (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 B4C22131245 for ; Thu, 21 Jun 2018 04:22:05 -0700 (PDT) Received: from zmcc-5-mta-1.zmailcloud.com (zmcc-5-mta-1.zmailcloud.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id EB4B9405D5; Thu, 21 Jun 2018 06:31:03 -0500 (CDT) Received: from zmcc-5-mta-1.zmailcloud.com (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id A3800C08EC; Thu, 21 Jun 2018 06:22:04 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 957E8C04A9; Thu, 21 Jun 2018 06:22:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id caskUp35npw1; Thu, 21 Jun 2018 06:22:04 -0500 (CDT) Received: from [192.168.1.204] (unknown [83.136.45.97]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPSA id AEA2CC08F0; Thu, 21 Jun 2018 06:22:03 -0500 (CDT) To: Adam Roach , Patrick McManus , Ted Hardie Cc: DoH WG References: From: Howard Chu Message-ID: Date: Thu, 21 Jun 2018 12:22:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 SeaMonkey/2.53a1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:22:19 -0000 Adam Roach wrote: > [as an individual] > > I agree with Patrick's analysis here, and think the proposed text (plus the > "minimal set of data" statement below) is likely to serve the purpose well. In > particular, I agree with Patrick that the various features that have been > cited so far each serve a useful purpose, and that such purposes may have a > place in DoH deployments. Giving implementors a heads up about the privacy > trade-offs seems appropriate. Mandating (MUST or SHOULD) that DoH runs over a > minimal profile of HTTP seems to remove several of the advantages of using > HTTP at all. That's overstating things. It seems the primary benefit is being able to hide DoH traffic within standard HTTPS traffic, making it more difficult to filter out at firewalls. That benefit remains, even if barebones HTTP requests are used. >> On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie > > wrote: >> >> Repeating the comment I made at Github: >> >> Is there a reason not to make a recommendation for the case of a >> DOH-only service? The current text says: >> >> Implementations of DoH clients and servers need to consider the benefit >> and privacy impact of all these features, and their deployment context, >> when deciding whether or not to enable them. >> >> Would you consider a recommendation like "For DOH clients which do not >> intermingle DOH requests with other HTTP suppression of these headers >> and other potentially identifying headers is an appropriate data >> minimization strategy."? I would expect this to be the common case - most of the time, clients' HTTP(s) traffic will be to a wide variety of web servers, but only a single DNS/DoH server. And that particular DNS/DoH server is unlikely to be serving any interesting web pages for any clients. As such, the frequency of intermingled connections should be low-to-zero. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From nobody Thu Jun 21 04:29:25 2018 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 F3A1A131239 for ; Thu, 21 Jun 2018 04:29:12 -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 LbMAnGhgBzt8 for ; Thu, 21 Jun 2018 04:29:10 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 960C2131241 for ; Thu, 21 Jun 2018 04:29:10 -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 w5LBT7kU000795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jun 2018 13:29:07 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w5LBT7w3000791; Thu, 21 Jun 2018 13:29:07 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 21 Jun 2018 13:29:07 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Howard Chu cc: DoH WG In-Reply-To: Message-ID: References: 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] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:29:22 -0000 On Thu, 21 Jun 2018, Howard Chu wrote: > that particular DNS/DoH server is unlikely to be serving any interesting web > pages for any clients. As such, the frequency of intermingled connections > should be low-to-zero. That's a rather pessimistic view of the DoH future. I think it is likely that some DoH server operators will be companies with distributed presence so that they can offer proximity to users; CDNs and the likes. CDNs also host web sites. They should thus be perfect candidates for serving both web content and DoH requests over the same connections. Especially in combination with the ORIGIN frame etc. -- / daniel.haxx.se From nobody Thu Jun 21 04:34:40 2018 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 3C92E131228 for ; Thu, 21 Jun 2018 04:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 2cyBmF-XHfBQ for ; Thu, 21 Jun 2018 04:34:36 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 F14E6130E7E for ; Thu, 21 Jun 2018 04:34:35 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=54166) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fVxrC-0003Dp-1L; Thu, 21 Jun 2018 12:34:34 +0100 From: Sara Dickinson Message-Id: <78C7C2B7-BEE5-44CA-913E-9168E399DFC1@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C565E3F-60C8-441E-8F60-5AF96E8D828C" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 21 Jun 2018 12:34:20 +0100 In-Reply-To: Cc: nusenu , DoH WG , Ted Hardie To: Patrick McManus References: X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:34:39 -0000 --Apple-Mail=_0C565E3F-60C8-441E-8F60-5AF96E8D828C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jun 2018, at 01:58, Patrick McManus = wrote: >=20 > Hi Nusenu, >=20 > On Wed, Jun 20, 2018 at 8:06 PM, nusenu > wrote: >=20 > It does not introduce new concerns when compared with HTTPS=20 > but it does introduce new privacy converns when compared with=20 > DNS over UDP, TCP or TLS (RFC7858), >=20 > I started to go down this path, but it pretty quickly became clear = that comprehensive treatment of this kind of comparison is a different = document - though I think describing things in layers does a decent job = of pointing out where these various properties come into play. DoH needs = to describe the properties of DoH.. the proposed text certainly doesn't = try and hide from the fingerprintability of the http system doh is = using. But I also support (as other have voiced) at least a statement that it = does introduce new concerns compared with=20 DNS over UDP, TCP or TLS (RFC7858) which is missing from the new text. = Also a clear justification of why the design decisions were made (if = I=E2=80=99ve heard the current arguments correctly). I propose: OLD: =E2=80=9CDoH inherits the privacy properties of the HTTPS stack and is = not known to introduce new concerns beyond that of HTTPS." NEW: =E2=80=9CAs a deliberate design choice DoH inherits the privacy = properties of the HTTPS stack and is not known to introduce new concerns beyond that = of HTTPS. As a consequence, however, it does introduce new privacy concerns when = compared with DNS over UDP, TCP or TLS (RFC7858). The rationale for this decision = is that=20 retaining the ability to leverage the full functionality of the HTTP = ecosystem is more important than placing any constraints on this new protocol based on = privacy considerations." > The IP layer paragraph includes mitigations, the paragraphs about=20 > the other layers are missing mitigations. >=20 >=20 > those mitigations are there to provide context/scope to the addressing = problem - not advice on how to mitigate it :) For most of the other = features the mitigation is "don't use it" which of course has a cost. But that cost would be low for a system resolver for example that could = easily gain many benefits of DoH without needing to include hardly any = of the HTTP bells and whistles. The current assumptions are very browser = centric.=20 I support adding the text as suggested by others e.g. "In making this evaluation DoH clients should use the minimal set of = data (e.g. headers, cookies) that can achieve the desired feature set = whilst minimizing potentially identifying information being passed. For = DOH clients which do not intermingle DOH requests with other HTTP = messages suppression of these headers and other potentially identifying = headers is an appropriate data minimization strategy.=E2=80=9D Sara.=20 --Apple-Mail=_0C565E3F-60C8-441E-8F60-5AF96E8D828C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 21 Jun 2018, at 01:58, Patrick McManus <pmcmanus@mozilla.com> wrote:

Hi Nusenu,

On Wed, = Jun 20, 2018 at 8:06 PM, nusenu <nusenu-lists@riseup.net> wrote:

It does not introduce new concerns when compared with HTTPS
but it does introduce new privacy converns when compared with
DNS over UDP, TCP or TLS (RFC7858),

I started to go down = this path, but it pretty quickly became clear that comprehensive = treatment of this kind of comparison is a different document - though I = think describing things in layers does a decent job of pointing out = where these various properties come into play. DoH needs to describe the = properties of DoH.. the proposed text certainly doesn't try and hide = from the fingerprintability of the http system doh is using. =

But I also support (as other have voiced) at least = a statement that it does introduce new concerns compared = with 
DNS over UDP, TCP or TLS (RFC7858) which is missing from = the new text.  Also a clear justification of why the design = decisions were made (if I=E2=80=99ve heard the current arguments = correctly).

I propose:

OLD:
=E2=80=9CDoH inherits the privacy = properties of the HTTPS stack and is not known to introduce new concerns = beyond that of HTTPS."

NEW:
=E2=80=9CAs a deliberate design = choice DoH inherits the privacy properties of
the HTTPS stack = and is not known to introduce new concerns beyond that of = HTTPS.
As a consequence, however, it does introduce new = privacy concerns when compared
with DNS over UDP, TCP or TLS = (RFC7858). The rationale for this decision is = that 
retaining the ability to leverage the full = functionality of the HTTP ecosystem is more
important than = placing any constraints on this new protocol based on privacy = considerations."

The IP layer paragraph includes mitigations, the paragraphs about =
the other layers are missing mitigations.


those mitigations are there to provide = context/scope to the addressing problem - not advice on how to mitigate = it :) For most of the other features the mitigation is "don't use it" = which of course has a cost.

But that cost would be low for a system resolver = for example that could easily gain many benefits of DoH without needing = to include hardly any of the HTTP bells and whistles. The current = assumptions are very browser centric. 

I support adding the text as suggested by others = e.g.
"In making this evaluation DoH clients should use = the minimal set of data (e.g. headers, cookies) that can achieve the = desired feature set whilst minimizing potentially identifying = information being passed. For DOH clients which do not intermingle DOH = requests with other HTTP messages suppression of these headers and other = potentially identifying headers is an appropriate data minimization = strategy.=E2=80=9D

Sara. 





= --Apple-Mail=_0C565E3F-60C8-441E-8F60-5AF96E8D828C-- From nobody Thu Jun 21 04:41:38 2018 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 20A30131230 for ; Thu, 21 Jun 2018 04:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oxd1ifjRkrnP for ; Thu, 21 Jun 2018 04:41:34 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB881130E7E for ; Thu, 21 Jun 2018 04:41:34 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 586191A0385 for ; Thu, 21 Jun 2018 04:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529581294; bh=HyGMFl+hedwRvbg4he+SXqe+/b/hJM87mLCac9BLHAY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KVEpb1VLly0n9L5PFbgBieAI2LHoQF7TcguL7DlxOO1ugWpekgAaL7rGAwMp0t2TY 9IaY9oVJG3Qdmpga7vIg0aro+hhFmxXSpCAN0IxNE0dZB4KjSPuZUdkfMsPHqXtKvI FrZZRaR2g19spjEHSlNfSwLv4/L48qi4vDmRfEVY= X-Riseup-User-ID: 70B420CA3B07BD60954CB8153FDD91F5FBE964FB083B224B44C3F1676AB4C790 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 6C759C7BDB for ; Thu, 21 Jun 2018 04:41:33 -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: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> Date: Thu, 21 Jun 2018 11:41:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="z3lP80rK4e9KkV91iSddShPUinhQ6ijf7" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:41:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --z3lP80rK4e9KkV91iSddShPUinhQ6ijf7 Content-Type: multipart/mixed; boundary="caQQkaE92jx3yASbNDZpMAeOXUSCKkTRX"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> Subject: Re: [Doh] New Privacy Considerations Section Proposal References: In-Reply-To: --caQQkaE92jx3yASbNDZpMAeOXUSCKkTRX Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hewitt, Rory: > "DoH clients should use the minimal set of data (e.g. headers, cookies)= that=20 > can achieve the desired feature set whilst minimizing potentially ident= ifying=20 > information being passed." I like this as a start with the following modification: should -> SHOULD and followed by what a minimal example DoH client request looks like and the = specific advice that Sara gave in her Privacy Consideration section wrt header (sp= ecifically UA). --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --caQQkaE92jx3yASbNDZpMAeOXUSCKkTRX-- --z3lP80rK4e9KkV91iSddShPUinhQ6ijf7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsrjugACgkQrWE4wkXN Qn55zxAAxYU3xN7Okp3wvGfGcSvfdVj+qMO2+CG5ICiJNNvPjLdgyz9rDN1w2TZX kQzI8l6JZEdGKRSLasNMcathTbt59ez1WJR8z0984YGlgctHywD5RcUunvr9gxcm Ad5Gc8ZRP467/hegTB/0Bipx8aq61AmK04Lp4rEMiREV6ewuqWc0QJRrKHY7EXz4 JjQC6ed0kjszNFaKKdYZPuwyve04Ormk1vZnd5odthYAlwHVTXRT0wx5q5xnM+d/ drong9fEhYAUsuV4rQtWky86JQ7wlK/VMenYjs16ZPQDkE/YDbm+WnQ/3HOXSND7 UMptWlsHZi2ckk09OKkv0JPBXe6E9lp/EzJ3orsnT0ckmaEZD0k16EPNhM6a9OZn BMrcuz0SI344fGuAISQgxohQhs7Hi5IzWvM8hsHjuhKoyf25eb0vZrxTd9LESDDg /xjB8g/x5+KcKqIegNGUwaGulShV43AxI7QF9/KywAEiU5EQvUj1gqTS/rLpBRGi frPP8jA9xvmfbftbqkfxNCmVP6IDCyKXIU/WZSm/fY4b5MU3byZga9pThWX8zjwq zNLii6b3rs7bkZqYJWTTpOcn5t17xOZVoDBROVzDLtpvYEtHf1Ru8wSzGSbceyZV Nr5iJ6K3dccPMyjL6RoeIuN34Ndo0JWo6zG4nhDLliRKDQkno+M= =N8D2 -----END PGP SIGNATURE----- --z3lP80rK4e9KkV91iSddShPUinhQ6ijf7-- From nobody Thu Jun 21 04:45:29 2018 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 E8A35131234 for ; Thu, 21 Jun 2018 04:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 g5OqszeKYy8T for ; Thu, 21 Jun 2018 04:45:23 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9F3130E7E for ; Thu, 21 Jun 2018 04:45:23 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 0852A1A0B25 for ; Thu, 21 Jun 2018 04:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529581523; bh=eVbkznBUPf7Y27AKBM+xetb8GL4UsbkYe3t0LbZ40mM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VjABwhM5falsstc5pSaJO0fEmdassUsq57+cXboMiQ09O8Q5nnBfZXQFtUFsoOC5v CGscfSOjenQnJbOrQOs227vuOXwTYDxIFichlphyvVF6kaETVN1uTp4crtE074AlWX QZ7e3+yCTH0iCTtLtAtxYuw/zP8hf8qyFoj7PLbY= X-Riseup-User-ID: 73FE68EAAC5E460278F20FA1259AAA4D9052AC63C0E3A707FD1DA542CC2F4D04 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 3C0C3C7B2C for ; Thu, 21 Jun 2018 04:45:21 -0700 (PDT) To: doh@ietf.org References: <78C7C2B7-BEE5-44CA-913E-9168E399DFC1@sinodun.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: Thu, 21 Jun 2018 11:45:00 +0000 MIME-Version: 1.0 In-Reply-To: <78C7C2B7-BEE5-44CA-913E-9168E399DFC1@sinodun.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="99ZUmhgDTquiwM9ylD8Zlrp468XMJR3wO" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:45:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --99ZUmhgDTquiwM9ylD8Zlrp468XMJR3wO Content-Type: multipart/mixed; boundary="VyfbpQTO1JRxsGljs73QglHAai5ZSQUWj"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: Subject: Re: [Doh] New Privacy Considerations Section Proposal References: <78C7C2B7-BEE5-44CA-913E-9168E399DFC1@sinodun.com> In-Reply-To: <78C7C2B7-BEE5-44CA-913E-9168E399DFC1@sinodun.com> --VyfbpQTO1JRxsGljs73QglHAai5ZSQUWj Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable > I propose: >=20 > OLD: =E2=80=9CDoH inherits the privacy properties of the HTTPS stack an= d is > not known to introduce new concerns beyond that of HTTPS." >=20 > NEW: =E2=80=9CAs a deliberate design choice DoH inherits the privacy > properties of the HTTPS stack and is not known to introduce new > concerns beyond that of HTTPS. As a consequence, however, it does > introduce new privacy concerns when compared with DNS over UDP, TCP > or TLS (RFC7858). The rationale for this decision is that retaining > the ability to leverage the full functionality of the HTTP ecosystem > is more important than placing any constraints on this new protocol > based on privacy considerations." +1 this is a rather clear statement. thanks for that! --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --VyfbpQTO1JRxsGljs73QglHAai5ZSQUWj-- --99ZUmhgDTquiwM9ylD8Zlrp468XMJR3wO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsrj80ACgkQrWE4wkXN Qn5o0Q//W6LfqkDVxi7A5wiSTETT/FD7+QAEOxK2MyStkVCJXiKNM6iYSVLShFZv 0i+uk/33ojuQlOPO1n/DvhQ8I1YCSZk8wvZih5VxVmMy2L6Cqc3SnZ6nLvP4hEQ2 tdcoSuKxlSeVEKwM1vCjMcCwqQdksvCBoGGzi9S+BA0NVltV/JUeLB2O3MRNsP54 K01KnJ6IeG4lO1HtPQaLeXKIL3ZS84LX97WTvOADIa5fAcDEXnqcPH8Om+/zB9ks BEVPn3LJZIaItGLr+qk3GUbzOn/zurtq8topUnLqw4ukgqi2qEbT7ZB5BvUGlM0D N4j0pTNrWlmUmudk1eEgb6AV4iZYu+ZenWWKnjIZrbGNet9HIMVLKg8zWZH7gnHq 1xk4+vNRzcntdP6TlkwXOAmt5Zpcaq3HxGsxAVyPmFv2dx14tk4FCP8PeVfxHhVo KWyQswzesJPZGerFwchLMTALq1abKcjUNTyGGn0zCj5mr/B5TE3jM0FvLAuY8nW8 7Yx4w0Ws9m2NhZhKCcC5WgUrwiKODB2D4Z0++sJ77GtafSqmE7CNfB8zaBj7/SyS yykoz0BLJd6Hqi+aN8kvC6FVMMnry6DEDZcOqEWwKMg7gpwaZ84eRbjh0FEQNoRO 4nJFWGv6W1jSkfBFloxNDE7Z+08XEYwFGYzAOrGGHPa1sOV7ayQ= =Vewt -----END PGP SIGNATURE----- --99ZUmhgDTquiwM9ylD8Zlrp468XMJR3wO-- From nobody Thu Jun 21 04:50:33 2018 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 1D77B131228 for ; Thu, 21 Jun 2018 04:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 04T9O42ISc_Q for ; Thu, 21 Jun 2018 04:50:27 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF41C130E7E for ; Thu, 21 Jun 2018 04:50:26 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id C8A949FB55; Thu, 21 Jun 2018 11:50:23 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 8BE42AC6411; Thu, 21 Jun 2018 13:50:23 +0200 (CEST) Date: Thu, 21 Jun 2018 13:50:23 +0200 From: bert hubert To: Sara Dickinson Cc: Patrick McManus , nusenu , Ted Hardie , DoH WG Message-ID: <20180621115023.GC26965@server.ds9a.nl> References: <78C7C2B7-BEE5-44CA-913E-9168E399DFC1@sinodun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78C7C2B7-BEE5-44CA-913E-9168E399DFC1@sinodun.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:50:29 -0000 On Thu, Jun 21, 2018 at 12:34:20PM +0100, Sara Dickinson wrote: > NEW: > “As a deliberate design choice DoH inherits the privacy properties of > the HTTPS stack and is not known to introduce new concerns beyond that of HTTPS. > As a consequence, however, it does introduce new privacy concerns when compared > with DNS over UDP, TCP or TLS (RFC7858). The rationale for this decision is that > retaining the ability to leverage the full functionality of the HTTP ecosystem is more > important than placing any constraints on this new protocol based on privacy considerations." +1 ! > "In making this evaluation DoH clients should use the minimal set of data > (e.g. headers, cookies) that can achieve the desired feature set whilst > minimizing potentially identifying information being passed. For DOH > clients which do not intermingle DOH requests with other HTTP messages > suppression of these headers and other potentially identifying headers is > an appropriate data minimization strategy.” +1 ! Bert From nobody Thu Jun 21 04:58:39 2018 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 416DE130DC3 for ; Thu, 21 Jun 2018 04:58:36 -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, FREEMAIL_FROM=0.001, 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 k_Fegoa44DV7 for ; Thu, 21 Jun 2018 04:58:32 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.175]) (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 2E4311277D2 for ; Thu, 21 Jun 2018 04:58:32 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 3824 invoked from network); 21 Jun 2018 13:58:29 +0200 Received: from agkm49.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.140.49]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 21 Jun 2018 13:58:29 +0200 To: nusenu , DoH WG References: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Autocrypt: addr=mat.jonczyk@o2.pl; prefer-encrypt=mutual; keydata= xsFNBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/qDoPh52f ExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkxJww5X/2ZAtFjUJxO QjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOadTy5hvwv0rjNjohau1y4XfxU DdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSEAhs2rOTN6pnWJVd7ErauehrET2xo2JbO 4lAv0nbXmCpPj37ZvURswCeP8PcHoA1QQKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzg jxSYVZRAWVsdNakfT7xhkaeHjEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7yln DRrda+1EVObfszfBWm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnS RP/s9t+C8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaGDhVeLUVF Q+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQABzSRNYXRldXN6IEpv xYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD7CwX4EEwECACgFAlqMDyQCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhhCv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI 1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsUUAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52 hZxMsCQyzjGOcBAi0zmWGYB4xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU 9bzFCyqZ8kAqwOoCCx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3 ADg8sGuq4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbydWVke0FSR AzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFjGdeeggv668M7GmKl +SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXCVEwW4q17v8gNsPyVUVEdIroK cve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOWmyzCLQ1YoUZMxH+ddivDQtlKCp6JgGCz c9YCESxVii0vo8TsHdIAjQ/px9KsuYBmOlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7I U16IAtK5b7RpzsFNBFqMDyQBEACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+p Bw5/D2ruHhj1Bgs6Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01 ltYrMYV1IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv830ZCQ5Ds U0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2ISO0OAAMBKea7slr mu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJFyiZ0vYAUTwtITyjYxZWJbKJh JFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S4 16W9lBDJeHhmcVOsn+04x5KIxHtqAP3mkMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXf kgWJtW+JziZf6LYx4WvRa80VDIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9Sm kfTFrHOgiTpwZnI9saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABwsFl BBgBAgAPBQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbljJusw6xQ iKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbHb1GJtLF5HyI1q4j/ zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9mmDLEwO4ULK2quF6RYtbvg+2 PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dEjTx+uYCWpvcw3rRDz7aMs401CphrlMKr WndS5qYcdiS9fvAfu/Jp5KIawpM0tVrojnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y 6LHzJWsnLnL1o7MUARU++ztOl2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuw gF7DbkdscM7fkYzkUVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X2 0nI2LedLnIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fww8Ihl8aS TANkZ3QqXNX2 Message-ID: Date: Thu, 21 Jun 2018 13:58:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PwtiOFCqksk3njvzc5UQKnflsXgvOA1OA" X-WP-MailID: 3eb5f3cf4f047daaa86934ba702bc29a X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [YbNW] Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:58:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PwtiOFCqksk3njvzc5UQKnflsXgvOA1OA Content-Type: multipart/mixed; boundary="C9MFZJFiSEe0wkQSZGyUnxGJ44MzLfgzK"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: nusenu , DoH WG Message-ID: Subject: Re: [Doh] New Privacy Considerations Section Proposal References: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> In-Reply-To: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> --C9MFZJFiSEe0wkQSZGyUnxGJ44MzLfgzK Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 21.06.2018 o=C2=A013:41, nusenu pisze: >=20 >=20 > Hewitt, Rory: >> "DoH clients should use the minimal set of data (e.g. headers, cookies= ) that=20 >> can achieve the desired feature set whilst minimizing potentially iden= tifying=20 >> information being passed." >=20 >=20 > I like this as a start with the following modification: > should -> SHOULD >=20 > and >=20 > followed by what a minimal example DoH client request looks like and th= e specific > advice that Sara gave in her Privacy Consideration section wrt header (= specifically UA). >=20 >=20 I am afraid that ensuring that the minimal set of data is being used may = be difficult in practice, for example in simpler implementations that do not= have complete control over the stack. For example, it may be non-trivial to di= sable TCP Fast Open when using a particular networking library. Additionally, fulfilling this requirement to the letter would require ins= ight into the whole protocol stack, which would require much knowledge and exp= ertise. It should not be assumed that DOH implementers are knowledgeable about TC= P Fast Open or HTTPS session tickets, for example. What is more, there has been talk about using DOH in JavaScript. I would rather support the previous text in the PR: Implementations of DoH clients and servers need to consider the benefit and privacy impact of all these features, and their deployment context, when deciding whether or not to enable them. Greetings, Mateusz Jo=C5=84czyk --C9MFZJFiSEe0wkQSZGyUnxGJ44MzLfgzK-- --PwtiOFCqksk3njvzc5UQKnflsXgvOA1OA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEVwj0eFevwwaT4Zqs+9ZauGEK/sYFAlsrksoACgkQ+9ZauGEK /sY4nA/+JsjNMfupJj0xBd0rJ2rlA5d1EW2qz/kMU27AMYM02VMgQ6ppx++Wk+Ky W7bJXMLQ9K8mJd0kUzUIM4Fxh56I0mO+wwGSNMItD7bygE/DOJMTRyGAI/sejj8i KrQFO0piA42eQ0CrKDzNLwaMltJMSnfSRmJBWLdY2bm+WIHLouvBkeoOF8tmi4jP VFih+FVvqYNOOuGbi6mZp5V/sMWPmfbGOP143nW9G0/Jo40atw/6Bz6MAuz+ypPM GlM/R8YG59rBFC85kO9VRoe5CySNA3rg5ISV0E/0nsUk2jaksB4fr7CpWWhpXFkQ E1UXm1ep/P0SNVTrSZTxZm6xfRteLxelCpJ1aP9LM7cEKO3DOS9UK6dfiLYNjm3U fITU7LYcnTCbFp20WFuLWF4MFclnhn+W86sG8O1UHizEdhjhz/NCVjoZ/D04wbYg QkMmvRnUwDSyn/EfrpLkkiEQMYti6YyzRzcFIODu+bf0+6K+b9FElAC1oMCePYXj OVMJTQczcZ7C1NQ5/kihOj3mAH1+8Uay/Xmhcns3biS47gYwnHKxmYjZ9lg/mG4t JdO/YNeihenMFJYlHpeS+21NH0/ig8yNLfuLvsxQN8TwLSMf3WmX80Il/dqxN/n2 ADdVMahdGpWvxEX+uqlvdNpNfwTW8kf2z6dOJhu7kYP5wJJq/LU= =94Xv -----END PGP SIGNATURE----- --PwtiOFCqksk3njvzc5UQKnflsXgvOA1OA-- From nobody Thu Jun 21 04:59:04 2018 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 616EA130DC6 for ; Thu, 21 Jun 2018 04:59:03 -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 XUot0DA4EX8M for ; Thu, 21 Jun 2018 04:59:01 -0700 (PDT) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [52.201.171.122]) (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 27A001277D2 for ; Thu, 21 Jun 2018 04:59:01 -0700 (PDT) Received: from zmcc-5-mta-1.zmailcloud.com (zmcc-5-mta-1.zmailcloud.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 73EC74055C; Thu, 21 Jun 2018 07:07:59 -0500 (CDT) Received: from zmcc-5-mta-1.zmailcloud.com (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 1CADAC04E9; Thu, 21 Jun 2018 06:59:00 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 0D823C08F0; Thu, 21 Jun 2018 06:59:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jRWFVCypRhLM; Thu, 21 Jun 2018 06:58:59 -0500 (CDT) Received: from [192.168.1.204] (unknown [83.136.45.97]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPSA id 374EDC04E9; Thu, 21 Jun 2018 06:58:58 -0500 (CDT) To: Daniel Stenberg Cc: DoH WG References: From: Howard Chu Message-ID: Date: Thu, 21 Jun 2018 12:58:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 SeaMonkey/2.53a1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:59:04 -0000 Daniel Stenberg wrote: > On Thu, 21 Jun 2018, Howard Chu wrote: > >> that particular DNS/DoH server is unlikely to be serving any interesting web >> pages for any clients. As such, the frequency of intermingled connections >> should be low-to-zero. > > That's a rather pessimistic view of the DoH future. It's a realistic view of devices coming preconfigured to use e.g. Google's DNS servers. > I think it is likely that some DoH server operators will be companies with > distributed presence so that they can offer proximity to users; CDNs and the > likes. CDNs also host web sites. They should thus be perfect candidates for > serving both web content and DoH requests over the same connections. > Especially in combination with the ORIGIN frame etc. Those companies may indeed arise, but the vast majority of users will never change their default DNS settings to point to them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From nobody Thu Jun 21 05:10:10 2018 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 ECFE0130DC6 for ; Thu, 21 Jun 2018 05:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3hNUMM81gQPO for ; Thu, 21 Jun 2018 05:10:07 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1B61277D2 for ; Thu, 21 Jun 2018 05:10:07 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 B930B1A051D for ; Thu, 21 Jun 2018 05:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529583006; bh=+gD/RZu9NzqTTRLnFz/jJvzYBykl4maBVDSlcwZAsBI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=HUv4ycZMJvem9+VHNQ/smlqAyYME30WdHklmp+WKqJonAIKxx8x9IOvlmqu0wr5B+ XZNaPFwB/z26KWxQlf2SeCWvj38h3c3fkjsvm1z86umee3bv3bK3tXs9f80HJAs4eN F+zE232IHTU5mwuVuAwBEDrZmtl5/i2nbk7V3odM= X-Riseup-User-ID: 563287C864B530FCAD5B212AE588BDE28D43946A5F85F06F787722EC817223F9 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id C9F3FC7B2C for ; Thu, 21 Jun 2018 05:10:05 -0700 (PDT) To: doh@ietf.org References: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> 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: Thu, 21 Jun 2018 12:09:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ONl37I1ZFZrLND5bTrgyDhcgts327VjHn" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 12:10:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ONl37I1ZFZrLND5bTrgyDhcgts327VjHn Content-Type: multipart/mixed; boundary="zoCnNvEXf8tt8Iq0UAWI9vTDnSt0o86AS"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: Subject: Re: [Doh] New Privacy Considerations Section Proposal References: <576c87a0-9b10-9eac-0a77-8cdbbf6cba80@riseup.net> In-Reply-To: --zoCnNvEXf8tt8Iq0UAWI9vTDnSt0o86AS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Mateusz Jo=C5=84czyk wrote: >>> "DoH clients should use the minimal set of data (e.g. headers, cookie= s) that=20 >>> can achieve the desired feature set whilst minimizing potentially ide= ntifying=20 >>> information being passed." >> >> >> I like this as a start with the following modification: >> should -> SHOULD >> >> and >> >> followed by what a minimal example DoH client request looks like and t= he specific >> advice that Sara gave in her Privacy Consideration section wrt header = (specifically UA). >> >> > I am afraid that ensuring that the minimal set of data is being used ma= y be > difficult in practice, for example in simpler implementations that do n= ot have > complete control over the stack.=20 Since this is about a SHOULD and not a mandatory requirement (MUST) there= is no need to be afraid to fail to implement a SHOULD recommendation? --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --zoCnNvEXf8tt8Iq0UAWI9vTDnSt0o86AS-- --ONl37I1ZFZrLND5bTrgyDhcgts327VjHn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsrlZcACgkQrWE4wkXN Qn6cbA/+PQVNNgB54O2wU0+1OBhVoJnbxB9MGiqsIutzZt0KGZKaqGmDDoDE2r+J jBbfC0RRoQvE0JsOpETisPW4ifwyfPeIe+POX38D53BqDaZWP+nPShd7zh2DMljF l9mYqd1YxG/1cp+AnQJfGD39mnENrbKqMa8MBiFdoYhGHS0GMG75d19LptsoS8L6 +G0qlA/JdEU2cuF1Us3R3HnLvPaNOTsJ8UwvajaPxMObGHqrxDXxxtvapMbL2D4w pIWfTkwFc25BjRylk2YfJJ9QBh071T76OR4tgQ1I9bY0ZVDFYtui4InKM6JUgAvN iotXBVIIczaePDkE1ZrkEjtQ0pE+MrN/XM1LRMi0+qHf5ex7AgWQ4ktLxsmmlzNP bj+s0bNRzozIxd2CB7jP+fFKi03yDTL014Mnsjsj1RZTPzFvpdgxLDySZUzhr6ps ESKRZbKWxPf9kC9dCPTt0ytAf3x4iy52kmJnWc3D7QvG76ulHhEmjchKWrNmaOFn MBVsB03Sm89gCkJdpZB2v0l5FDGSfhd9wSCcjQyYHmMTrEwRVoGIfPHuOPoRDFkj 5Dnl+ZzMXepj8p056GRSB+YkB6Q8uAlfjfMZ2AsK6VfgTJp8D38gs9TYTArT/iQT KgXQ9R9peorjtbZwVZAW5fypHHvRthaFcOsmiyh+3nmTxIBFvZM= =ZSFu -----END PGP SIGNATURE----- --ONl37I1ZFZrLND5bTrgyDhcgts327VjHn-- From nobody Thu Jun 21 05:10:29 2018 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 4F5A312D7F8 for ; Thu, 21 Jun 2018 05:10:27 -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 dQbUBByCpqtH for ; Thu, 21 Jun 2018 05:10:25 -0700 (PDT) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [52.201.171.122]) (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 204951277D2 for ; Thu, 21 Jun 2018 05:10:25 -0700 (PDT) Received: from zmcc-5-mta-1.zmailcloud.com (zmcc-5-mta-1.zmailcloud.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 8066E4056E; Thu, 21 Jun 2018 07:19:23 -0500 (CDT) Received: from zmcc-5-mta-1.zmailcloud.com (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 2FA72C0978; Thu, 21 Jun 2018 07:10:24 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 2300AC08F0; Thu, 21 Jun 2018 07:10:24 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gwnL0nvPH2mf; Thu, 21 Jun 2018 07:10:24 -0500 (CDT) Received: from [192.168.1.204] (unknown [83.136.45.97]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPSA id 84DDDC03C7; Thu, 21 Jun 2018 07:10:23 -0500 (CDT) From: Howard Chu To: Daniel Stenberg Cc: DoH WG References: Message-ID: Date: Thu, 21 Jun 2018 13:10:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 SeaMonkey/2.53a1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 12:10:27 -0000 Howard Chu wrote: > Daniel Stenberg wrote: >> On Thu, 21 Jun 2018, Howard Chu wrote: >> >>> that particular DNS/DoH server is unlikely to be serving any interesting >>> web pages for any clients. As such, the frequency of intermingled >>> connections should be low-to-zero. >> >> That's a rather pessimistic view of the DoH future. > > It's a realistic view of devices coming preconfigured to use e.g. Google's DNS > servers. > >> I think it is likely that some DoH server operators will be companies with >> distributed presence so that they can offer proximity to users; CDNs and the >> likes. CDNs also host web sites. They should thus be perfect candidates for >> serving both web content and DoH requests over the same connections. >> Especially in combination with the ORIGIN frame etc. > > Those companies may indeed arise, but the vast majority of users will never > change their default DNS settings to point to them. An additional point - it's been easy enough to launch DDoS attacks against dedicated DNS infrastructure in the past. If you combine DNS traffic and real HTTP traffic in the same server, it will become even easier to overload these servers and knock out DNS service. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From nobody Thu Jun 21 05:57:35 2018 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 362711310DF for ; Thu, 21 Jun 2018 05:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 IdJ3RzZwYQ8d for ; Thu, 21 Jun 2018 05:57:23 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 17396131115 for ; Thu, 21 Jun 2018 05:57:23 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 79F423A050 for ; Thu, 21 Jun 2018 08:57:19 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id t133-v6so2792563oif.10 for ; Thu, 21 Jun 2018 05:57:19 -0700 (PDT) X-Gm-Message-State: APt69E002YyITux9TTkLmrA+viX947nJFQjs60HGDnPH2QKS84emWpgP ymqg+nIhj5Q6cjIUW5uflq+9VGeQPRitYG14Xpg= X-Google-Smtp-Source: ADUXVKKSXhq9DWYGF++NzjDfheMzhTeCRPwvDAEtDxKTA2dRSYZFg/9QWvqgmusN2SaAH4TR/KPjr9r2HP9LHB861GU= X-Received: by 2002:aca:d7d6:: with SMTP id o205-v6mr13338274oig.347.1529585839223; Thu, 21 Jun 2018 05:57:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 05:57:18 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Thu, 21 Jun 2018 08:57:18 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Howard Chu Cc: Adam Roach , Patrick McManus , Ted Hardie , DoH WG Content-Type: multipart/alternative; boundary="00000000000099bb05056f267402" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 12:57:33 -0000 --00000000000099bb05056f267402 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 21, 2018 at 7:22 AM, Howard Chu wrote: > > I would expect this to be the common case - most of the time, clients' > HTTP(s) traffic will be to a wide variety of web servers, but only a single > DNS/DoH serve I strongly disagree with the view point that DoH clients and servers are dedicated only to DoH. The granularity of DoH is a URI (configured via a template). I understand that the use case of "use HTTPS's port and ALPN" to do something akin to DNS-over-TLS is the attractive use case for some. But we're using HTTP and trying to align with the ecosystem. Its not a tunnel. The introduction discusses some of this directly, and some other text addresses it obliquely. Note that a server may support more than one URI and that we jettisoned the .well-known of an earlier draft.. that's all because URIs are the granularity of HTTP and that is also the scope of DoH. --00000000000099bb05056f267402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 21, 2018 at 7:22 AM, Howard Chu <hyc@symas.com> = wrote:

 I would expect this to be the common case - most of the time, clients' = HTTP(s) traffic will be to a wide variety of web servers, but only a single= DNS/DoH serve=

I strongly disagree with the view point th= at DoH clients and servers are dedicated only to DoH. The granularity of Do= H is a URI (configured via a template).

I unde= rstand that the use case of "use HTTPS's port and ALPN" to do= something akin to DNS-over-TLS is the attractive use case for some. But we= 're using HTTP and trying to align with the ecosystem. Its not a tunnel= . The introduction discusses some of this directly, and some other text add= resses it obliquely. Note that a server may support more than one URI and t= hat we jettisoned the .well-known of an earlier draft.. that's all beca= use URIs are the granularity of HTTP and that is also the scope of DoH.





=C2=A0
--00000000000099bb05056f267402-- From nobody Thu Jun 21 05:57:41 2018 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 BD5F11310A7 for ; Thu, 21 Jun 2018 05:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 W3Erf9uJqebY for ; Thu, 21 Jun 2018 05:57:30 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 28D8A131242 for ; Thu, 21 Jun 2018 05:57:30 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id C3F573A03B for ; Thu, 21 Jun 2018 08:57:29 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id c128-v6so2787975oig.11 for ; Thu, 21 Jun 2018 05:57:29 -0700 (PDT) X-Gm-Message-State: APt69E3ADaM2hGKPa+i9Q+CGYF3zOvBh22SL298U5eKo/2CgcKe1+63f 9OqFtphEcXG1SPrrP/7ICT3FKjblMZcbm8Gevfk= X-Google-Smtp-Source: ADUXVKKsSDSJ7iEQudePq2XBtnYm53ST/pXlqzP6153GP4lbLNmxqhsMdcMsy7idGIkYErUR7v+o2ySbpTeR5+D7/0U= X-Received: by 2002:aca:41d6:: with SMTP id o205-v6mr14662572oia.38.1529585849575; Thu, 21 Jun 2018 05:57:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 05:57:29 -0700 (PDT) In-Reply-To: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> From: Patrick McManus Date: Thu, 21 Jun 2018 08:57:29 -0400 X-Gmail-Original-Message-ID: Message-ID: To: nusenu Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000037b963056f267520" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 12:57:39 -0000 --00000000000037b963056f267520 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 21, 2018 at 7:08 AM, nusenu wrote: > > > So because a comprehensive treatment is hard and obviously not the primary > goal of the > document a comparative statement of the privacy implications of DoH wrt > other DNS protocols > from Sara's text is no longer mentioned at all? > > I feel like it is absolutely mentioned! The text makes clear that issues arise at the IP, TCP, TLS, and HTTPS layers. UDP-based DNS suffers from IP issues, TCP-based DNS suffers from TCP and IP based issues, DNS over TLS suffers from IP, TCP, and TLS based issues, and DoH adds HTTP issues to the mix. The DoH spec is going to focus on DoH.. if another document would like to comprehensively discuss all of this that's fine by me but its not practical to do here. I'll add a small clarifying bit to the text for people to try out - but this is already most of the text. > I'd like to understand the reasoning for NOT including specific privacy > friendly > recommendations in the document, because currently the document mentions > DoH uses and requires HTTP but does not redefine it. DoH is not a mere tunnel for DNS and applications should leverage what features fit their needs. The specification(s) for those features are where you need to look to make a decision or you turn things over to a library. the high level issues but doesn't give specific advise on what to do about > it > - the implementors are basically on their own - > this is non-normative considerations text - it is highlighting what you need to consider. The primary consideration is that you are now in the HTTP ecosystem. A couple other messages have asked to highlight that the HTTP ecosystem is different than the DNS ecosystem and I'm fine with including that. --00000000000037b963056f267520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 21, 2018 at 7:08 AM, nusenu <nusenu-lists@riseup.n= et> wrote:


So because a comprehensive treatment is hard and obviously not the p= rimary goal of the
document a comparative statement of the privacy implications of DoH wrt oth= er DNS protocols
from Sara's text is no longer mentioned at all?


I feel like it= is absolutely mentioned!

The text makes clear tha= t issues arise at the IP, TCP, TLS, and HTTPS layers.

<= div>UDP-based DNS suffers from IP issues, TCP-based DNS suffers from TCP an= d IP based issues, DNS over TLS suffers from IP, TCP, and TLS=C2=A0 based i= ssues, and DoH adds HTTP issues to the mix. The DoH spec is going to focus = on DoH.. if another document would like to comprehensively discuss all of t= his that's fine by me but its not practical to do here.
<= br>
I'll add a small clarifying bit to the text for people to= try out - but this is already most of the text.


I'd like to understand the reasoning for NOT including specific privacy= friendly
recommendations in the document, because currently the document mentions

DoH uses and requires HTTP but does not r= edefine it. DoH is not a mere tunnel for DNS and applications should levera= ge what features fit their needs. The specification(s) for those features a= re where you need to look to make a decision or you turn things over to a l= ibrary.

the high level issues but doesn't give specific advise on what to do ab= out it
- the implementors are basically on their own -

this is non-normative considerations text - it is highlighting wha= t you need to consider. The primary consideration is that you are now in th= e HTTP ecosystem. A couple other messages have asked to highlight that the = HTTP ecosystem is different than the DNS ecosystem and I'm fine with in= cluding that.

=C2=A0
--00000000000037b963056f267520-- From nobody Thu Jun 21 06:57:11 2018 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 510861310D1 for ; Thu, 21 Jun 2018 06:57:00 -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] 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 7o0t3t26UvSr for ; Thu, 21 Jun 2018 06:56:58 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 067951310E6 for ; Thu, 21 Jun 2018 06:56:58 -0700 (PDT) Received: from [62.232.251.194] (port=21146 helo=[192.168.12.23]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fW04x-00074n-NZ; Thu, 21 Jun 2018 14:56:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sara Dickinson In-Reply-To: Date: Thu, 21 Jun 2018 14:56:50 +0100 Cc: nusenu , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <60056EED-498C-4E85-85A0-48A646FE04DC@sinodun.com> References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> To: Patrick McManus X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 13:57:10 -0000 > On 21 Jun 2018, at 13:57, Patrick McManus = wrote: >=20 >=20 > DoH uses and requires HTTP but does not redefine it. DoH is not a mere = tunnel for DNS and applications should leverage what features fit their = needs. The specification(s) for those features are where you need to = look to make a decision or you turn things over to a library. One further issue - RFC7626 (DNS Privacy considerations) is currently an = informative reference. If the draft is going to argue that all = implementors must make their own decision about balancing HTTP = functionality against privacy then RFC7626 is a document they should be = required to read. I think this should be a normative reference. Nit: Section 2.5 in that document is called =E2=80=98In the server=E2=80=99= not =E2=80=98On the server=E2=80=99 as in the current PR text.=20 Sara. From nobody Thu Jun 21 07:00:58 2018 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 9D0ED130E5A for ; Thu, 21 Jun 2018 07:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 q7L-IGN6f5Dc for ; Thu, 21 Jun 2018 07:00:52 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 752AD130DDD for ; Thu, 21 Jun 2018 07:00:52 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=55602) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fW08k-0007gs-AJ; Thu, 21 Jun 2018 15:00:50 +0100 From: Sara Dickinson Message-Id: <2E0A7A4D-C419-4833-94C2-A38C3CA836F1@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_69123310-983F-4743-A18D-E3601D7D219D" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 21 Jun 2018 15:00:38 +0100 In-Reply-To: Cc: Howard Chu , Ted Hardie , DoH WG , Adam Roach To: Patrick McManus References: X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:00:57 -0000 --Apple-Mail=_69123310-983F-4743-A18D-E3601D7D219D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 21 Jun 2018, at 13:57, Patrick McManus = wrote: >=20 >=20 >=20 > On Thu, Jun 21, 2018 at 7:22 AM, Howard Chu > wrote: >=20 > I would expect this to be the common case - most of the time, clients' = HTTP(s) traffic will be to a wide variety of web servers, but only a = single DNS/DoH serve >=20 > I strongly disagree with the view point that DoH clients and servers = are dedicated only to DoH. The granularity of DoH is a URI (configured = via a template). >=20 > I understand that the use case of "use HTTPS's port and ALPN" to do = something akin to DNS-over-TLS is the attractive use case for some. To many members of this working group in fact. There are already 2 = implementations in progress that fall into this category - Stubby using = DoH as a system resolver and dnsdist as a DNS resolver that offers = service over DoH. These are legitamate use cases and running code that = should be recognised in this draft even though they differ from the = browser centric view of: > But we're using HTTP and trying to align with the ecosystem. Its not = a tunnel.. There are many that want to use DoH and align it with the DNS ecosystem = where it might be akin to just a tunnel and yet still provide distinct = benefits. Sara.=20 --Apple-Mail=_69123310-983F-4743-A18D-E3601D7D219D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 21 Jun 2018, at 13:57, Patrick McManus <pmcmanus@mozilla.com> wrote:



On Thu, Jun 21, 2018 at 7:22 AM, Howard Chu <hyc@symas.com> wrote:

 I would expect this to be the common case - most of the time, clients' = HTTP(s) traffic will be to a wide variety of web servers, but only a = single DNS/DoH serve

I strongly disagree with the view point = that DoH clients and servers are dedicated only to DoH. The granularity = of DoH is a URI (configured via a template).

I understand that the = use case of "use HTTPS's port and ALPN" to do something akin to = DNS-over-TLS is the attractive use case for some. =

To many members of this working group in fact. = There are already 2 implementations in progress that fall into this = category - Stubby using DoH as a system resolver and dnsdist as a DNS = resolver that offers service over DoH. These are legitamate use cases = and running code that should be recognised in this draft even though = they differ from the browser centric view of:

 But we're using HTTP and trying to align with the = ecosystem. Its not a tunnel..

There are many that want to use DoH and align it with = the DNS ecosystem where it might be akin to just a tunnel and yet still = provide distinct benefits.

Sara. 

= --Apple-Mail=_69123310-983F-4743-A18D-E3601D7D219D-- From nobody Thu Jun 21 07:16:52 2018 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 CD4AA131094 for ; Thu, 21 Jun 2018 07:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 2sVrGZxmU1Pw for ; Thu, 21 Jun 2018 07:16:41 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEFB131092 for ; Thu, 21 Jun 2018 07:16:41 -0700 (PDT) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by linode64.ducksong.com (Postfix) with ESMTPSA id B14243A03B for ; Thu, 21 Jun 2018 10:16:39 -0400 (EDT) Received: by mail-ot0-f178.google.com with SMTP id a5-v6so3721691otf.12 for ; Thu, 21 Jun 2018 07:16:39 -0700 (PDT) X-Gm-Message-State: APt69E15fAP1pTN6B4iF89mqNlUgjHZhOlcJsKt5TbHiEoBd00q3Jt7z tBHo8dhoUeucuSOuuvdvN7iDRxM2EqtUDm5qVO0= X-Google-Smtp-Source: ADUXVKJlv1mrLWILJVcj455g35R7SqCXqg6I92HS0SJbJw16LJbyXUE2Oi2L4wx8l5CxQIqwNzlXyW0e0V+PmuSLRJo= X-Received: by 2002:a9d:1142:: with SMTP id p2-v6mr15029308otp.110.1529590594576; Thu, 21 Jun 2018 07:16:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 07:16:33 -0700 (PDT) In-Reply-To: <60056EED-498C-4E85-85A0-48A646FE04DC@sinodun.com> References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> <60056EED-498C-4E85-85A0-48A646FE04DC@sinodun.com> From: Patrick McManus Date: Thu, 21 Jun 2018 10:16:33 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: Patrick McManus , nusenu , DoH WG Content-Type: multipart/alternative; boundary="0000000000000aa973056f279085" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:16:50 -0000 --0000000000000aa973056f279085 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson wrote: > > > One further issue - RFC7626 (DNS Privacy considerations) is currently an > informative reference. If the draft is going to argue that all > implementors must make their own decision about balancing HTTP > functionality against privacy then RFC7626 is a document they should be > required to read. I think this should be a normative reference. > unfortunately 7626 is informational and making it normative from DoH would (aiui) be a down reference that isn't allowed from a standards track document. > > Nit: Section 2.5 in that document is called =E2=80=98In the server=E2=80= =99 not =E2=80=98On the > server=E2=80=99 as in the current PR text. > > got it. thanks. --0000000000000aa973056f279085 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson <<= a href=3D"mailto:sara@sinodun.com" target=3D"_blank">sara@sinodun.com&g= t; wrote:


One further issue - RFC7626 (DNS Privacy considerations) is currentl= y an informative reference. If the draft=C2=A0 is going to argue that all i= mplementors must make their own decision about balancing HTTP functionality= against privacy then RFC7626 is a document they should be required to read= . I think this should be a normative reference.

unfortunately 7626 is informational and making it normative from D= oH would (aiui) be a down reference that isn't allowed from a standards= track document.
=C2=A0

Nit: Section 2.5 in that document is called =E2=80=98In the server=E2=80=99= not =E2=80=98On the server=E2=80=99 as in the current PR text.


got it. thanks.
=C2=A0
=
--0000000000000aa973056f279085-- From nobody Thu Jun 21 07:25:43 2018 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 A9ECB130E8F for ; Thu, 21 Jun 2018 07:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 uUbWtYc4YJ19 for ; Thu, 21 Jun 2018 07:25:36 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 829BB13108C for ; Thu, 21 Jun 2018 07:25:35 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id r19-v6so1210774ywc.10 for ; Thu, 21 Jun 2018 07:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZW7n0Zr50X0qw+kQfKz8SFM8faDSBbpPSzX31UEHniI=; b=Sy3pBBkeRqWpuAbCzTAYTFXO6t0tGvGClZnIg9t4Wdrncn0Y2HYmsPd8uaCgIOvqGO pdM0EwE7/1jVC7gnLOOwqyDawERQZrL8QNbge1OLa2PRCuxq2YUkCv/yWoiRN9Bic3n5 gLhHfVnE7FioEqu+vX5Z1IBNruVSkpl8ffNx5xUV1pDYM3Nh8naZs+oGK6zXgaMycEEb UzavbyvBYiudxEXO5b7SVhv5Pg2Q0wXLl/eEMDgefsIyIc/HErwsPf4UvnlW5HL02LdG aFWG9IWlMtB3p75oMBc/9z0BCs1NDeWWmC4M2Kh08DXPqr+ta1SXQvL5YLF3gKyO1P2E I4KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZW7n0Zr50X0qw+kQfKz8SFM8faDSBbpPSzX31UEHniI=; b=QfZNgSLy16ExAD7kMTME9RK2VX9bkH6Mcevd5SvQ8JkdPO239Uy5FACIescka9cjVS G9GBPG7Wi5Gz6qN7WCp0AOTJVMN57sLE4kPc8ILCUAd/tioRxEQagFf+XRE8edCim9Mp TIOQP7FJYe+0Rgu/fX2yfJz1ADkcwyY85mtuYE2PSbRS6vTvJSCfpJIAHqEwL9OYEQYf rikqYOAjatskNH5HDzq7FLx+0eawKyfHWmSpjIQG1uAHxruF1nMXzo2Co4GK4zvTmDQE FJ5hqPOpEvKfDdZ/Y1L7Sx9Xy+0KVdMAiKfBrZloimHLN+vqsZeH4fXkdW4HG8U9ln6H BRsQ== X-Gm-Message-State: APt69E1ttIbl7lru7DUvvmCF12qtg8wNmhqx26+le4gwHvZpdmQHhf5e HFw+6xptq/QPV8ct2N5f+rjA6ZWhNhwghKX+G61oKQ== X-Google-Smtp-Source: ADUXVKIOFR6SKGxh4CDBG4dJd+q434cKKyuE6yxdQVyPFvpUq1oK57V3PmP4bFg1wXGXvVBNrvz0pBjpJyaDaZnFl5Q= X-Received: by 2002:a0d:fe07:: with SMTP id o7-v6mr9781964ywf.167.1529591134748; Thu, 21 Jun 2018 07:25:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 07:24:54 -0700 (PDT) In-Reply-To: References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> <60056EED-498C-4E85-85A0-48A646FE04DC@sinodun.com> From: Eric Rescorla Date: Thu, 21 Jun 2018 07:24:54 -0700 Message-ID: To: Patrick McManus Cc: Sara Dickinson , nusenu , DoH WG Content-Type: multipart/alternative; boundary="0000000000003d2351056f27b077" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:25:41 -0000 --0000000000003d2351056f27b077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 21, 2018 at 7:16 AM, Patrick McManus wrote: > > > On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson wrote: > >> >> >> One further issue - RFC7626 (DNS Privacy considerations) is currently an >> informative reference. If the draft is going to argue that all >> implementors must make their own decision about balancing HTTP >> functionality against privacy then RFC7626 is a document they should be >> required to read.. I think this should be a normative reference. >> > > unfortunately 7626 is informational and making it normative from DoH woul= d > (aiui) be a down reference that isn't allowed from a standards track > document. > You actually can do that. See: https://tools.ietf.org/rfcmarkup/8067 -Ekr >> Nit: Section 2.5 in that document is called =E2=80=98In the server=E2=80= =99 not =E2=80=98On the >> server=E2=80=99 as in the current PR text. >> >> > got it. thanks. > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --0000000000003d2351056f27b077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 21, 2018 at 7:16 AM, Patrick McManus <= pmcmanus@mozilla.= com> wrote:

You actually can do that. See: https://tools.ietf.org/rfcmarkup/8067

=
-Ekr


Nit: Section 2.5 in that document is called =E2=80=98In the server=E2=80=99= not =E2=80=98On the server=E2=80=99 as in the current PR text.
<= br>

got it. thanks.
=C2=A0


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--0000000000003d2351056f27b077-- From nobody Thu Jun 21 07:26:17 2018 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 B09371310A2 for ; Thu, 21 Jun 2018 07:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 PlHbegEdDqFO for ; Thu, 21 Jun 2018 07:26:02 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 81F19131246 for ; Thu, 21 Jun 2018 07:26:02 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=55742) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fW0X6-0002pP-RJ; Thu, 21 Jun 2018 15:26:00 +0100 From: Sara Dickinson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B23603B3-C1DD-4CEF-9688-D3C3FE346065" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 21 Jun 2018 15:25:55 +0100 In-Reply-To: Cc: nusenu , DoH WG To: Patrick McManus References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> <60056EED-498C-4E85-85A0-48A646FE04DC@sinodun.com> X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:26:15 -0000 --Apple-Mail=_B23603B3-C1DD-4CEF-9688-D3C3FE346065 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 21 Jun 2018, at 15:16, Patrick McManus = wrote: >=20 >=20 >=20 > On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson > wrote: >=20 >=20 > One further issue - RFC7626 (DNS Privacy considerations) is currently = an informative reference. If the draft is going to argue that all = implementors must make their own decision about balancing HTTP = functionality against privacy then RFC7626 is a document they should be = required to read. I think this should be a normative reference. >=20 > unfortunately 7626 is informational and making it normative from DoH = would (aiui) be a down reference that isn't allowed from a standards = track document. Good point, well made. I missed that. :-)=20 --Apple-Mail=_B23603B3-C1DD-4CEF-9688-D3C3FE346065 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On 21 Jun 2018, at 15:16, Patrick McManus <pmcmanus@mozilla.com> wrote:



On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson <sara@sinodun.com> wrote:


One further issue - RFC7626 (DNS Privacy considerations) is currently an informative reference. If the draft  is going to argue that all implementors must make their own decision about balancing HTTP functionality against privacy then RFC7626 is a document they should be required to read. I think this should be a normative reference.

unfortunately 7626 is informational and making it normative from DoH would (aiui) be a down reference that isn't allowed from a standards track document.

Good point, well made. I missed that. :-) 

--Apple-Mail=_B23603B3-C1DD-4CEF-9688-D3C3FE346065-- From nobody Thu Jun 21 07:35:51 2018 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 AAADC130E96 for ; Thu, 21 Jun 2018 07:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 uAl2S9Wecltz for ; Thu, 21 Jun 2018 07:35:48 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF99130E77 for ; Thu, 21 Jun 2018 07:35:48 -0700 (PDT) Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id 973843A05B for ; Thu, 21 Jun 2018 10:35:47 -0400 (EDT) Received: by mail-ot0-f182.google.com with SMTP id d19-v6so3816700oti.8 for ; Thu, 21 Jun 2018 07:35:47 -0700 (PDT) X-Gm-Message-State: APt69E2w3udi+WltGbiQdyTpAmg6d4qhiRhtA7TeqrdiihzRG6jAMjsY E36f+vYprcfMlHwAqAMlIgjBGguy8cL7n3a22Mo= X-Google-Smtp-Source: ADUXVKLtkr3bMwci3pizmYFkUwar/xWV0FKcCH9/DTm7Dcec6UxV99jMf8ghJgY41B7/UlDQVWjurjraLLQRalOp8kA= X-Received: by 2002:a9d:1142:: with SMTP id p2-v6mr15077248otp.110.1529591747324; Thu, 21 Jun 2018 07:35:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 07:35:46 -0700 (PDT) In-Reply-To: References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> <60056EED-498C-4E85-85A0-48A646FE04DC@sinodun.com> From: Patrick McManus Date: Thu, 21 Jun 2018 10:35:46 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: Patrick McManus , nusenu , DoH WG Content-Type: multipart/alternative; boundary="000000000000c03014056f27d467" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:35:50 -0000 --000000000000c03014056f27d467 Content-Type: text/plain; charset="UTF-8" but ekr counters us both - seems like 8067 fits the documents at hand well. happy to make 7626 normative knowing that. On Thu, Jun 21, 2018 at 10:25 AM, Sara Dickinson wrote: > > > On 21 Jun 2018, at 15:16, Patrick McManus wrote: > > > > On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson wrote: > >> >> >> One further issue - RFC7626 (DNS Privacy considerations) is currently an >> informative reference. If the draft is going to argue that all >> implementors must make their own decision about balancing HTTP >> functionality against privacy then RFC7626 is a document they should be >> required to read. I think this should be a normative reference. >> > > unfortunately 7626 is informational and making it normative from DoH would > (aiui) be a down reference that isn't allowed from a standards track > document. > > > Good point, well made. I missed that. :-) > > --000000000000c03014056f27d467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
but ekr counters us both - seems like 8067 fits the d= ocuments at hand well. happy to make 7626 normative knowing that.

=

On Thu, Jun= 21, 2018 at 10:25 AM, Sara Dickinson <sara@sinodun.com> wrot= e:


On 21 Jun 2018, at 15:16, Patrick McManus <pmcmanus@mozilla.com> wr= ote:



On Thu, Jun 21, 2018 at 9:56 AM, Sara Dickinson <= ;sara@sinodun.com= > wrote:


One further issue - RFC7626 (DNS Privacy considerations) is currentl= y an informative reference. If the draft=C2=A0 is going to argue that all i= mplementors must make their own decision about balancing HTTP functionality= against privacy then RFC7626 is a document they should be required to read= . I think this should be a normative reference.

unfortunately 7626 is informational and making it normative from D= oH would (aiui) be a down reference that isn't allowed from a standards= track document.

Good point, well made. I missed that. :-)=C2=A0
<= br>

--000000000000c03014056f27d467-- From nobody Thu Jun 21 09:08:39 2018 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 01F6C130F08 for ; Thu, 21 Jun 2018 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2QNSZYs_9rY5 for ; Thu, 21 Jun 2018 09:08:29 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90B8130ED6 for ; Thu, 21 Jun 2018 09:08:29 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 4EB341A0316 for ; Thu, 21 Jun 2018 09:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529597309; bh=X0mlDXoFSgtEOkRSaS944lsTWJRDxocBbVRFcDUNyRw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iCgSMjLhDjxN5E116ttprATWOab+WdxuXhqNlS0U2y5idqaVMn1sQC1/zfCfJ1lb4 LhtAzj0ySDni179D+2g8o7O8vz6U7nK0AdA2N0e5U3aq1ijVLflBQpsGDtL1SUSrGP HDDHLk4760TlhSmNac2ttQ8bQXaf8PPxw81kP2Ns= X-Riseup-User-ID: 5137C29711BA42DE0EBDCADDE8FEE063A5B0C71594113B1E4126A6AC5A7109C5 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 71DD1C7C8E for ; Thu, 21 Jun 2018 09:08:28 -0700 (PDT) To: doh@ietf.org References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> 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: Thu, 21 Jun 2018 16:08:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="80fkgf65C4G5YNXfsviqr7bsZKgdh3z8E" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 16:08:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --80fkgf65C4G5YNXfsviqr7bsZKgdh3z8E Content-Type: multipart/mixed; boundary="9FzJR6q2dxOLUavbtvDdRDNzrN9Ndhecb"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: Subject: Re: [Doh] New Privacy Considerations Section Proposal References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> In-Reply-To: --9FzJR6q2dxOLUavbtvDdRDNzrN9Ndhecb Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Patrick McManus wrote: > On Thu, Jun 21, 2018 at 7:08 AM, nusenu wrote= : >> So because a comprehensive treatment is hard and obviously not the pri= mary >> goal of the >> document a comparative statement of the privacy implications of DoH wr= t >> other DNS protocols >> from Sara's text is no longer mentioned at all? >> >> > I feel like it is absolutely mentioned! >=20 > The text makes clear that issues arise at the IP, TCP, TLS, and HTTPS > layers. by "comparative statement" I was referring to=20 " DNS-over-TLS, for example, would normally contain no client identifiers i= n the DNS messages and a resolver would see only a stream of DNS queries = originating from a client IP address. Whereas if DoH clients commonly inc= lude several headers in a DNS message (e.g. user-agent and accept-languag= e) this could lead to the resolver being able to identify the source of i= ndividual DNS requests not only to a specific end user device but to a sp= ecific application. " but Sara made already a better version of it in [1]: > I propose: >=20 > OLD: > =E2=80=9CDoH inherits the privacy properties of the HTTPS stack and is = not known to introduce new concerns beyond that of HTTPS." >=20 > NEW: > =E2=80=9CAs a deliberate design choice DoH inherits the privacy propert= ies of > the HTTPS stack and is not known to introduce new concerns beyond that = of HTTPS. > As a consequence, however, it does introduce new privacy concerns when = compared > with DNS over UDP, TCP or TLS (RFC7858). The rationale for this decisio= n is that=20 > retaining the ability to leverage the full functionality of the HTTP ec= osystem is more > important than placing any constraints on this new protocol based on pr= ivacy considerations." that hasn't gotten any feedback from the draft authors yet. [1] https://mailarchive.ietf.org/arch/msg/doh/_ju-J52e5cf7UNpgwhCbq5pln5Y= >> I'd like to understand the reasoning for NOT including specific privac= y >> friendly >> recommendations in the document, because currently the document mentio= ns >> >=20 > DoH uses and requires HTTP but does not redefine it. DoH is not a mere > tunnel for DNS and applications should leverage what features fit their= > needs.=20 Understood. Now it primarily about making this clear in the draft and the= proposed paragraph above is IMHO doing that very well. --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --9FzJR6q2dxOLUavbtvDdRDNzrN9Ndhecb-- --80fkgf65C4G5YNXfsviqr7bsZKgdh3z8E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsrzXUACgkQrWE4wkXN Qn5awBAAwjFbemzAecYLSr0DJiEGRVM3Lfo8oqQ/fBRfJ6TQplZRBSaCY/1mEVae BxMGMwbyWdAt8PfbZI+55UhKGtIYEkUXPOHWA2UVzp8fsZ8UlCGgMUR4ImaR1ix1 T+1FK2mQb7whirhnAd1QiufgbfwvBPduBywC5NJBKfMrcS87u1uB6WWheNwqUjN5 yOzGsMCmV/rErcsx2I4BQ5Od3OFh73ALSwSGaJaslBfhleqqh5ppnoXXuhKq5Vel WkTjlCUfNu2rNqeJxvt7bXDmr6+hGTgnTn26AJTRnVYYBLtDZkrOKQOWKlfVju1O tifOnfrj5FgXlvMwQMHUZff6zK5wIkxOSTbwhwMMVDziVOg2e5qcK00cTy8PpHG2 ETNzmRlnKT2LnWeYtDtu9o9ewW+69NyQ4nOQ6S7wS6jvhTbl+Xj0LS2bsvta1Yro CE9mZ0zMlQ/i5qSFtYfC5O2y/+mnYA98+nZzqlU9Egbi5z0DzD39ADOVSuXTx/W9 HA9O2eHqnHnT/Ve/UKq8yxDPm1mxA4Tf3qAW2SY4YxaXg1OXa1KrqpTMkax8dbuW oRHuKRkKCFi4DXP6zMLFqvFh6JxXVcc4rYT3wr4Now6XpWZz3/kE9aqtAHfPZsNY ZtLDRuNTFBqBb4AKHX1tZzNs8HCNElUgoibp/J9bXH2sMBlqu+o= =x6Ae -----END PGP SIGNATURE----- --80fkgf65C4G5YNXfsviqr7bsZKgdh3z8E-- From nobody Thu Jun 21 09:21:31 2018 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 50E41130F24 for ; Thu, 21 Jun 2018 09:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 uCSWly7Z7cJ2 for ; Thu, 21 Jun 2018 09:21:27 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2E19A130F1C for ; Thu, 21 Jun 2018 09:21:27 -0700 (PDT) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id A27733A05F for ; Thu, 21 Jun 2018 12:21:26 -0400 (EDT) Received: by mail-ot0-f169.google.com with SMTP id l15-v6so4225377oth.6 for ; Thu, 21 Jun 2018 09:21:26 -0700 (PDT) X-Gm-Message-State: APt69E1fbIvdeg/wqmRb4CYMkYvT2st5MU5KUl0cMJOH9yE5wmsQw+EJ xQ2EVeSHBvhRJY/2xIAw2EtokJsAiOfz1EAS3Tk= X-Google-Smtp-Source: ADUXVKIJQ14UosHLB9gfAmN1gVjZ7tMpf13l/bPT/t+t53k/mmBYxiblhSoNrutCmdE9kU3OWQfIccf/K3i7gVCk4ZE= X-Received: by 2002:a9d:419c:: with SMTP id p28-v6mr17781092ote.2.1529598086375; Thu, 21 Jun 2018 09:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 09:21:25 -0700 (PDT) In-Reply-To: References: <9fe2b4d7-14a7-934d-cd38-a7396dfec48a@riseup.net> From: Patrick McManus Date: Thu, 21 Jun 2018 12:21:25 -0400 X-Gmail-Original-Message-ID: Message-ID: To: nusenu Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000966e11056f294ee0" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 16:21:29 -0000 --000000000000966e11056f294ee0 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 21, 2018 at 12:08 PM, nusenu wrote: > > > that hasn't gotten any feedback from the draft authors yet. > > working on it :) --000000000000966e11056f294ee0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 21, 2018 at 12:08 PM, nusenu <nusenu-lists@riseup.n= et> wrote:


that hasn't gotten any feedback from the draft authors yet.
<= br>

working on it :)
=
--000000000000966e11056f294ee0-- From nobody Thu Jun 21 10:27:23 2018 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 B0791130EEE for ; Thu, 21 Jun 2018 10:27:21 -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 rVmhCKduBAQj for ; Thu, 21 Jun 2018 10:27:19 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 CA8E1130DEF for ; Thu, 21 Jun 2018 10:27:18 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 14-v6so3665449oie.3 for ; Thu, 21 Jun 2018 10:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1nLA4ikNiLObZukvN/1a85qnPeloq0QsjvGZVZrrcfk=; b=uq7mZFPBASWeMuk7Uvx2po7lVlpNLTYAry4LMyoxSlCEbDV2QFr5+ug3DB9FOqdah1 yzgpkPsUSBfOiWDod7WnHIaRGp6Y3BUbUZ2X6GhyJxfDMGEfYzzxDME30R29+QQLgUlR yRTvDVIb/24/1lqU5OCozYe8tV4xg1ptO7+yb/go2Zp2KNwnGl/Ycm+7/QrkHGBw1no3 TlJwoCbDqLneSsjSmCSQTcBs3WoSbpnD683EWOTfX2AORuRKdyuLLrJ8IrqXMo/QJG0X SEZ2SIkSW4PF3RKc7UGZ9Yp9G/8z+fp9jNVqiDyYXndy3QarN4RG7Y2XZRz63dqVCALr o/MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1nLA4ikNiLObZukvN/1a85qnPeloq0QsjvGZVZrrcfk=; b=eiSBvV9+gX2G+w6srpCFfZP3yDqbz58YnU/L9QyPA/JwxrPotJoE1A2TyCo7hV6qZO 3tXrBrwfJrqqFdUOn8QQxYn2A5x51dWcY+PnAOUIBh31anwjcvE8UiplX4eVcMamIAOA vHighjkbmjtv2owIapV6gcc3oAVTtdYF55d70Ufo0QcZ8CcvXp9jhHbHQX/K1+s1qJOm BNrTEM+yP7HJls/lo4CP8Kgpfjr67EQJeutjJ76UkhDJu9l4ZVrfdtUKyGMseNP7yijH Lqn/v9rk0n3/3D8PJDgFXI8KRhgO4KHNiFn25XN4AomD+m1UZMgmqUqJyeFYXwgwPTDv NuVA== X-Gm-Message-State: APt69E00s6MwbCS0I/psKtJ0B3JefFtmcFJ37XVv4z7AW5ozVCWaGJGQ 2MJuTi9gGziP6kbyPxkwClLV10lx0CO+Sjy6UHg= X-Google-Smtp-Source: ADUXVKIh+Tt+qU8dKbGlAM9NIDrHPswkJB6UITXYdrk5KwEdxsCk8GVqKov79GArdBhRnZMPjFIFHB9mPyc8wIK22H0= X-Received: by 2002:aca:47cb:: with SMTP id u194-v6mr15339156oia.45.1529602037837; Thu, 21 Jun 2018 10:27:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 10:26:47 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 21 Jun 2018 10:26:47 -0700 Message-ID: To: Adam Roach Cc: Patrick McManus , DoH WG Content-Type: multipart/alternative; boundary="0000000000001cf5ee056f2a3ac5" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 17:27:22 -0000 --0000000000001cf5ee056f2a3ac5 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 20, 2018 at 4:54 PM, Adam Roach wrote: > [as an individual] > > I agree with Patrick's analysis here, and think the proposed text (plus > the "minimal set of data" statement below) is likely to serve the purpose > well. In particular, I agree with Patrick that the various features that > have been cited so far each serve a useful purpose, and that such purposes > may have a place in DoH deployments. Giving implementors a heads up about > the privacy trade-offs seems appropriate. Mandating (MUST or SHOULD) that > DoH runs over a minimal profile of HTTP seems to remove several of the > advantages of using HTTP at all. > > Note that this is not actually what I said--I said "run without specific headers *when you are not interleaving DOH with other HTTP requests*". That's a use case where some key advantages of using HTTP (traversal, particularly) are maintained without affecting the other use cases which might prefer more general integration. Ted > /a > > On 6/20/18 6:03 PM, Patrick McManus wrote: > > > > On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie wrote: > >> Repeating the comment I made at Github: >> >> Is there a reason not to make a recommendation for the case of a DOH-only >> service? The current text says: >> >> Implementations of DoH clients and servers need to consider the benefit >> and privacy impact of all these features, and their deployment context, >> when deciding whether or not to enable them. >> >> Would you consider a recommendation like "For DOH clients which do not >> intermingle DOH requests with other HTTP suppression of these headers and >> other potentially identifying headers is an appropriate data minimization >> strategy."? >> >> > there are some practical problems there. Big picture you need to weigh the > reasons these things get used in your implementation decisions. Its not > like TLS didn't know they had built a tracker with session tickets, yet > dprive recommended its use anyhow :) > > every http feature has a reason an implementation might want want it in > doh. cookies can do useful things for auth. new compression algorithms > (which create a fingerprint on introduction just as surely as UA does) > enable better performance. etc.. UA strings have kept the web runinng, for > good and bad, across many unanticipated bugs for many years.. I'm not > saying those arguments win the day but its not really DoH's place to change > the properties of HTTP. Alt-Service provides great load balancing and > protocol evolution, but its basically a cache with a tracking implication > too. > > It is an important goal of this work to leverage the HTTP ecosystem - > stripping out all the HTTP parts and leaving a tunnel doesn't give it any > value. > > The picture is also complicated by the end to end message semantics of > http headers and how they interact with the hop to hop transport semantics > of the client or server. i.e. the notion of intermingle is not e2e, but > headers are. That's not really a driver, but something to keep in mind when > considering the limitations of text. > > I'm more inclined in general to use words along the lines of "should use > the minimal set of data that can achieve the desired feature set." if > that's helpful, but I'm not eager to start working through individual > design decisions. > > > > > _______________________________________________ > Doh mailing listDoh@ietf.orghttps://www.ietf.org/mailman/listinfo/doh > > > --0000000000001cf5ee056f2a3ac5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 20, 2018 at 4:54 PM, Adam Roach <adam@nostrum.= com> wrote:
=20 =20 =20
[as an individual]<= br>
I agree with Patrick's analysis here, and think the proposed text (plus the "minimal set of data" statement below) is likely = to serve the purpose well. In particular, I agree with Patrick that the various features that have been cited so far each serve a useful purpose, and that such purposes may have a place in DoH deployments. Giving implementors a heads up about the privacy trade-offs seems appropriate. Mandating (MUST or SHOULD) that DoH runs over a minimal profile of HTTP seems to remove several of the advantages of using HTTP at all.

Note that this is not actually what= I said--I said "run without specific headers *when you are not interl= eaving DOH with other HTTP requests*".=C2=A0 That's a use case whe= re some key advantages of using HTTP (traversal, particularly) are maintain= ed without affecting the other use cases which might prefer more general in= tegration.

Ted

=C2=A0=
/a

On 6/20/18 6:03 PM, Patrick McManus wrote:


On Wed, Jun 20, 2018 at 6:14 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Repeating the comment I made at Github:

Is there a reason not to make a recommendation for the case of a DOH-only service?=C2= =A0 The current text says:

Implementations of DoH clients and servers need to consider the benefit
and privacy impact of all these features, and their deployment context,
when deciding whether or not to enable them.

Would you consider a recommendation like "For DOH clients which do not intermingle DOH requests with other HTTP suppression of these headers and other potentially identifying headers is an appropriate data minimization strategy."?


there are some practical problems there. Big picture you need to weigh the reasons these things get used in your implementation decisions. Its not like TLS didn't know they had built a tracker with session tickets, ye= t dprive recommended its use anyhow :)

every http feature has a reason an implementation might want want it in doh. cookies can do useful things for auth. new compression algorithms (which create a fingerprint on introduction just as surely as UA does) enable better performance. etc.. UA strings have kept the web runinng, for good and bad, across many unanticipated bugs for many years.. I'm not saying those arguments win the day but its not really DoH's place to change the properties o= f HTTP. Alt-Service provides great load balancing and protocol evolution, but its basically a cache with a tracking implication too.

It is an important goal of this work to leverage the HTTP ecosystem - stripping out all the HTTP parts and leaving a tunnel doesn't give it any value.

The picture is also complicated by the end to end message semantics of http headers and how they interact with the hop to hop transport semantics of the client or server. i.e. the notion of intermingle is not e2e, but headers are. That's not really a driver, but something to kee= p in mind when considering the limitations of text.

I'm more inclined in general to use words along the lines of "should use the minimal set of data that can achieve the desired feature set." if that's hel= pful, but I'm not eager to start working through individual design decisions.




_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mail=
man/listinfo/doh



--0000000000001cf5ee056f2a3ac5-- From nobody Thu Jun 21 10:44:31 2018 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 C6659130FE1 for ; Thu, 21 Jun 2018 10:44: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 65TiHriwpP-G for ; Thu, 21 Jun 2018 10:44:24 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 69F6E131135 for ; Thu, 21 Jun 2018 10:44:23 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id r18-v6so4551699otk.1 for ; Thu, 21 Jun 2018 10:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c17IIP9CQoE88he0iLUedFlih0uaBonvZBoY+Nh3bNw=; b=o/buhXSfQc79PO1GYSFBqid2tRrUSzEHkW1EnJNjv+FXorM9oew6uUJ0ocrd3LwN1g xnZb9ltnj833GF1gbFFerCHtWqrEFGziR8NYNYqRNQWe3+D9xGgkkT4VDEGAuNZRhfoa fQg8UF3LI3+CU1XOvfBVx+My53ruw78GaAj9Mn9kK1d9qkZG86AKOsmnnYZ2l2+RPAX8 NxdVO8hbPznnGITGncIjGz3+yZq9ra/x/jbf0DJIeUfSfpxS4mcQHkPLjHHpz+epV7ny mOC1+Gxa2JVWRbkJPm07ndXRGnRat03X32lqhHCrzliZ/nD0DSe2t0XvovrBPttfVdnm 5a5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c17IIP9CQoE88he0iLUedFlih0uaBonvZBoY+Nh3bNw=; b=Uvv4btUKC9zZ7j04OXzdikDhicXFhtZT04ZoPNh+VKK9yg42JO9BNOnvh7drfwKAfs Ka/vlsPF37kAuWEdd9h7e42On4+MWSxWPhiP4kpZ0OEU9aY05dM0ben8DySq78ofzADr ZKeBlznmAwBraj9Iyl7uvpEgmHRQDzh+S7u83pU0DXoM2ayNvbP8o+K1KYzG9LrQM5So V7Kz95wggDPqKIWQ1DHGUKxc39GCgMl4CmDhD+8q5bVLjBmERKABML+HivIriYPS7xlr Xs9Orcrwq/GwEUhIcr7nIJ09wr9El93yFZhSaUS62NU+7RmqNm1Yn9qmQIhOa0fs/OD+ Q3TA== X-Gm-Message-State: APt69E31NYurg8ignruR2DfWV71r8wz21X/UfLty//geZgdSZ39o1TCa PzgowDHsQnzxi1wwWUVWTOuSDQj+0eVKw0dBmic= X-Google-Smtp-Source: ADUXVKIsWS1ZtEhgd7KhNyU3PoYduNrpekOPf71y7cz1CGBykugs9M+2lQ6xxPnvXiD0KkuO48uqrb37AYPMgFO0toE= X-Received: by 2002:a9d:282e:: with SMTP id m43-v6mr17278775otb.393.1529603062490; Thu, 21 Jun 2018 10:44:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 10:43:51 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 21 Jun 2018 10:43:51 -0700 Message-ID: To: Patrick McManus Cc: Howard Chu , Adam Roach , DoH WG Content-Type: multipart/alternative; boundary="0000000000002fec14056f2a7783" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 17:44:29 -0000 --0000000000002fec14056f2a7783 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 21, 2018 at 5:57 AM, Patrick McManus wrote: > > > On Thu, Jun 21, 2018 at 7:22 AM, Howard Chu wrote: > >> >> I would expect this to be the common case - most of the time, clients' >> HTTP(s) traffic will be to a wide variety of web servers, but only a single >> DNS/DoH serve > > > I strongly disagree with the view point that DoH clients and servers are > dedicated only to DoH. The granularity of DoH is a URI (configured via a > template). > > I understand that the use case of "use HTTPS's port and ALPN" to do > something akin to DNS-over-TLS is the attractive use case for some. But > we're using HTTP and trying to align with the ecosystem. > There is more than one HTTP ecosystem, and forcing some use cases to behave as if they are using it differently does not make sense. A DOH-only request stream does not need to send information on accept-language; why would it do so? Ted > Its not a tunnel. The introduction discusses some of this directly, and > some other text addresses it obliquely. Note that a server may support more > than one URI and that we jettisoned the .well-known of an earlier draft.. > that's all because URIs are the granularity of HTTP and that is also the > scope of DoH. > > > > > > > --0000000000002fec14056f2a7783 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 21, 2018 at 5:57 AM, Patrick McManus <pmcm= anus@mozilla.com> wrote:


On= Thu, Jun 21, 2018 at 7:22 AM, Howard Chu <hyc@symas.com> wrote:=

I would expect this to be the common case - most of the time, clients' = HTTP(s) traffic will be to a wide variety of web servers, but only a single= DNS/DoH serve

I strongly dis= agree with the view point that DoH clients and servers are dedicated only t= o DoH. The granularity of DoH is a URI (configured via a template).

I understand that the use case of "use HTTPS'= ;s port and ALPN" to do something akin to DNS-over-TLS is the attracti= ve use case for some. But we're using HTTP and trying to align with the= ecosystem.

There = is more than one HTTP ecosystem, and forcing some use cases to behave as if= they are using it differently does not make sense.=C2=A0 A DOH-only reques= t stream does not need to send information on accept-language; why would it= do so?

Ted


=C2=A0
Its not a tunnel. The int= roduction discusses some of this directly, and some other text addresses it= obliquely. Note that a server may support more than one URI and that we je= ttisoned the .well-known of an earlier draft.. that's all because URIs = are the granularity of HTTP and that is also the scope of DoH.




= =C2=A0

--0000000000002fec14056f2a7783-- From nobody Thu Jun 21 11:43:15 2018 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 8F8E81310A8 for ; Thu, 21 Jun 2018 11:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 OyQYf5PqYLUj for ; Thu, 21 Jun 2018 11:43:11 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 52483130E05 for ; Thu, 21 Jun 2018 11:43:11 -0700 (PDT) Received: from mail-ot0-f177.google.com (mail-ot0-f177.google.com [74.125.82.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id 1B4403A062 for ; Thu, 21 Jun 2018 14:43:09 -0400 (EDT) Received: by mail-ot0-f177.google.com with SMTP id c15-v6so4736245otl.3 for ; Thu, 21 Jun 2018 11:43:09 -0700 (PDT) X-Gm-Message-State: APt69E3KWz6IECM3CynjFAbLqVw9zLFzZnDBoN8DlQjj94DL1BOikX1/ qKs2kFQ6zj8EAuB43FNYFqIhy+k9mRHYhZVgi+U= X-Google-Smtp-Source: ADUXVKJbEn38j7P9IoXcvdaz9HVEe8qAPRtmt9Bt7o7RpR68TYSk5FM49M6JNiJ3FWKXIGITORarqvr+75hcypIH8No= X-Received: by 2002:a9d:2c41:: with SMTP id f59-v6mr15432701otb.263.1529606588752; Thu, 21 Jun 2018 11:43:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 11:43:07 -0700 (PDT) From: Patrick McManus Date: Thu, 21 Jun 2018 14:43:07 -0400 X-Gmail-Original-Message-ID: Message-ID: To: DoH WG Content-Type: multipart/alternative; boundary="0000000000005e69ff056f2b4944" Archived-At: Subject: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:43:14 -0000 --0000000000005e69ff056f2b4944 Content-Type: text/plain; charset="UTF-8" Hi All, We may be getting close to bridging the important points here - so we've made an update to the PR. (its still not merged into the working copy, but it has changed). and we can iterate from there. Thank you for the comments, and especially text proposals - they really help. The live copy is at https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and I'll snapshot it again at the end of this email The deltas make more explicit comparisons between DoH and Do(TLS), calls out some rationale about the full ecosystem in the same text that asks you to consider the cost/benefits of http features, and includes the new text about a minimal data set. -Patrick # Privacy Considerations {#PrivacyConsiderations} {{RFC7626}} discusses DNS Privacy Considerations in both "On the wire" (Section 2.4), and "In the server" (Section 2.5) contexts. This is also a useful framing for DoH's privacy considerations. ## On The Wire {#OnTheWire} DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance {{RFC7258}} and active attacks attempting to divert DNS traffic to rogue servers ({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides similar protections, while direct UDP and TCP based transports are vulnerable to this class of information leak. Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. ## In The Server {#InTheServer} A DoH application is built on IP, TCP, TLS, and HTTP. Each layer contains one or more common features that can be used to correlate different queries to the same identity. DNS transports will generally carry the same privacy properties of the layers used to implement them. For example, the properties of IP, TCP, and TLS apply to DNS over TLS implementations. The privacy considerations of using the HTTPS layer in DoH are incremental to those of DNS over TLS. DoH is not known to introduce new concerns beyond those associated with HTTPS. At the IP level, the client address provides obvious correlation information. This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time. It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity. TCP-based solutions may seek performance through the use of TCP Fast Open {{RFC7413}}. The cookies used in TCP Fast Open allow servers to correlate different TCP sessions together. TLS based implementations often achieve better handshake performance through the use of some form of session resumption mechanism such as session tickets {{RFC5077}}. Session resumption creates trivial mechanisms for a server to correlate different TLS connections together. HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, authentication request header fields explicitly identify profiles in use, and HTTP Cookies are designed as an explicit state tracking mechanism between the client and serving site and often are used as an authentication mechanism. Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale. This facilitates content negotiation and operational work-arounds for implementation bugs. Request header fields that control caching can expose state information about a subset of the client's history. Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. The DoH protocol design allows applications to fully leverage all the features of the HTTP ecosystem, including features not enumerated here. Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations should expose the minimal set of data needed to achieve the desired feature set. --0000000000005e69ff056f2b4944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

We may be getting cl= ose to bridging the important points here - so we've made an update to = the PR. (its still not merged into the working copy, but it has changed). a= nd we can iterate from there. Thank you for the comments, and especially te= xt proposals - they really help.

The live copy= is at https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200= and I'll snapshot it again at the end of this email

The deltas make more explicit comparisons between DoH and Do(TLS), c= alls out some rationale about the full ecosystem in the same text that asks= you to consider the cost/benefits of http features, and includes the new t= ext about a minimal data set.

-Patr= ick

# Privacy Considerations {#PrivacyConsider= ations}

{{RFC7626}} discusses DNS Privacy Considerations in both &qu= ot;On the
wire" (Section 2.4), and "In the server" (Secti= on 2.5) contexts. This
is also a useful framing for DoH's privacy co= nsiderations.

## On The Wire {#OnTheWire}

DoH encrypts DNS tr= affic and requires authentication of the
server. This mitigates both pas= sive surveillance {{RFC7258}} and
active attacks attempting to divert DN= S traffic to rogue servers
({{RFC7626}} Section 2.5.1). DNS over TLS {{R= FC7858}} provides
similar protections, while direct UDP and TCP based tr= ansports are
vulnerable to this class of information leak.

Additi= onally, the use of the HTTPS default port 443 and the ability to
mix DoH= traffic with other HTTPS traffic on the same connection can
deter on-pa= th devices from interfering with DNS operations and make
DNS traffic ana= lysis more difficult.

## In The Server {#InTheServer}

A DoH a= pplication is built on IP, TCP, TLS, and HTTP. Each layer
contains one o= r more common features that can be used to correlate
different queries t= o the same identity. DNS transports will generally
carry the same privac= y properties of the layers used to implement
them. For example, the prop= erties of IP, TCP, and TLS apply to DNS
over TLS implementations.
The privacy considerations of using the HTTPS layer in DoH are
incremen= tal to those of DNS over TLS. DoH is not known to introduce
new concerns= beyond those associated with HTTPS.

At the IP level, the client add= ress provides obvious correlation
information. This can be mitigated by = use of a NAT, proxy, VPN, or
simple address rotation over time. It may b= e aggravated by use of a
DNS server that can correlate real-time address= ing information with
other personal identifiers, such as when a DNS serv= er and DHCP server
are operated by the same entity.

TCP-based sol= utions may seek performance through the use of TCP Fast
Open {{RFC7413}}= . The cookies used in TCP Fast Open allow servers to
correlate different= TCP sessions together.

TLS based implementations often achieve bett= er handshake performance
through the use of some form of session resumpt= ion mechanism such as
session tickets {{RFC5077}}. Session resumption cr= eates trivial
mechanisms for a server to correlate different TLS connect= ions
together.

HTTP's feature set can also be used for identi= fication and tracking in
a number of different ways. For example, authen= tication request header
fields explicitly identify profiles in use, and = HTTP Cookies are
designed as an explicit state tracking mechanism betwee= n the client
and serving site and often are used as an authentication me= chanism.

Additionally, the User-Agent and Accept-Language request he= ader fields
often convey specific information about the client version o= r locale.
This facilitates content negotiation and operational work-arou= nds for
implementation bugs. Request header fields that control caching<= br>can expose state information about a subset of the client's
histo= ry. Mixing DoH requests with other HTTP requests on the same
connection = also provides an opportunity for richer data correlation.

The DoH pr= otocol design allows applications to fully leverage all the
features of = the HTTP ecosystem, including features not enumerated
here. Implementati= ons of DoH clients and servers need to consider the
benefit and privacy = impact of these features, and their deployment
context, when deciding wh= ether or not to enable them. Implementations
should expose the minimal s= et of data needed to achieve the desired
feature set.

--0000000000005e69ff056f2b4944-- From nobody Thu Jun 21 11:50:32 2018 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 3B9771310D3 for ; Thu, 21 Jun 2018 11:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 U9EkjHP2o0v0 for ; Thu, 21 Jun 2018 11:50:13 -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 7E4E413112E for ; Thu, 21 Jun 2018 11:50:13 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5LIkYuI001986 for ; Thu, 21 Jun 2018 19:50:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=+wYhFFOQ3NySSojlz3/2iug6lOGwkAdaei9hLOLCOCM=; b=dpgz9zrhxmLOc109yPqGWF1oyrWyx7Sof0PVbp31CmUh/TecweyLE8GVhAz6RJh3Ol4/ TTp+fDddrWSgzYFE61+xwrqaI8p15X03agyR/MooGyIE/TKXa+rh7mk7mBIaQuIaLyvm 1COG99eABe1g8lb/uFNSApa+Sv1mOQHFvKHhGXXfB0XoPhzbZxSoRYFWJERoBl5zZvV2 Mko4ecRuqWD6yt6jfb66y7JB4kHoD0GXEqEaDG7CTgk5feRssJpMJ3ySdDQo/Spsy9ja JHm9Sx5dyKAWF/Yj48CYkgqmpUvHctn5EA7IClnsT/2F3GD8MvV1/nztBKD+9u7xfKy7 8Q== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2jqnpxv6kj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Jun 2018 19:50:12 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5LIkJqt000717 for ; Thu, 21 Jun 2018 14:50:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2jmwvv0ajr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 21 Jun 2018 14:50:10 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 21 Jun 2018 14:50:10 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 21 Jun 2018 14:50:10 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Thu, 21 Jun 2018 14:50:10 -0400 From: "Hewitt, Rory" To: DoH WG Thread-Topic: [Doh] Privacy Considerations Text (#2) Thread-Index: AQHUCY+7ftjL2jjgkUClRQGMeG/U9KRrDhFg Date: Thu, 21 Jun 2018 18:50:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.109] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001E_01D40956.004FBC50" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_08:, , 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-1805220000 definitions=main-1806210202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-21_08:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806210202 Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:50:25 -0000 ------=_NextPart_000_001E_01D40956.004FBC50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001F_01D40956.004FBC50" ------=_NextPart_001_001F_01D40956.004FBC50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit +1 - new text looks good AND is readable. From: Patrick McManus [mailto:pmcmanus@mozilla.com] Sent: Thursday, June 21, 2018 11:43 AM To: DoH WG Subject: [Doh] Privacy Considerations Text (#2) Hi All, We may be getting close to bridging the important points here - so we've made an update to the PR. (its still not merged into the working copy, but it has changed). and we can iterate from there. Thank you for the comments, and especially text proposals - they really help. The live copy is at https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/200 and I'll snapshot it again at the end of this email The deltas make more explicit comparisons between DoH and Do(TLS), calls out some rationale about the full ecosystem in the same text that asks you to consider the cost/benefits of http features, and includes the new text about a minimal data set. -Patrick # Privacy Considerations {#PrivacyConsiderations} {{RFC7626}} discusses DNS Privacy Considerations in both "On the wire" (Section 2.4), and "In the server" (Section 2.5) contexts. This is also a useful framing for DoH's privacy considerations. ## On The Wire {#OnTheWire} DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance {{RFC7258}} and active attacks attempting to divert DNS traffic to rogue servers ({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides similar protections, while direct UDP and TCP based transports are vulnerable to this class of information leak. Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. ## In The Server {#InTheServer} A DoH application is built on IP, TCP, TLS, and HTTP. Each layer contains one or more common features that can be used to correlate different queries to the same identity. DNS transports will generally carry the same privacy properties of the layers used to implement them. For example, the properties of IP, TCP, and TLS apply to DNS over TLS implementations. The privacy considerations of using the HTTPS layer in DoH are incremental to those of DNS over TLS. DoH is not known to introduce new concerns beyond those associated with HTTPS. At the IP level, the client address provides obvious correlation information. This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time. It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity. TCP-based solutions may seek performance through the use of TCP Fast Open {{RFC7413}}.. The cookies used in TCP Fast Open allow servers to correlate different TCP sessions together. TLS based implementations often achieve better handshake performance through the use of some form of session resumption mechanism such as session tickets {{RFC5077}}. Session resumption creates trivial mechanisms for a server to correlate different TLS connections together. HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, authentication request header fields explicitly identify profiles in use, and HTTP Cookies are designed as an explicit state tracking mechanism between the client and serving site and often are used as an authentication mechanism. Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale. This facilitates content negotiation and operational work-arounds for implementation bugs. Request header fields that control caching can expose state information about a subset of the client's history. Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. The DoH protocol design allows applications to fully leverage all the features of the HTTP ecosystem, including features not enumerated here. Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations should expose the minimal set of data needed to achieve the desired feature set. ------=_NextPart_001_001F_01D40956.004FBC50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

= +1 - new text looks good AND is readable.

=  

From: Patrick McManus = [mailto:pmcmanus@mozilla.com]
Sent: Thursday, June 21, 2018 = 11:43 AM
To: DoH WG <doh@ietf.org>
Subject: = [Doh] Privacy Considerations Text (#2)

 

Hi = All,

 

We may be getting close to bridging the important = points here - so we've made an update to the PR. (its still not merged = into the working copy, but it has changed). and we can iterate from = there. Thank you for the comments, and especially text proposals - they = really help.

 

The live copy is at https://github.com/dohwg= /draft-ietf-doh-dns-over-https/pull/200 and I'll snapshot it again = at the end of this email

 

The deltas make more explicit comparisons between DoH = and Do(TLS), calls out some rationale about the full ecosystem in the = same text that asks you to consider the cost/benefits of http features, = and includes the new text about a minimal data = set.

 

-Patrick

 

# Privacy Considerations = {#PrivacyConsiderations}

{{RFC7626}} discusses DNS Privacy = Considerations in both "On the
wire" (Section 2.4), and = "In the server" (Section 2.5) contexts. This
is also a = useful framing for DoH's privacy considerations.

## On The Wire = {#OnTheWire}

DoH encrypts DNS traffic and requires authentication = of the
server. This mitigates both passive surveillance {{RFC7258}} = and
active attacks attempting to divert DNS traffic to rogue = servers
({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} = provides
similar protections, while direct UDP and TCP based = transports are
vulnerable to this class of information = leak.

Additionally, the use of the HTTPS default port 443 and the = ability to
mix DoH traffic with other HTTPS traffic on the same = connection can
deter on-path devices from interfering with DNS = operations and make
DNS traffic analysis more difficult.

## In = The Server {#InTheServer}

A DoH application is built on IP, TCP, = TLS, and HTTP. Each layer
contains one or more common features that = can be used to correlate
different queries to the same identity. DNS = transports will generally
carry the same privacy properties of the = layers used to implement
them. For example, the properties of IP, = TCP, and TLS apply to DNS
over TLS implementations.

The = privacy considerations of using the HTTPS layer in DoH = are
incremental to those of DNS over TLS. DoH is not known to = introduce
new concerns beyond those associated with HTTPS.

At = the IP level, the client address provides obvious = correlation
information. This can be mitigated by use of a NAT, = proxy, VPN, or
simple address rotation over time. It may be = aggravated by use of a
DNS server that can correlate real-time = addressing information with
other personal identifiers, such as when = a DNS server and DHCP server
are operated by the same = entity.

TCP-based solutions may seek performance through the use = of TCP Fast
Open {{RFC7413}}.. The cookies used in TCP Fast Open = allow servers to
correlate different TCP sessions = together.

TLS based implementations often achieve better = handshake performance
through the use of some form of session = resumption mechanism such as
session tickets {{RFC5077}}. Session = resumption creates trivial
mechanisms for a server to correlate = different TLS connections
together.

HTTP's feature set can = also be used for identification and tracking in
a number of different = ways. For example, authentication request header
fields explicitly = identify profiles in use, and HTTP Cookies are
designed as an = explicit state tracking mechanism between the client
and serving site = and often are used as an authentication mechanism.

Additionally, = the User-Agent and Accept-Language request header fields
often convey = specific information about the client version or locale.
This = facilitates content negotiation and operational work-arounds = for
implementation bugs. Request header fields that control = caching
can expose state information about a subset of the = client's
history. Mixing DoH requests with other HTTP requests on the = same
connection also provides an opportunity for richer data = correlation.

The DoH protocol design allows applications to fully = leverage all the
features of the HTTP ecosystem, including features = not enumerated
here. Implementations of DoH clients and servers need = to consider the
benefit and privacy impact of these features, and = their deployment
context, when deciding whether or not to enable = them. Implementations
should expose the minimal set of data needed to = achieve the desired
feature = set.

------=_NextPart_001_001F_01D40956.004FBC50-- ------=_NextPart_000_001E_01D40956.004FBC50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDYyMTE4NTAwN1owIwYJKoZIhvcNAQkEMRYEFHidowuElcOvMHMF+4zvRpoYIi9WMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAGi3gcRy1O0IMgEpX865qI2STVFPFg6NxgPhuEJMpL03nmf73M7Y414wSxAR ghSfuwpCylRqyCqpMCL+E3YAO9UNLf1pKqhSFKJU641i/CuqiztFEQOWdmd8dISLinwQkUY+6nPj 9Di83x84X1Ay/E9cD4h6+vCZ6OTLZ28m0Nw04kk7N2H/aNjIaWOtVmkwEt4NEdCmw0xGFNU2puwz q1F69QIPmK+s1Yw5zTd7D/hXi3f1Pby4wWFpVSdAPsiWQGKuf9Rgq05M9I1wBPnM1VSPIMqawTtD Ndav7ck0/Zg62cAnPcnY8Ym1gpDb1dU27RkvfzVi41FUYYr3slf48ycAAAAAAAA= ------=_NextPart_000_001E_01D40956.004FBC50-- From nobody Thu Jun 21 11:57:02 2018 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 BDE3A1310E5 for ; Thu, 21 Jun 2018 11:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 jawHrinxN2It for ; Thu, 21 Jun 2018 11:56:48 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 8265013124C for ; Thu, 21 Jun 2018 11:56:48 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id x6-v6so1610127ybl.12 for ; Thu, 21 Jun 2018 11:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4RZIz6JUeBqR0m7UlyIQ8dX0hUSuIyN2C50XERBvuHQ=; b=OeyE+a2Qn+9scZ3Pqa4kxSUcwRc3CbBYSVvWNDUpd0/S9wDJYgdG/qimR5qyjQRjxu kprX5YFnMp9ld9dOsQ14Z26iXed/RFerFzuuVOw9fSY1rZo2+ydhF8/wMm4ccd1ZCv0Q S8H7TZsZFzqW7NDG7IFDJ87HRrKNwWHwLLp6c/4KUZuf4nt2EbJ8yI5pKq2ZANfsGDHa TfbG+G6cZDkCA3fuYN+U1u5JsPxoQOeSlKpRZk/8znyxlu+cV3Sz6o2z6PBdA1HEHTF7 E3KeX9Y1KhdmFWJ/Pex6ZMhJ2q8pG6ZeY78BYg83zgE+G2Smm+kj5m39QSdx5fcszVkS /mpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4RZIz6JUeBqR0m7UlyIQ8dX0hUSuIyN2C50XERBvuHQ=; b=US+SXv06FhRJKu1vMD1S5XmDZ53i0+F+FKXg8ppeVQfC0byDub+7zAUmfe9feF8oQn MVPm9Eoon//Ogv5ithJ8WYiq82cMflaTIEq1edagkM9412yARPBe/pmKli+GpVCA9b2k vB0o1DhI2i/ReDfWHQW3IXdrjQzxyQ54Qp6VHK3zlKPYs6NeivjgRotBYobYVxzW6fMx oZcHs6IxuaqtP/ijZmlioCIcBuQMDOlAfJIgLEaM3V1p0EJLcABIO1doRko8CD8yRq8M BK3ISrHJCAv3ZJQ+IWSqWsaMRn9/3zCwpje8Jsd45lGB8uG2rzdroUnr24Fvh6K1QNK1 g6Xg== X-Gm-Message-State: APt69E3YW3wUabqSR6oUpLRcT0aZxiFFesOKMbe4Y5PItYbWgxrH7VYE jiDNNGEAMJB0EL7HfkiCbz5FXOMsifS14rjSVcLNXQ== X-Google-Smtp-Source: ADUXVKLL62+JHyFLieFqEoApVJiVEvBeWsD2mUvQlMYlNEVoAAR4wJ7MpzHsNmP2teJywOC8sG8MjEM0CAUu1geZrs4= X-Received: by 2002:a25:6542:: with SMTP id z63-v6mr14015515ybb.73.1529607407599; Thu, 21 Jun 2018 11:56:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 11:56:06 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 21 Jun 2018 11:56:06 -0700 Message-ID: To: Patrick McManus Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000002d1611056f2b7a54" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 18:57:02 -0000 --0000000000002d1611056f2b7a54 Content-Type: text/plain; charset="UTF-8" Can you please enable comments on the PR so that people can provide detailed feedback -Ekr On Thu, Jun 21, 2018 at 11:43 AM, Patrick McManus wrote: > Hi All, > > We may be getting close to bridging the important points here - so we've > made an update to the PR. (its still not merged into the working copy, but > it has changed). and we can iterate from there. Thank you for the comments, > and especially text proposals - they really help. > > The live copy is at https://github.com/dohwg/ > draft-ietf-doh-dns-over-https/pull/200 and I'll snapshot it again at the > end of this email > > The deltas make more explicit comparisons between DoH and Do(TLS), calls > out some rationale about the full ecosystem in the same text that asks you > to consider the cost/benefits of http features, and includes the new text > about a minimal data set. > > -Patrick > > # Privacy Considerations {#PrivacyConsiderations} > > {{RFC7626}} discusses DNS Privacy Considerations in both "On the > wire" (Section 2.4), and "In the server" (Section 2.5) contexts. This > is also a useful framing for DoH's privacy considerations. > > ## On The Wire {#OnTheWire} > > DoH encrypts DNS traffic and requires authentication of the > server. This mitigates both passive surveillance {{RFC7258}} and > active attacks attempting to divert DNS traffic to rogue servers > ({{RFC7626}} Section 2.5.1). DNS over TLS {{RFC7858}} provides > similar protections, while direct UDP and TCP based transports are > vulnerable to this class of information leak. > > Additionally, the use of the HTTPS default port 443 and the ability to > mix DoH traffic with other HTTPS traffic on the same connection can > deter on-path devices from interfering with DNS operations and make > DNS traffic analysis more difficult. > > ## In The Server {#InTheServer} > > A DoH application is built on IP, TCP, TLS, and HTTP. Each layer > contains one or more common features that can be used to correlate > different queries to the same identity. DNS transports will generally > carry the same privacy properties of the layers used to implement > them. For example, the properties of IP, TCP, and TLS apply to DNS > over TLS implementations. > > The privacy considerations of using the HTTPS layer in DoH are > incremental to those of DNS over TLS. DoH is not known to introduce > new concerns beyond those associated with HTTPS. > > At the IP level, the client address provides obvious correlation > information. This can be mitigated by use of a NAT, proxy, VPN, or > simple address rotation over time. It may be aggravated by use of a > DNS server that can correlate real-time addressing information with > other personal identifiers, such as when a DNS server and DHCP server > are operated by the same entity. > > TCP-based solutions may seek performance through the use of TCP Fast > Open {{RFC7413}}.. The cookies used in TCP Fast Open allow servers to > correlate different TCP sessions together. > > TLS based implementations often achieve better handshake performance > through the use of some form of session resumption mechanism such as > session tickets {{RFC5077}}. Session resumption creates trivial > mechanisms for a server to correlate different TLS connections > together. > > HTTP's feature set can also be used for identification and tracking in > a number of different ways. For example, authentication request header > fields explicitly identify profiles in use, and HTTP Cookies are > designed as an explicit state tracking mechanism between the client > and serving site and often are used as an authentication mechanism. > > Additionally, the User-Agent and Accept-Language request header fields > often convey specific information about the client version or locale. > This facilitates content negotiation and operational work-arounds for > implementation bugs. Request header fields that control caching > can expose state information about a subset of the client's > history. Mixing DoH requests with other HTTP requests on the same > connection also provides an opportunity for richer data correlation. > > The DoH protocol design allows applications to fully leverage all the > features of the HTTP ecosystem, including features not enumerated > here. Implementations of DoH clients and servers need to consider the > benefit and privacy impact of these features, and their deployment > context, when deciding whether or not to enable them. Implementations > should expose the minimal set of data needed to achieve the desired > feature set. > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --0000000000002d1611056f2b7a54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you please enable comments on the PR so that peop= le can provide detailed feedback

-Ekr


On Thu, Jun 21, 2018 at 11:43 AM, Patrick McManus <pmcmanus@mozilla.co= m> wrote:
=
Hi All,

We may be getting close to bridging t= he important points here - so we've made an update to the PR. (its stil= l not merged into the working copy, but it has changed). and we can iterate= from there. Thank you for the comments, and especially text proposals - th= ey really help.

The live copy is at https://github.com/dohwg/draft-ietf-doh-dns-over-https/p= ull/200 and I'll snapshot it again at the end of this email

The deltas make more explicit comparisons between DoH and= Do(TLS), calls out some rationale about the full ecosystem in the same tex= t that asks you to consider the cost/benefits of http features, and include= s the new text about a minimal data set.

-Patrick

# Privacy Considerations {#Priv= acyConsiderations}

{{RFC7626}} discusses DNS Privacy Considerations = in both "On the
wire" (Section 2.4), and "In the server&q= uot; (Section 2.5) contexts. This
is also a useful framing for DoH's= privacy considerations.

## On The Wire {#OnTheWire}

DoH encr= ypts DNS traffic and requires authentication of the
server. This mitigat= es both passive surveillance {{RFC7258}} and
active attacks attempting t= o divert DNS traffic to rogue servers
({{RFC7626}} Section 2.5.1). DNS o= ver TLS {{RFC7858}} provides
similar protections, while direct UDP and T= CP based transports are
vulnerable to this class of information leak.
Additionally, the use of the HTTPS default port 443 and the ability to=
mix DoH traffic with other HTTPS traffic on the same connection can
= deter on-path devices from interfering with DNS operations and make
DNS = traffic analysis more difficult.

## In The Server {#InTheServer}
=
A DoH application is built on IP, TCP, TLS, and HTTP. Each layer
con= tains one or more common features that can be used to correlate
differen= t queries to the same identity. DNS transports will generally
carry the = same privacy properties of the layers used to implement
them. For exampl= e, the properties of IP, TCP, and TLS apply to DNS
over TLS implementati= ons.

The privacy considerations of using the HTTPS layer in DoH are<= br>incremental to those of DNS over TLS. DoH is not known to introduce
n= ew concerns beyond those associated with HTTPS.

At the IP level, the= client address provides obvious correlation
information. This can be mi= tigated by use of a NAT, proxy, VPN, or
simple address rotation over tim= e. It may be aggravated by use of a
DNS server that can correlate real-t= ime addressing information with
other personal identifiers, such as when= a DNS server and DHCP server
are operated by the same entity.

TC= P-based solutions may seek performance through the use of TCP Fast
Open = {{RFC7413}}.. The cookies used in TCP Fast Open allow servers to
correla= te different TCP sessions together.

TLS based implementations often = achieve better handshake performance
through the use of some form of ses= sion resumption mechanism such as
session tickets {{RFC5077}}. Session r= esumption creates trivial
mechanisms for a server to correlate different= TLS connections
together.

HTTP's feature set can also be use= d for identification and tracking in
a number of different ways. For exa= mple, authentication request header
fields explicitly identify profiles = in use, and HTTP Cookies are
designed as an explicit state tracking mech= anism between the client
and serving site and often are used as an authe= ntication mechanism.

Additionally, the User-Agent and Accept-Languag= e request header fields
often convey specific information about the clie= nt version or locale.
This facilitates content negotiation and operation= al work-arounds for
implementation bugs. Request header fields that cont= rol caching
can expose state information about a subset of the client= 9;s
history. Mixing DoH requests with other HTTP requests on the sameconnection also provides an opportunity for richer data correlation.
The DoH protocol design allows applications to fully leverage all the
= features of the HTTP ecosystem, including features not enumerated
here. = Implementations of DoH clients and servers need to consider the
benefit = and privacy impact of these features, and their deployment
context, when= deciding whether or not to enable them. Implementations
should expose t= he minimal set of data needed to achieve the desired
feature set.

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--0000000000002d1611056f2b7a54-- From nobody Thu Jun 21 12:10:54 2018 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 B8773130DED for ; Thu, 21 Jun 2018 12:10:43 -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 kThsGtMjuX8j for ; Thu, 21 Jun 2018 12:10:40 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB771310F9 for ; Thu, 21 Jun 2018 12:10:40 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 21 Jun 2018 12:10:38 -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; Thu, 21 Jun 2018 12:10:38 -0700 From: Paul Hoffman To: Eric Rescorla CC: DoH WG Thread-Topic: [Ext] [Doh] Privacy Considerations Text (#2) Thread-Index: AQHUCZOJCbwr0INJiUa4CcuCb1e7uA== Date: Thu, 21 Jun 2018 19:10:37 +0000 Message-ID: <7562C742-6D47-4C56-8DAF-6C34F0B32D67@icann.org> References: In-Reply-To: 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: <9EB4B6FF345925449CADBE4844201CD8@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:10:53 -0000 On Jun 21, 2018, at 11:56 AM, Eric Rescorla wrote: >=20 > Can you please enable comments on the PR so that people can provide detai= led feedback We had them on earlier, and there was a request to turn them off and have a= ll the comments here on the list. Can you provided detailed feedback on the= full text Patrick included in his message? --Paul Hoffman= From nobody Thu Jun 21 12:17:05 2018 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 7F551130DE0 for ; Thu, 21 Jun 2018 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 dqIeo7ALoDom for ; Thu, 21 Jun 2018 12:17:00 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id A6306130DCD for ; Thu, 21 Jun 2018 12:17:00 -0700 (PDT) Received: from mail-ot0-f174.google.com (mail-ot0-f174.google.com [74.125.82.174]) by linode64.ducksong.com (Postfix) with ESMTPSA id B09013A068 for ; Thu, 21 Jun 2018 15:16:59 -0400 (EDT) Received: by mail-ot0-f174.google.com with SMTP id 92-v6so4817689otw.9 for ; Thu, 21 Jun 2018 12:16:59 -0700 (PDT) X-Gm-Message-State: APt69E39sWLONtSHA7AFa6wfvPfNF3OHvqChsygiboU/n/APa2eNz1SP 1M8OjLCvppGTHNNO5mmcGueRtNkSFtv0oQABa1g= X-Google-Smtp-Source: ADUXVKIa+zkl0JIFQx5rDH7MYY3rdPDmKUtDXrEnNdPIubMR527C9Zy4NERilNT/RWlk95uKl5Oxmgw9u8HnhyRf3Uc= X-Received: by 2002:a9d:2c41:: with SMTP id f59-v6mr15503781otb.263.1529608619425; Thu, 21 Jun 2018 12:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 12:16:58 -0700 (PDT) In-Reply-To: <7562C742-6D47-4C56-8DAF-6C34F0B32D67@icann.org> References: <7562C742-6D47-4C56-8DAF-6C34F0B32D67@icann.org> From: Patrick McManus Date: Thu, 21 Jun 2018 15:16:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: Eric Rescorla , DoH WG Content-Type: multipart/alternative; boundary="0000000000006804ff056f2bc286" Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:17:03 -0000 --0000000000006804ff056f2bc286 Content-Type: text/plain; charset="UTF-8" hi - I'm pretty sure ekr is referring to a sidebar suggestion he made to me that would strengthen the cookie specific text (as these are the primary and, most concerning, flexible state tracking mechanism in http). Its a good suggestion - stay tuned and I'll write it up. On Thu, Jun 21, 2018 at 3:10 PM, Paul Hoffman wrote: > On Jun 21, 2018, at 11:56 AM, Eric Rescorla wrote: > > > > Can you please enable comments on the PR so that people can provide > detailed feedback > > We had them on earlier, and there was a request to turn them off and have > all the comments here on the list. Can you provided detailed feedback on > the full text Patrick included in his message? > > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000006804ff056f2bc286 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi - I'm pretty sure ekr is referring to a sidebar sug= gestion he made to me that would strengthen the cookie specific text (as th= ese are the primary and, most concerning, flexible state tracking mechanism= in http). Its a good suggestion - stay tuned and I'll write it up.
=

On Thu, Jun= 21, 2018 at 3:10 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Jun 21, 2= 018, at 11:56 AM, Eric Rescorla <ekr@rtf= m.com> wrote:
>
> Can you please enable comments on the PR so that people can provide de= tailed feedback

We had them on earlier, and there was a request to turn them off and= have all the comments here on the list. Can you provided detailed feedback= on the full text Patrick included in his message?

--Paul Hoffman
_____________________= __________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--0000000000006804ff056f2bc286-- From nobody Thu Jun 21 12:39:25 2018 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 5EB9D130EC5 for ; Thu, 21 Jun 2018 12:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 nETTrwh38K0e for ; Thu, 21 Jun 2018 12:39:21 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 B7E88130DFA for ; Thu, 21 Jun 2018 12:39:21 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u124-v6so1587216ywg.0 for ; Thu, 21 Jun 2018 12:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MTjw1GtUekkDpR7b3vgvdcTemfcImgoGstuboRYOztM=; b=wezQ9n3S+zBkeMcpkomd/T8eqvgl4YEB+FoZEtEYKwEEBOnxpjQtY4idb680zmeuAP njfWmcWT6BVWvW0FVT/I/YhOyVspzDnwFNZYY4YlMvHWfb1Zx92XtZCElHeB/ddjS+jO hWumhVBWRJajNi7MbIIm/1OVxOqHDGJXWGPED00jC44kT9kLqCy51Yo360GHNG0jV/rn Fx/YZGumonx+yxwiYiBFpfY8aadX/YKDWKttQ7D3ATiV9+2D60RcZOu/ka1GNiKUNBk+ /tVR+MtJnhFQ34AtwM7FlwofbemwAVjUwDeGKlNOI+fF+duJAWxnuFuxqrIepuSeUNcS XBPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MTjw1GtUekkDpR7b3vgvdcTemfcImgoGstuboRYOztM=; b=iRlNa6TWGR4I+aqSJeFSGcPYR7MAK21YSqwd4naZut1p0S7NeupaDJcXKosCNddgsk r5NErQ9KBORoFgyZT0fCNr1Jc4CcfnXFUrPeuKe9c9mzEXuQ5AFk0HrhIIReT1vjDoMy a1tFTXeqgq2RHadvDSIG9k78jkoln35ZT+3+2BbaOSGjYnCi/xVfvUAtkL6ffFa0yqMe qAmOboqRYFfHr4aF89BrT14QRCjeV44Le/tln/V/6VWE7hvjqqWcTLvViYlHBQHix3Cb D0v0ncAb0ipNeaOq4ZQ39V9CGsyNdqhoSrUPZ+wPWI8wfUSEV9dbW9MSTs1Q++5f9Z42 hrZQ== X-Gm-Message-State: APt69E2a3e9R8CL2hiU8EXPNYWFbm2+3p0jk4X/TZSnlg8K1ckn4aPzP SVn+Z56ul3BYEbWJwsuXRAB7JcZQUlchnK8BYxj+ww== X-Google-Smtp-Source: ADUXVKLwEifVwY9KL6pdPotJFWAfwXJ/Qd0XhL310Tqs+50cYH38Egbtzg+ehLfJk9OmEI2nw/3kMFi6xFzKkosyWKE= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr12767171ywf.489.1529609960989; Thu, 21 Jun 2018 12:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 12:38:40 -0700 (PDT) In-Reply-To: <7562C742-6D47-4C56-8DAF-6C34F0B32D67@icann.org> References: <7562C742-6D47-4C56-8DAF-6C34F0B32D67@icann.org> From: Eric Rescorla Date: Thu, 21 Jun 2018 12:38:40 -0700 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000005ec735056f2c1210" Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:39:24 -0000 --0000000000005ec735056f2c1210 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 21, 2018 at 12:10 PM, Paul Hoffman wrote: > On Jun 21, 2018, at 11:56 AM, Eric Rescorla wrote: > > > > Can you please enable comments on the PR so that people can provide > detailed feedback > > We had them on earlier, and there was a request to turn them off and have > all the comments here on the list. Who made that request? That's not how any other group I work with is using Github. Can you provided detailed feedback on the full text Patrick included in his > message? > Not as conveniently as in Github, no -Ekr > --Paul Hoffman --0000000000005ec735056f2c1210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 21, 2018 at 12:10 PM, Paul Hoffman <paul.hoffman@ican= n.org> wrote:
On Jun 21, 2018, at 11:56 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Can you please enable comments on the PR so that people can provide de= tailed feedback

We had them on earlier, and there was a request to turn them off and= have all the comments here on the list.

Wh= o made that request? That's not how any other group I work with is usin= g Github.



Can you provided detailed feedback on the full text Patri= ck included in his message?

Not as conv= eniently as in Github, no

-Ekr


--Paul Hoffman

--0000000000005ec735056f2c1210-- From nobody Thu Jun 21 12:42:57 2018 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 D8AB4130EC5 for ; Thu, 21 Jun 2018 12:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 qtXm4b4DTNmw for ; Thu, 21 Jun 2018 12:42:53 -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 60AD0130DFA for ; Thu, 21 Jun 2018 12:42:53 -0700 (PDT) Received: from Svantevit.local (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 w5LJgneV070289 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Jun 2018 14:42:51 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Howard Chu , Patrick McManus , Ted Hardie Cc: DoH WG References: From: Adam Roach Message-ID: <317567e1-9d3d-4981-e7a5-35c0b6557281@nostrum.com> Date: Thu, 21 Jun 2018 14:42:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:42:55 -0000 On 6/21/18 6:22 AM, Howard Chu wrote: > Adam Roach wrote: >> [as an individual] >> >> I agree with Patrick's analysis here, and think the proposed text >> (plus the "minimal set of data" statement below) is likely to serve >> the purpose well. In particular, I agree with Patrick that the >> various features that have been cited so far each serve a useful >> purpose, and that such purposes may have a place in DoH deployments. >> Giving implementors a heads up about the privacy trade-offs seems >> appropriate. Mandating (MUST or SHOULD) that DoH runs over a minimal >> profile of HTTP seems to remove several of the advantages of using >> HTTP at all. > > That's overstating things. It seems the primary benefit is being able > to hide DoH traffic within standard HTTPS traffic, making it more > difficult to filter out at firewalls. That benefit remains, even if > barebones HTTP requests are used. Note that I didn't say "all" or "most" -- I said "several." If all we wanted was putting DNS requests over connections that are difficult to distinguish from ordinary HTTPS traffic, then we could have informatively described the use of HTTP CONNECT to set up RFC 7858 connections and had a much simpler document. /a From nobody Thu Jun 21 12:51:51 2018 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 AE15B130EE9 for ; Thu, 21 Jun 2018 12:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 JX6ZWlpnKBYi for ; Thu, 21 Jun 2018 12:51:47 -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 9296E130EC5 for ; Thu, 21 Jun 2018 12:51:47 -0700 (PDT) Received: from Svantevit.local (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 w5LJpjrP071702 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Jun 2018 14:51:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Ted Hardie , Patrick McManus Cc: Howard Chu , DoH WG References: From: Adam Roach Message-ID: <53813713-9179-d91c-7b9a-01d32ede0e11@nostrum.com> Date: Thu, 21 Jun 2018 14:51:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:51:49 -0000 On 6/21/18 12:43 PM, Ted Hardie wrote: > There is more than one HTTP ecosystem, and forcing some use cases to > behave as if they are using it differently does not make sense.  A > DOH-only request stream does not need to send information on > accept-language; why would it do so? Under the proposed guidance ("In making this evaluation DoH clients should use the minimal set of data (e.g.  headers, cookies) that can achieve the desired feature set"), it would not do so. /a From nobody Thu Jun 21 13:07:29 2018 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 55EB012872C for ; Thu, 21 Jun 2018 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.28 X-Spam-Level: ** X-Spam-Status: No, score=2.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 z42GOovn3ZY4 for ; Thu, 21 Jun 2018 13:07:26 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0556612777C for ; Thu, 21 Jun 2018 13:07:25 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 858791A04EC for ; Thu, 21 Jun 2018 13:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529611645; bh=b06eivEksDsvcZt8eXYNXBxHINrr8NYYPSJBAtoWAXI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=P6fHzmP+SuXNPwUOp8kFKfL8UXUWsI9Po/PUe7Jrzb2br6CmUGcCcVO0oZcT98fW/ o1s3mkFVyyDw0yp7GlO3Mdknikjr/+GwFMLLKBCtNDIeHQ+6DEiBkWkNNMUueHgDWC C/RVQ1vsdPfa2CwL3cLAgTRiCdAk2R75vD64JLp8= X-Riseup-User-ID: AC340BA3704AB9C4B28BF9B6971A56BAC5441FFE9604CB3A6AB4AA0887B2BFB6 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 8EFFDC7D8A for ; Thu, 21 Jun 2018 13:07:24 -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: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> Date: Thu, 21 Jun 2018 20:07:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tKlbXXAodXVgO6bHGvuotZyAcaYlr62gq" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 20:07:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tKlbXXAodXVgO6bHGvuotZyAcaYlr62gq Content-Type: multipart/mixed; boundary="sqfeBsCxweNYajwlbjtnaf9aqS2SKPSes"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> Subject: Re: [Doh] Privacy Considerations Text (#2) References: In-Reply-To: --sqfeBsCxweNYajwlbjtnaf9aqS2SKPSes Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Patrick McManus wrote: > We may be getting close to bridging the important points here - so we'v= e > made an update to the PR. (its still not merged into the working copy, = but > it has changed). and we can iterate from there. Thank you for the comme= nts, > and especially text proposals - they really help. Is this iteration supposed to address or include previous comments from [= 1]? I don't see [1] addressed. Specifically it does not _explicitly_ convey that=20 "DoH introduces new privacy concerns". I propse to change: > The privacy considerations of using the HTTPS layer in DoH are > incremental to those of DNS over TLS. to be more explicit about it: "DoH introduces new privacy concerns=20 when compared with DNS over UDP, TCP or TLS (RFC7858)." (this sentence - and more - has been proposed in [1] before by others) > The privacy considerations of using the HTTPS layer in DoH are > incremental to those of DNS over TLS. DoH is not known to introduce > new concerns beyond those associated with HTTPS. Actually I think it does because it combines two protocols (DNS + HTTPS) = that haven't been combined before and DNS+HTTPS has more privacy implications than just the= sum of IP, TCP, TLS and HTTP when DoH server are not used exclusively for DoH. Sara wrote [1]: > [...] [DoH] introduces new privacy concerns when compared > with DNS over UDP, TCP or TLS (RFC7858). The rationale for this decisio= n is that=20 > retaining the ability to leverage the full functionality of the HTTP ec= osystem is more > important than placing any constraints on this new protocol based on pr= ivacy considerations." Also the rationale behind the design decision is important. [1] https://mailarchive.ietf.org/arch/msg/doh/_ju-J52e5cf7UNpgwhCbq5pln5Y= =20 --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --sqfeBsCxweNYajwlbjtnaf9aqS2SKPSes-- --tKlbXXAodXVgO6bHGvuotZyAcaYlr62gq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlssBXUACgkQrWE4wkXN Qn4c1w//UL/f+lZhNSGYfkShC6zyxQvqwV66kwZvIl+OZnnFMjFrRnDd4J9T3vhI piK7sP1W4mICFadGDgTonlfBfOC8yvj4X4KWnUqDK6m1yhEsDZgfBTmnjMK7m7Yt WMv2v9gP1dwaypin9npJurNtvguX7mhtfjJA5vEHGQh2TP1JEBfL1kV6Mc+xYCiD sntVA+d55MJQdMKwpQiGTlzBbn1sQ0t6IlzVe4E0Jpwutdfdmhndqc2SiZqO3YWA qPUAlVnHIaOeLYihPeSJKYkZSPZsstznwPiVlJH2jtuni1ARhGe5lOJTD57Hmky4 Zf5B5KfrAm5w7L9xIzsnTPxW3FWV5zYL+N++QJoS+r1/R/SBKKkhKnC00NtRPjV8 lGlu8Fbgq5PPY5uVpDfkwR10vaBUEuGr4wnYDyqD9JgULAqfiiSk91qhaoV+PQVS RSTJLHegO3hbIxVc6Dsnvtsd3Daj+NNfW+I/RKJTVSJMPN7hyuMVyleUJOFbP2ni ZKrtxalE+cGXuFDa0PllXHkzTn0ORe9ETsUIX8ArsTkGSTw6iMNyQG9YizMHPQt0 0R4ObQa+EaKVnytJEpx9BeRnB0PIk74MljSg17oJgQC/BofmDeCGfwU9d9kv+/Yc HYnGbuA0M/5QGUJDi5TEpf6o8jhtelGrboE85XUt3pirHm+lpZQ= =lvap -----END PGP SIGNATURE----- --tKlbXXAodXVgO6bHGvuotZyAcaYlr62gq-- From nobody Thu Jun 21 13:57:30 2018 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 8D9A71294D0 for ; Thu, 21 Jun 2018 13:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 Qvr9J-Kl_XnB for ; Thu, 21 Jun 2018 13:57:26 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id BE95912785F for ; Thu, 21 Jun 2018 13:57:26 -0700 (PDT) Received: from mail-ot0-f180.google.com (mail-ot0-f180.google.com [74.125.82.180]) by linode64.ducksong.com (Postfix) with ESMTPSA id 75CB83A068 for ; Thu, 21 Jun 2018 16:57:25 -0400 (EDT) Received: by mail-ot0-f180.google.com with SMTP id 92-v6so5125008otw.9 for ; Thu, 21 Jun 2018 13:57:25 -0700 (PDT) X-Gm-Message-State: APt69E0cpOQgwN59mPTBysEvxU420JpSECnMi0h/J1/v5p8Inc+qzGpg xJvK3fZR3s80sEvzJpBrIXDeN3TK0/66o7/rufc= X-Google-Smtp-Source: ADUXVKJIn9JgsYeL5TKs9Or65pSI/sZ/nPvh+sCOfJL7huic9GqXILjif5tIRHaE43xwD4imlZlk7ifz8u3BqyzFL/w= X-Received: by 2002:a9d:513b:: with SMTP id c56-v6mr15646278oth.397.1529614645176; Thu, 21 Jun 2018 13:57:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Thu, 21 Jun 2018 13:57:24 -0700 (PDT) In-Reply-To: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> From: Patrick McManus Date: Thu, 21 Jun 2018 16:57:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: nusenu Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000091b3ce056f2d29fe" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 20:57:29 -0000 --00000000000091b3ce056f2d29fe Content-Type: text/plain; charset="UTF-8" On Thu, Jun 21, 2018 at 4:07 PM, nusenu wrote: > > Is this iteration supposed to address or include previous comments from > [1]? > I don't see [1] addressed. > > I believe it addresses where we are converging related to those comments and others. The text includes, among other things, the notion that HTTPS is an incremental consideration to TLS and that the HTTPS considerations deal with a large number of features because DoH design allows leveraging of the full HTTP ecosystem. --00000000000091b3ce056f2d29fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 21, 2018 at 4:07 PM, nusenu <nusenu-lists@riseup.net>= wrote:

Is this iteration supposed to address or include previous comments f= rom [1]?
I don't see [1] addressed.


I believe it addresses where we are co= nverging related to those comments and others. The text includes, among oth= er things, the notion that HTTPS is an incremental consideration to TLS and= that the HTTPS considerations deal with a large number of features because= DoH design allows leveraging of the full HTTP ecosystem.

--00000000000091b3ce056f2d29fe-- From nobody Fri Jun 22 08:34:13 2018 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 2F3C5130E9C for ; Fri, 22 Jun 2018 08:34:11 -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, FREEMAIL_FROM=0.001, 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 JekVkd2pTnNE for ; Fri, 22 Jun 2018 08:34:08 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 16041130E96 for ; Fri, 22 Jun 2018 08:34:07 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 26943 invoked from network); 22 Jun 2018 17:34:03 +0200 Received: from agkp106.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.143.106]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 22 Jun 2018 17:34:03 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus , DoH WG References: Openpgp: preference=signencrypt Autocrypt: addr=mat.jonczyk@o2.pl; prefer-encrypt=mutual; keydata= xsFNBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/qDoPh52f ExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkxJww5X/2ZAtFjUJxO QjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOadTy5hvwv0rjNjohau1y4XfxU DdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSEAhs2rOTN6pnWJVd7ErauehrET2xo2JbO 4lAv0nbXmCpPj37ZvURswCeP8PcHoA1QQKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzg jxSYVZRAWVsdNakfT7xhkaeHjEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7yln DRrda+1EVObfszfBWm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnS RP/s9t+C8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaGDhVeLUVF Q+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQABzSRNYXRldXN6IEpv xYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD7CwX4EEwECACgFAlqMDyQCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhhCv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI 1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsUUAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52 hZxMsCQyzjGOcBAi0zmWGYB4xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU 9bzFCyqZ8kAqwOoCCx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3 ADg8sGuq4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbydWVke0FSR AzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFjGdeeggv668M7GmKl +SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXCVEwW4q17v8gNsPyVUVEdIroK cve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOWmyzCLQ1YoUZMxH+ddivDQtlKCp6JgGCz c9YCESxVii0vo8TsHdIAjQ/px9KsuYBmOlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7I U16IAtK5b7RpzsFNBFqMDyQBEACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+p Bw5/D2ruHhj1Bgs6Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01 ltYrMYV1IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv830ZCQ5Ds U0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2ISO0OAAMBKea7slr mu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJFyiZ0vYAUTwtITyjYxZWJbKJh JFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S4 16W9lBDJeHhmcVOsn+04x5KIxHtqAP3mkMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXf kgWJtW+JziZf6LYx4WvRa80VDIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9Sm kfTFrHOgiTpwZnI9saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABwsFl BBgBAgAPBQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbljJusw6xQ iKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbHb1GJtLF5HyI1q4j/ zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9mmDLEwO4ULK2quF6RYtbvg+2 PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dEjTx+uYCWpvcw3rRDz7aMs401CphrlMKr WndS5qYcdiS9fvAfu/Jp5KIawpM0tVrojnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y 6LHzJWsnLnL1o7MUARU++ztOl2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuw gF7DbkdscM7fkYzkUVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X2 0nI2LedLnIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fww8Ihl8aS TANkZ3QqXNX2 Message-ID: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> Date: Fri, 22 Jun 2018 17:34:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="np1BlYHHAND6cjt37GgaWZVA1hhaX19oV" X-WP-MailID: 853fa8a80d81dc22782052c0d8bba6f1 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [ERN2] Archived-At: Subject: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:34:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --np1BlYHHAND6cjt37GgaWZVA1hhaX19oV Content-Type: multipart/mixed; boundary="osrgaPvKy3a31fbgCLfyyNjm0CH0OXz7v"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus , DoH WG Message-ID: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> Subject: [Doh] Privacy Considerations Text (#2) References: In-Reply-To: --osrgaPvKy3a31fbgCLfyyNjm0CH0OXz7v Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 21.06.2018 o=C2=A020:43, Patrick McManus pisze: > ## In The Server {#InTheServer} > > A DoH application is built on IP, TCP, TLS, and HTTP. Each layer > contains one or more common features that can be used to correlate > different queries to the same identity. DNS transports will generally > carry the same privacy properties of the layers used to implement > them. For example, the properties of IP, TCP, and TLS apply to DNS > over TLS implementations. The sentence above is misleading. We are talking about DOH, not DNS over = TLS. >=20 > The privacy considerations of using the HTTPS layer in DoH are > incremental to those of DNS over TLS. DoH is not known to introduce > new concerns beyond those associated with HTTPS. I have been thinking that a DoH client would open a long-running connecti= on to a DoH server. In such a case, request correlation could be simple and we sh= ould drop the "is not known to introduce new concerns" sentence. >=20 > At the IP level, the client address provides obvious correlation > information. This can be mitigated by use of a NAT, proxy, VPN, or > simple address rotation over time. It may be aggravated by use of a > DNS server that can correlate real-time addressing information with > other personal identifiers, such as when a DNS server and DHCP server > are operated by the same entity. >=20 > TCP-based solutions may seek performance through the use of TCP Fast > Open {{RFC7413}}..=20 Double dot here. > The cookies used in TCP Fast Open allow servers to > correlate different TCP sessions together. >=20 > TLS based implementations often achieve better handshake performance > through the use of some form of session resumption mechanism such as > session tickets {{RFC5077}}. Session resumption creates trivial > mechanisms for a server to correlate different TLS connections > together. >=20 > HTTP's feature set can also be used for identification and tracking in > a number of different ways. For example, authentication request header > fields explicitly identify profiles in use, and HTTP Cookies are > designed as an explicit state tracking mechanism between the client > and serving site and often are used as an authentication mechanism. "and server" would be better. > > [...] > > The DoH protocol design allows applications to fully leverage all the > features of the HTTP ecosystem, including features not enumerated > here. Implementations of DoH clients and servers need to consider the > benefit and privacy impact of these features, and their deployment > context, when deciding whether or not to enable them. Implementations > should expose the minimal set of data needed to achieve the desired > feature set. It would be IMHO better to write "Implementations are advised to expose t= he minimal set of data..." to avoid the use of the word "should" (as this is= not a RFC2119 SHOULD and IMHO shouldn't be, as I explained previously on the li= st [1]). Greetings, Mateusz Jo=C5=84czyk [1] https://www.ietf.org/mail-archive/web/doh/current/msg00819.html --osrgaPvKy3a31fbgCLfyyNjm0CH0OXz7v-- --np1BlYHHAND6cjt37GgaWZVA1hhaX19oV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEVwj0eFevwwaT4Zqs+9ZauGEK/sYFAlstFuoACgkQ+9ZauGEK /sbjsQ/+NtaPQ5GjgLbRttcx1/wtL2REFZwp1OhuU113ftDjhp0+MZEIbCC+5wHG 2E4sg//ydjUzDCznmSOSH1+qBjqqRP1y6ZcvFb3k6gZ5KFg0SeFTNGlQhqP6/vCm v1sMtBGYaaz/qZEo4irrRi8R15ZOmaZQR9XiPp9CLbgDhVdiQ96w2K1jYkGqHeeS U5E1UcyvRpkF7YUaVTl1FOoM+ccZKEOZX+Djf10zwizMtsDYq979nFi/x+18TUoF dqoy6Bi09I6OHdoZBBrLtniVOS8984DRfgIWLXoEfSUgzdpXNgv+YrHsHrB1fJAS zAiNe3u0PLde7A0AVYi/uyiQ1VM3aBDsJy/7lnjoV5kFWBCuRTqgKInFOmDdd2Q7 jCa/oXAfwZz1cXqd//WCt6NAJblmsNzbLrHCcL17h04/N4FcZcwEkb128Wvh3bed JBRtd5r34SKQNgjztTj+bL5dy96MaLiLdRb8CB0vKeSn88FE/EGVouu4Z7d7ZMYe dwfrKujmLay32pHjVKM2AX9e8Y1Vy0wjcXxD+f0++2M2Oh0HlwET9K+dUCLt8lVj 5zwevsWQdZwAQiLrezdEWYUcmjMGipYSN9AXS0IegudPaP7yBw2+WR9uuRHXPd2W OotVlLi5CW1b15uVdexM82bLJe3/Pyusnrkgrt/G2Ipnj05U4TQ= =1cfy -----END PGP SIGNATURE----- --np1BlYHHAND6cjt37GgaWZVA1hhaX19oV-- From nobody Fri Jun 22 08:42:57 2018 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 76D27130EA2 for ; Fri, 22 Jun 2018 08:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 DWKX-KW_tkMT for ; Fri, 22 Jun 2018 08:42:54 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 9D3DD130E96 for ; Fri, 22 Jun 2018 08:42:54 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 22 Jun 2018 08:42:52 -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; Fri, 22 Jun 2018 08:42:52 -0700 From: Paul Hoffman To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= CC: DoH WG Thread-Topic: [Ext] [Doh] Privacy Considerations Text (#2) Thread-Index: AQHUCY+5ux5TGUEI5UeHbfdotxktpaRs3x0AgAACd4A= Date: Fri, 22 Jun 2018 15:42:52 +0000 Message-ID: <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> In-Reply-To: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_D10458BF-7596-4BF7-9C25-0D1D42DC16FC"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:42:56 -0000 --Apple-Mail=_D10458BF-7596-4BF7-9C25-0D1D42DC16FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 22, 2018, at 8:34 AM, Mateusz Jo=C5=84czyk = wrote: >=20 > Signed PGP part > W dniu 21.06.2018 o 20:43, Patrick McManus pisze: >> ## In The Server {#InTheServer} >>=20 >> A DoH application is built on IP, TCP, TLS, and HTTP. Each layer >> contains one or more common features that can be used to correlate >> different queries to the same identity. DNS transports will generally >> carry the same privacy properties of the layers used to implement >> them. For example, the properties of IP, TCP, and TLS apply to DNS >> over TLS implementations. >=20 > The sentence above is misleading. We are talking about DOH, not DNS = over TLS. Earlier, the WG wanted the document to compare (where appropriate) DoH = and DoT. It seems appropriate to do so in the privacy considerations to = show that DoH has one more layer that can make user tracking more = possible. >>=20 >> The privacy considerations of using the HTTPS layer in DoH are >> incremental to those of DNS over TLS. DoH is not known to introduce >> new concerns beyond those associated with HTTPS. >=20 > I have been thinking that a DoH client would open a long-running = connection to a > DoH server. In such a case, request correlation could be simple and we = should > drop the "is not known to introduce new concerns" sentence. Both RFC 7766 (DNS in TCP) and RFC 7858 (DNS in TLS) recommend opening = long-running connections, and explain the operational pros and cons of = doing so. >> At the IP level, the client address provides obvious correlation >> information. This can be mitigated by use of a NAT, proxy, VPN, or >> simple address rotation over time. It may be aggravated by use of a >> DNS server that can correlate real-time addressing information with >> other personal identifiers, such as when a DNS server and DHCP server >> are operated by the same entity. >>=20 >> TCP-based solutions may seek performance through the use of TCP Fast >> Open {{RFC7413}}.. >=20 > Double dot here. Thanks; fixed in editor's copy. >=20 >> The cookies used in TCP Fast Open allow servers to >> correlate different TCP sessions together. >>=20 >> TLS based implementations often achieve better handshake performance >> through the use of some form of session resumption mechanism such as >> session tickets {{RFC5077}}. Session resumption creates trivial >> mechanisms for a server to correlate different TLS connections >> together. >>=20 >> HTTP's feature set can also be used for identification and tracking = in >> a number of different ways. For example, authentication request = header >> fields explicitly identify profiles in use, and HTTP Cookies are >> designed as an explicit state tracking mechanism between the client >> and serving site and often are used as an authentication mechanism. >=20 > "and server" would be better. Agree; fixed in editor's copy. >=20 >>=20 >> [...] >>=20 >> The DoH protocol design allows applications to fully leverage all the >> features of the HTTP ecosystem, including features not enumerated >> here. Implementations of DoH clients and servers need to consider the >> benefit and privacy impact of these features, and their deployment >> context, when deciding whether or not to enable them. Implementations >> should expose the minimal set of data needed to achieve the desired >> feature set. >=20 > It would be IMHO better to write "Implementations are advised to = expose the > minimal set of data..." to avoid the use of the word "should" (as this = is not a > RFC2119 SHOULD and IMHO shouldn't be, as I explained previously on the = list [1]). Will do. --Paul Hoffman --Apple-Mail=_D10458BF-7596-4BF7-9C25-0D1D42DC16FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAlstGPsACgkQsZnCoeEP RXveMAgAlO1UrYIZXLNdZH4cWIn2ixQyY/O1fw/h6/JaElKjssMPcqTvFWrooC8W WS0yNw/2vGUthmZ678LHYLkFilvldTZ3IpNEuCJK0be0NeRTUmn2xhR8WTdHd0Sj d8LOyvS4sXZpj4aoxNOkpTBjLEB5IECDplbWlxfE0Iai2ldY5nai2wF1TtWCO0Zk fP7nJGMV3PEYlMK35avhY9mQPmGC9CQYqR54p3XbTqEqqDbJ8w+P4QmgOmAZZa7K dEPXpUK6w5lsTZQvmV2jIlep7Qb0VHK00Z8T7A3o9KqgOUbwFM6QRi7Qgr+HSKPA R+1xrVWbRqwEaWp4SCygHM2zch3HNg== =tbXI -----END PGP SIGNATURE----- --Apple-Mail=_D10458BF-7596-4BF7-9C25-0D1D42DC16FC-- From nobody Fri Jun 22 08:58:19 2018 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 2CABE130EE1 for ; Fri, 22 Jun 2018 08:58:06 -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, FREEMAIL_FROM=0.001, 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 KSfEb-tZ2DJm for ; Fri, 22 Jun 2018 08:58:02 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 398C6130ED9 for ; Fri, 22 Jun 2018 08:58:02 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 15372 invoked from network); 22 Jun 2018 17:58:00 +0200 Received: from agkp106.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.143.106]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 22 Jun 2018 17:58:00 +0200 To: Paul Hoffman Cc: DoH WG References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Autocrypt: addr=mat.jonczyk@o2.pl; prefer-encrypt=mutual; keydata= xsFNBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/qDoPh52f ExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkxJww5X/2ZAtFjUJxO QjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOadTy5hvwv0rjNjohau1y4XfxU DdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSEAhs2rOTN6pnWJVd7ErauehrET2xo2JbO 4lAv0nbXmCpPj37ZvURswCeP8PcHoA1QQKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzg jxSYVZRAWVsdNakfT7xhkaeHjEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7yln DRrda+1EVObfszfBWm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnS RP/s9t+C8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaGDhVeLUVF Q+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQABzSRNYXRldXN6IEpv xYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD7CwX4EEwECACgFAlqMDyQCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhhCv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI 1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsUUAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52 hZxMsCQyzjGOcBAi0zmWGYB4xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU 9bzFCyqZ8kAqwOoCCx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3 ADg8sGuq4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbydWVke0FSR AzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFjGdeeggv668M7GmKl +SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXCVEwW4q17v8gNsPyVUVEdIroK cve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOWmyzCLQ1YoUZMxH+ddivDQtlKCp6JgGCz c9YCESxVii0vo8TsHdIAjQ/px9KsuYBmOlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7I U16IAtK5b7RpzsFNBFqMDyQBEACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+p Bw5/D2ruHhj1Bgs6Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01 ltYrMYV1IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv830ZCQ5Ds U0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2ISO0OAAMBKea7slr mu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJFyiZ0vYAUTwtITyjYxZWJbKJh JFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S4 16W9lBDJeHhmcVOsn+04x5KIxHtqAP3mkMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXf kgWJtW+JziZf6LYx4WvRa80VDIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9Sm kfTFrHOgiTpwZnI9saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABwsFl BBgBAgAPBQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbljJusw6xQ iKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbHb1GJtLF5HyI1q4j/ zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9mmDLEwO4ULK2quF6RYtbvg+2 PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dEjTx+uYCWpvcw3rRDz7aMs401CphrlMKr WndS5qYcdiS9fvAfu/Jp5KIawpM0tVrojnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y 6LHzJWsnLnL1o7MUARU++ztOl2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuw gF7DbkdscM7fkYzkUVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X2 0nI2LedLnIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fww8Ihl8aS TANkZ3QqXNX2 Message-ID: <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> Date: Fri, 22 Jun 2018 17:57:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s6qy70zuu9XEjVbxV9y3gemeVILVwLtwX" X-WP-MailID: 82ffd9b6fa2366ee6bbbc24eb1347a31 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [8ZP0] Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:58:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s6qy70zuu9XEjVbxV9y3gemeVILVwLtwX Content-Type: multipart/mixed; boundary="4iI1YvojIapZnUvkWwiXMxUmpEKb0AE1t"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Paul Hoffman Cc: DoH WG Message-ID: <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> Subject: Re: [Ext] [Doh] Privacy Considerations Text (#2) References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> In-Reply-To: <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> --4iI1YvojIapZnUvkWwiXMxUmpEKb0AE1t Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 22.06.2018 o=C2=A017:42, Paul Hoffman pisze: > On Jun 22, 2018, at 8:34 AM, Mateusz Jo=C5=84czyk w= rote: >> W dniu 21.06.2018 o 20:43, Patrick McManus pisze: >>> ## In The Server {#InTheServer} >>> >>> A DoH application is built on IP, TCP, TLS, and HTTP. Each layer >>> contains one or more common features that can be used to correlate >>> different queries to the same identity. DNS transports will generally= >>> carry the same privacy properties of the layers used to implement >>> them. For example, the properties of IP, TCP, and TLS apply to DNS >>> over TLS implementations. >> >> The sentence above is misleading. We are talking about DOH, not DNS ov= er TLS. >=20 > Earlier, the WG wanted the document to compare (where appropriate) DoH = and DoT.=20 > It seems appropriate to do so in the privacy considerations to show tha= t DoH > has one more layer that can make user tracking more possible. >=20 OK >>> >>> The privacy considerations of using the HTTPS layer in DoH are >>> incremental to those of DNS over TLS. DoH is not known to introduce >>> new concerns beyond those associated with HTTPS. >> >> I have been thinking that a DoH client would open a long-running conne= ction to a >> DoH server. In such a case, request correlation could be simple and we= should >> drop the "is not known to introduce new concerns" sentence. >=20 > Both RFC 7766 (DNS in TCP) and RFC 7858 (DNS in TLS) recommend opening = long-running connections, and explain the operational pros and cons of do= ing so. >=20 OK, now I have read that passage again and understand it. I would argue that this should be discussed explicitly in the "Privacy considerations" section. Greetings, Mateusz Jo=C5=84czyk --4iI1YvojIapZnUvkWwiXMxUmpEKb0AE1t-- --s6qy70zuu9XEjVbxV9y3gemeVILVwLtwX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEVwj0eFevwwaT4Zqs+9ZauGEK/sYFAlstHHsACgkQ+9ZauGEK /sbimg//bGlqtbMgiK4fq01/fEbnSIeBmPy1BWA8MEBB0afNM+Y3ZU+OCM0ueKoO 3GrWubnv+YR/+0hpkJ+mdOsZkRrIO3oKOch7hGINvIXOYk3MjSpFznHKxeFXClsv wu+k/I3xr2niJsu3yu34+EYOTaDxoMnVwdoA4iwh4v5glctrn91rx5yIl7BnM15P fBW2llMs/3QNLaQy9GObhZU828gM3pKC9J3SXWZyIuXE1aeFqRgiCWMFVUReZ+PZ qzK63SxqUqy4VX4+tlckZBIUwtfuyt0NsroEQ4k+Z3/9nt5+dOHE7KrjU5yx39iT n+INQ9oXM3TabXZzWHusNV0lN7qWFNw2+RjH+V3HhRBOBHXJk9qoSAY8CbCrM8Hi M/5CiFfaD5k0bQcCbZb1CXengU0kZRNnZuUGo+XXjiJHtCtbJB2ITwxUKH6dTHCn 3mU2IlcYMQ5KMZYV5N4l4VT4pA6cGd8cdQG0iQtQAQJN5k1oVIhRfw8omPvTafbL kgGPnbbr82bNv67BPVXTfW48HFljcb8PQ1a8iTy2Cpk5CNctyPXfjMAchrvBFmjY qlQzW38aOE2PUw6jx7AYlOp5Yeb+Jiei1LyLKU3Sy8IUx3kPypEoA7mgl2VGCzCk YnWVBbyeg6GelmOEVfsIPaZWwyOv7XiDHLfvTesi1jKyHyPfqa4= =V/Dd -----END PGP SIGNATURE----- --s6qy70zuu9XEjVbxV9y3gemeVILVwLtwX-- From nobody Fri Jun 22 09:08:13 2018 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 A111C130EA6 for ; Fri, 22 Jun 2018 09:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 eAzfoHfPSW9f for ; Fri, 22 Jun 2018 09:08:09 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id E81BC130EA2 for ; Fri, 22 Jun 2018 09:08:08 -0700 (PDT) Received: from mail-ot0-f181.google.com (mail-ot0-f181.google.com [74.125.82.181]) by linode64.ducksong.com (Postfix) with ESMTPSA id 13E333A06C for ; Fri, 22 Jun 2018 12:08:08 -0400 (EDT) Received: by mail-ot0-f181.google.com with SMTP id c15-v6so8073995otl.3 for ; Fri, 22 Jun 2018 09:08:08 -0700 (PDT) X-Gm-Message-State: APt69E0r83PybIUqFjyLHx+0V0pivqBBXD1E2qRDulguJ91vTWw5V7gL U7hG5jO6jQasoUQPtOiUpVDUy7RNedHC74PBoHE= X-Google-Smtp-Source: AAOMgpcIVuBq+P0RS+okXcxb+UrR6smWNgD+XhOephs6Qx7KnPL3rqhawYVnwhUPVeya0F1CTZpmkP92SbTzBSgsLbU= X-Received: by 2002:a9d:1bd6:: with SMTP id v22-v6mr1370027otv.85.1529683687726; Fri, 22 Jun 2018 09:08:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 09:08:06 -0700 (PDT) In-Reply-To: <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> From: Patrick McManus Date: Fri, 22 Jun 2018 12:08:06 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= , DoH WG Content-Type: multipart/alternative; boundary="000000000000d362d8056f3d3c5c" Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:08:11 -0000 --000000000000d362d8056f3d3c5c Content-Type: text/plain; charset="UTF-8" On Fri, Jun 22, 2018 at 11:42 AM, Paul Hoffman wrote: > > >> designed as an explicit state tracking mechanism between the client > >> and serving site and often are used as an authentication mechanism. > > > > "and server" would be better. > > Agree; fixed in editor's copy. > > quick note on the scope of an HTTP cookie is actually the site, not the server you are connected to which is why it uses that language. --000000000000d362d8056f3d3c5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 22, 2018 at 11:42 AM, Paul Hoffman <paul.hoffman@ican= n.org> wrote:

>> designed as an explicit state tracking mechanism between the clien= t
>> and serving site and often are used as an authentication mechanism= .
>
> "and server" would be better.

Agree; fixed in editor's copy.


quick note on the scope of an HTTP cookie is actually the site, not = the server you are connected to which is why it uses that language.



--000000000000d362d8056f3d3c5c-- From nobody Fri Jun 22 09:15:42 2018 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 70B4C124C04 for ; Fri, 22 Jun 2018 09:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, 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 bvg6wRFtOk7r for ; Fri, 22 Jun 2018 09:15:36 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 3B3C2130F00 for ; Fri, 22 Jun 2018 09:15:31 -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; Fri, 22 Jun 2018 09:15:29 -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; Fri, 22 Jun 2018 09:15:29 -0700 From: Paul Hoffman To: Patrick McManus CC: =?iso-8859-2?Q?Mateusz_Jo=F1czyk?= , DoH WG Thread-Topic: [Doh] [Ext] Privacy Considerations Text (#2) Thread-Index: AQHUCkM7nM3nVmfptESHLWiVjrb6xqRs6UoA Date: Fri, 22 Jun 2018 16:15:28 +0000 Message-ID: References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> In-Reply-To: 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="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:15:38 -0000 On Jun 22, 2018, at 9:08 AM, Patrick McManus wrote: >=20 >=20 >=20 > On Fri, Jun 22, 2018 at 11:42 AM, Paul Hoffman w= rote: >=20 > >> designed as an explicit state tracking mechanism between the client > >> and serving site and often are used as an authentication mechanism.. > >=20 > > "and server" would be better. >=20 > Agree; fixed in editor's copy. >=20 >=20 > quick note on the scope of an HTTP cookie is actually the site, not the s= erver you are connected to which is why it uses that language. >=20 quick note that having both HTTP and DNS people active in this discussion i= s being amazingly educational for both teams. --Paul Hoffman= From nobody Fri Jun 22 09:26:22 2018 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 E5CC9130EA6 for ; Fri, 22 Jun 2018 09:26:20 -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 ZVfND2vJpBWP for ; Fri, 22 Jun 2018 09:26:19 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005E2130EA2 for ; Fri, 22 Jun 2018 09:26:18 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:53496 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fWOt4-0004d4-Tp (Exim 4.72) for doh@ietf.org (return-path ); Fri, 22 Jun 2018 17:26:15 +0100 To: doh@ietf.org References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> From: Ray Bellis Message-ID: <85363866-2050-606e-27bd-13237d060560@bellis.me.uk> Date: Fri, 22 Jun 2018 17:26:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:26:21 -0000 On 22/06/2018 17:08, Patrick McManus wrote: > quick note on the scope of an HTTP cookie is actually the site, not the > server you are connected to Or any other site that's covered by the same cookie (if it's a dot-prefixed domain cookie) Ray From nobody Sat Jun 23 04:22:59 2018 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 1A5C5130E1C for ; Sat, 23 Jun 2018 04:22:58 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ufTFV0QwLKSu for ; Sat, 23 Jun 2018 04:22:55 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.140]) (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 417B6130E1A for ; Sat, 23 Jun 2018 04:22:55 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 12534 invoked from network); 23 Jun 2018 13:22:51 +0200 Received: from agkp106.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.143.106]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 23 Jun 2018 13:22:51 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Paul Hoffman , DoH WG References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> Openpgp: preference=signencrypt Autocrypt: addr=mat.jonczyk@o2.pl; prefer-encrypt=mutual; keydata= xsFNBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/qDoPh52f ExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkxJww5X/2ZAtFjUJxO QjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOadTy5hvwv0rjNjohau1y4XfxU DdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSEAhs2rOTN6pnWJVd7ErauehrET2xo2JbO 4lAv0nbXmCpPj37ZvURswCeP8PcHoA1QQKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzg jxSYVZRAWVsdNakfT7xhkaeHjEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7yln DRrda+1EVObfszfBWm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnS RP/s9t+C8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaGDhVeLUVF Q+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQABzSRNYXRldXN6IEpv xYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD7CwX4EEwECACgFAlqMDyQCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhhCv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI 1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsUUAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52 hZxMsCQyzjGOcBAi0zmWGYB4xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU 9bzFCyqZ8kAqwOoCCx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3 ADg8sGuq4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbydWVke0FSR AzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFjGdeeggv668M7GmKl +SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXCVEwW4q17v8gNsPyVUVEdIroK cve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOWmyzCLQ1YoUZMxH+ddivDQtlKCp6JgGCz c9YCESxVii0vo8TsHdIAjQ/px9KsuYBmOlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7I U16IAtK5b7RpzsFNBFqMDyQBEACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+p Bw5/D2ruHhj1Bgs6Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01 ltYrMYV1IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv830ZCQ5Ds U0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2ISO0OAAMBKea7slr mu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJFyiZ0vYAUTwtITyjYxZWJbKJh JFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S4 16W9lBDJeHhmcVOsn+04x5KIxHtqAP3mkMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXf kgWJtW+JziZf6LYx4WvRa80VDIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9Sm kfTFrHOgiTpwZnI9saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABwsFl BBgBAgAPBQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbljJusw6xQ iKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbHb1GJtLF5HyI1q4j/ zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9mmDLEwO4ULK2quF6RYtbvg+2 PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dEjTx+uYCWpvcw3rRDz7aMs401CphrlMKr WndS5qYcdiS9fvAfu/Jp5KIawpM0tVrojnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y 6LHzJWsnLnL1o7MUARU++ztOl2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuw gF7DbkdscM7fkYzkUVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X2 0nI2LedLnIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fww8Ihl8aS TANkZ3QqXNX2 Message-ID: Date: Sat, 23 Jun 2018 13:22:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wnZ1FRxkVvcZMClP9DSPmpS3v4xlULUjj" X-WP-MailID: 7f7fa3692818364197b358b14593337f X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000001 [4ZLk] Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 11:22:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wnZ1FRxkVvcZMClP9DSPmpS3v4xlULUjj Content-Type: multipart/mixed; boundary="Fz9xgPHK4eqWQMPvyDddnCEVuKkhfThrt"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Paul Hoffman , DoH WG Message-ID: Subject: Re: [Ext] [Doh] Privacy Considerations Text (#2) References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> In-Reply-To: <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> --Fz9xgPHK4eqWQMPvyDddnCEVuKkhfThrt Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 22.06.2018 o=C2=A017:57, Mateusz Jo=C5=84czyk pisze: > W dniu 22.06.2018 o=C2=A017:42, Paul Hoffman pisze: >> On Jun 22, 2018, at 8:34 AM, Mateusz Jo=C5=84czyk = wrote: >>> W dniu 21.06.2018 o 20:43, Patrick McManus pisze: >>>> >>>> The privacy considerations of using the HTTPS layer in DoH are >>>> incremental to those of DNS over TLS. DoH is not known to introduce >>>> new concerns beyond those associated with HTTPS. >>> >>> I have been thinking that a DoH client would open a long-running conn= ection to a >>> DoH server. In such a case, request correlation could be simple and w= e should >>> drop the "is not known to introduce new concerns" sentence. >> >> Both RFC 7766 (DNS in TCP) and RFC 7858 (DNS in TLS) recommend opening= long-running connections, and explain the operational pros and cons of d= oing so. >> >=20 > OK, now I have read that passage again and understand it. > I would argue that this should be discussed explicitly in the "Privacy > considerations" section. >=20 I would propose to add the following text: Because of performance reasons, DOH clients are advised to open long-running connections to the DOH server. However, in such a case the server is able to correlate all the requests within a connection. Therefore it is advisable for DOH clients to close and reopen the connection to the DOH server e.g. every hour or when outside IP address changes - to make request correlation more difficult. I am happy to live in the EU. AFAIK our law makes doing such request correllation for tracking purposes illegal in most cases. Greetings, Mateusz Jo=C5=84czyk --Fz9xgPHK4eqWQMPvyDddnCEVuKkhfThrt-- --wnZ1FRxkVvcZMClP9DSPmpS3v4xlULUjj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEVwj0eFevwwaT4Zqs+9ZauGEK/sYFAlsuLXoACgkQ+9ZauGEK /sb88RAAiqszejtN+gi90SDAWJ0EDZofAk5DBaDLX0PZ1ibm3u+RHY+xKs4We9ov cfkb3m3GD6+L9J3jEw4nNjv8zSrzRK5MpoCDNiTg/6JVQEgp7e6Dux+YFF2UG4j7 QRx+2dVjBwKXNQ1OcdFnv9Nv6XcJFGBM72+u2AsC70ZXfs8bjtQcLOxMw0McfM4L gy2nvjR02IPNXJ8G7aNjIcT78YwchwTUiPGpCDs9d+aJe4ePOSsPs7PS39uKACNv PksIrU7VegnTK/BxFeVWl/m4JJEnZ/HC98lpJD/Pjno1yKiSo/58vg0TKUWRobWw cM/NLzrMP7eooioTBfeNeBpXYfM75+LPJBKx6ooNxWiI+19SFy7VuRkj5ZcjB5mj M7G0vLEnlMchhXEnGLlXk8I9PnMZ6Ot77g0pFj1XyoAMiOBajvwF5k1VNBrTr30+ I6EdQ9le4SVPigSinlK7idFIy5Dro8oAmP0HHuUatBrEVIGD2ojmqDSllEMB5QU6 K4g0T/hRisgVQ0UcVraY4FKI3H9ANRE6ZvtxwiMo9XgKCfg9F/BgBhRBStFjEAVy D2cXCnZyZNNn78Huf/Sv9P5Ioymr8RO2QYedoNWndlspUghx4WyGWiOAEbrsikJv onDcpy5WDnw3xeg4H0u+oIgkLG8g4SxakjgGTSL8yEd1yBYz8G0= =cWlV -----END PGP SIGNATURE----- --wnZ1FRxkVvcZMClP9DSPmpS3v4xlULUjj-- From nobody Mon Jun 25 06:14:54 2018 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 7C05F130E82 for ; Mon, 25 Jun 2018 06:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 bIoc4-mI-OPc for ; Mon, 25 Jun 2018 06:14:51 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 79990130ED0 for ; Mon, 25 Jun 2018 06:14:50 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by linode64.ducksong.com (Postfix) with ESMTPSA id 4AF533A02D for ; Mon, 25 Jun 2018 09:14:48 -0400 (EDT) Received: by mail-oi0-f47.google.com with SMTP id e8-v6so12430462oii.2 for ; Mon, 25 Jun 2018 06:14:48 -0700 (PDT) X-Gm-Message-State: APt69E3Xw+qtUWr3dfwfGmUBIs/xj1cMKyp6bIJ4HLHo0cJPX+6umrWS k+roBs3DWYMbIuJdU0v8jFwlZ6Kquz8KY2z80Q0= X-Google-Smtp-Source: ADUXVKJoWBKExrBvzDItybKO5/zHZ9D5MIO1wGK9frAV4kgedferH0gfbVvqIvPIAka00EpTRILgLGCj4AlPz7Rm2M4= X-Received: by 2002:aca:e7c8:: with SMTP id e191-v6mr1058004oih.132.1529932487989; Mon, 25 Jun 2018 06:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 06:14:47 -0700 (PDT) In-Reply-To: <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> From: Patrick McManus Date: Mon, 25 Jun 2018 09:14:47 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="0000000000007a217d056f772ae0" Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 13:14:53 -0000 --0000000000007a217d056f772ae0 Content-Type: text/plain; charset="UTF-8" It might make sense to mention that TCP correlates different requests together on the same connection when talking about TCP (though you could argue this is pretty much just IP correlation). I don't think we can or should craft a specification recommendation in this space though. Chartering advice for HTTP has consistently required better use of long lived connections, clients demand low latency, etc. and there's no science behind any particular number as it relates to correlation. --0000000000007a217d056f772ae0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It might make sense to mention that TCP correlates di= fferent requests together on the same connection when talking about TCP (th= ough you could argue this is pretty much just IP correlation).
I don't think we can or should craft a specification recom= mendation in this space though. Chartering advice for HTTP has consistently= required better use of long lived connections, clients demand low latency,= etc. and there's no science behind any particular number as it relates= to correlation.






--0000000000007a217d056f772ae0-- From nobody Mon Jun 25 08:30:28 2018 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 243EA130ECD for ; Mon, 25 Jun 2018 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 Yv7RvgCjp9-d for ; Mon, 25 Jun 2018 08:30:17 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 94C70130EC9 for ; Mon, 25 Jun 2018 08:30:17 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=49642) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fXTRT-0004z0-S7; Mon, 25 Jun 2018 16:30:15 +0100 From: Sara Dickinson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_91BEF753-ABCA-4EDD-96C0-2F41EE68CC7A" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Mon, 25 Jun 2018 16:30:03 +0100 In-Reply-To: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> Cc: doh@ietf.org To: nusenu , Patrick McManus References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 15:30:27 -0000 --Apple-Mail=_91BEF753-ABCA-4EDD-96C0-2F41EE68CC7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jun 2018, at 21:57, Patrick McManus = wrote: >=20 > On Thu, Jun 21, 2018 at 4:07 PM, nusenu > wrote: >=20 > Is this iteration supposed to address or include previous comments = from [1]? > I don't see [1] addressed. >=20 >=20 > I believe it addresses where we are converging related to those = comments and others. The text includes, among other things, the notion = that HTTPS is an incremental consideration to TLS and that the HTTPS = considerations deal with a large number of features because DoH design = allows leveraging of the full HTTP ecosystem. Hi Patrick,=20 Thanks for the updates, I think the discussion on cookies is = particularly helpful. I=E2=80=99m not sure it yet addresses everything = that has been raised on the list, I believe the PR proposed below does. > On 21 Jun 2018, at 21:07, nusenu wrote: >> The privacy considerations of using the HTTPS layer in DoH are >> incremental to those of DNS over TLS. DoH is not known to introduce >> new concerns beyond those associated with HTTPS. >=20 > Actually I think it does because it combines two protocols (DNS + = HTTPS) that haven't been > combined before and DNS+HTTPS has more privacy implications than just = the sum of IP, TCP, TLS and HTTP > when DoH server are not used exclusively for DoH. Actually, I think this is a very salient point. DoH is the combination = of DNS wireformat messages and the HTTP layer. That combination alone = introduces new privacy concerns beyond that of either standalone = protocol so I think this does need to be framed differently.=20 I=E2=80=99ve done a PR https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/205 = which removes the above text and more clearly breaks down the issue = along the lines of the layer model already used. Specifically it add = this text: --- Session resumption creates trivial mechanisms for a server to correlate = TLS=20 connections together. + ### DNS Specific considerations + + Whilst DNS transports will generally carry the same privacy properties = of the + layers used to implement them the standard DNS wireformat itself = notably + contains no client identifiers. Using HTTPS as a transport therefore = introduces + new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with = regard to + additional data that may be visible to a DoH server compared to a DNS = resolver. + ### HTTP Specific considerations (#HTTPconsiderations) + This section provides guidance but places only minor restrictions on = HTTP + features (specifically HTTP cookies) that may be used in DoH. The = design + rationale for this decision is that retaining the ability to leverage = the full + functionality of the HTTP ecosystem is more important than placing any + constraints on this new protocol based on privacy considerations. HTTP's feature set can also be used for identification and tracking in =E2=80=94 Sara. --Apple-Mail=_91BEF753-ABCA-4EDD-96C0-2F41EE68CC7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 21 = Jun 2018, at 21:57, Patrick McManus <pmcmanus@mozilla.com> wrote:

On Thu, = Jun 21, 2018 at 4:07 PM, nusenu <nusenu-lists@riseup.net> wrote:

Is this iteration supposed to address = or include previous comments from [1]?
I don't see [1] = addressed.


I believe it addresses where we are = converging related to those comments and others. The text includes, = among other things, the notion that HTTPS is an incremental = consideration to TLS and that the HTTPS considerations deal with a large = number of features because DoH design allows leveraging of the full HTTP = ecosystem.

Hi Patrick, 

Thanks for the updates, = I think the discussion on cookies is particularly helpful. I=E2=80=99m = not sure it yet addresses everything that has been raised on the list, I = believe the PR proposed below does.


On 21 = Jun 2018, at 21:07, nusenu <nusenu-lists@riseup.net> wrote:
The = privacy considerations of using the HTTPS layer in DoH are
incremental to those of DNS over TLS. DoH is not known to = introduce
new concerns beyond those associated with = HTTPS.

Actually I think it = does because it combines two protocols (DNS + HTTPS) that haven't = been
combined before and DNS+HTTPS has more privacy = implications than just the sum of IP, TCP, TLS and HTTP
when= DoH server are not used exclusively for DoH.

Actually, I think this is a very salient point. = DoH is the combination of DNS wireformat messages and the HTTP layer. = That combination alone introduces new privacy concerns beyond that of = either standalone protocol so I think this does need to be framed = differently. 

I=E2=80=99ve done = a PR
which removes the above text and more clearly breaks down = the issue along the lines of the layer model already used. Specifically = it add this text:

---
Session resumption creates = trivial mechanisms for a server to correlate = TLS 
connections together.

+ ### DNS Specific = considerations
+
+ Whilst DNS transports will = generally carry the same privacy properties of the
+ layers = used to implement them the standard DNS wireformat itself = notably
+ contains no client identifiers. Using HTTPS as a = transport therefore introduces
+ new privacy concerns over DNS = over UDP, TCP or TLS (RFC7858) with regard to
+ additional = data that may be visible to a DoH server compared to a DNS = resolver.

+ ### HTTP Specific = considerations (#HTTPconsiderations)

+= This section provides guidance but places only minor restrictions on = HTTP
+ features (specifically HTTP cookies) that may be used = in DoH. The design
+ rationale for this decision is that = retaining the ability to leverage the full
+ functionality of = the HTTP ecosystem is more important than placing any
+ = constraints on this new protocol based on privacy = considerations.

HTTP's = feature set can also be used for identification and tracking = in
=E2=80=94


Sara.

= --Apple-Mail=_91BEF753-ABCA-4EDD-96C0-2F41EE68CC7A-- From nobody Mon Jun 25 08:31:09 2018 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 40522130EE7 for ; Mon, 25 Jun 2018 08:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 aKEXe16rS3qF for ; Mon, 25 Jun 2018 08:30:59 -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 698EA130ED3 for ; Mon, 25 Jun 2018 08:30:59 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5PFMCxb007479; Mon, 25 Jun 2018 16:30:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=xNRVlKDPXWhwYiqdgyQKcvoKIU3hm5s2NvC0XSLS/OU=; b=QIjjdImk9ElJSSuJTiOC3zx7F1NtbizIJO9UWUNmGG1+uapLcThmcDDPbxnv0qWnsu7q nnYrBaUYz4utsee+ftk6BrQkIgUgfwFOuZWEYWCq0LpEdYiYdt4zvkJPxTRQDKYt/nbm TFwV9MCwS0BEXCAhnRqbrwlsJN1tDhJiJpXxmZ3OmUR7NWOF4dYkkSB8MokCjvE3Aj6c tUZknPzTXOad3lWGroxWfarYHhK4T1CwbP/yompPvcAT6ZwVOFgbxIVaowBEio04MmBl tCCvYOLiADVQCPWKVNcAPRpM6GqkSJvsd166Lx8VpLALRYzGb6Mti4jDA2N7SXZJaEsc 8w== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2jt154v1bq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Jun 2018 16:30:37 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5PFKtoL027643; Mon, 25 Jun 2018 11:30:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2jt0wc0400-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Jun 2018 11:30:35 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 25 Jun 2018 11:30:30 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Mon, 25 Jun 2018 11:30:30 -0400 From: "Hewitt, Rory" To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= , Paul Hoffman , DoH WG Thread-Topic: [Doh] [Ext] Privacy Considerations Text (#2) Thread-Index: AQHUCj+1gDiFfb7TpEC+Xt69KgTnJqRsshQAgAFFcQCAAyP+sA== Date: Mon, 25 Jun 2018 15:30:30 +0000 Message-ID: References: <11f2eb05-cc0f-9540-2f1d-90f510d7561d@o2.pl> <43ADDDC4-B249-4963-8E3C-E2295B4C4529@icann.org> <1a87456f-e7c4-e639-69ee-ece7686121b9@o2.pl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.187] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01D40C5E.C627C020" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-25_07:, , 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-1806210000 definitions=main-1806250179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-25_07:, , 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-1806210000 definitions=main-1806250179 Archived-At: Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 15:31:07 -0000 ------=_NextPart_000_0000_01D40C5E.C627C020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Mateusz, I like that. Here's an alternate way of saying it (not 'better', just = 'different'): Users with concerns about request correlation within a connection may choose to close and reopen any connections between a DoH client and the DoH server on a regular basis (e.g. when the outside IP address changes). However, this may reduce the performance gains realized by using a long-running connection between client and server. Thanks, Rory -----Original Message----- From: Mateusz Jo=C5=84czyk [mailto:mat.jonczyk@o2.pl]=20 Sent: Saturday, June 23, 2018 4:23 AM To: Paul Hoffman ; DoH WG Subject: Re: [Doh] [Ext] Privacy Considerations Text (#2) W dniu 22.06.2018 o 17:57, Mateusz Jo=C5=84czyk pisze: > W dniu 22.06.2018 o 17:42, Paul Hoffman pisze: >> On Jun 22, 2018, at 8:34 AM, Mateusz Jo=C5=84czyk = wrote: >>> W dniu 21.06.2018 o 20:43, Patrick McManus pisze: >>>> >>>> The privacy considerations of using the HTTPS layer in DoH are=20 >>>> incremental to those of DNS over TLS. DoH is not known to introduce = >>>> new concerns beyond those associated with HTTPS. >>> >>> I have been thinking that a DoH client would open a long-running=20 >>> connection to a DoH server. In such a case, request correlation=20 >>> could be simple and we should drop the "is not known to introduce = new concerns" sentence. >> >> Both RFC 7766 (DNS in TCP) and RFC 7858 (DNS in TLS) recommend = opening long-running connections, and explain the operational pros and = cons of doing so. >> >=20 > OK, now I have read that passage again and understand it. > I would argue that this should be discussed explicitly in the "Privacy = > considerations" section. >=20 I would propose to add the following text: Because of performance reasons, DOH clients are advised to open long-running connections to the DOH server. However, in such a case the server is able to correlate all the requests within a connection. Therefore it is advisable for DOH clients to close and reopen the connection to the DOH server e.g. every hour or when outside IP address changes - to make request correlation more difficult. I am happy to live in the EU. AFAIK our law makes doing such request = correllation for tracking purposes illegal in most cases. Greetings, Mateusz Jo=C5=84czyk ------=_NextPart_000_0000_01D40C5E.C627C020 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDYyNTE1MzAyOVowIwYJKoZIhvcNAQkEMRYEFNpjwI8MfcHsvH+7c79FjyCF2A6hMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAEmRCgEUa26+TGcey0tiOvvZhmDEJHmux9fLenfcZ2zudc46WOQNnuSTUue0 SkRLrL6aZcpRkp3rFFzj5h7K8d3+/ya4lpt1Kyd/OjgUvjXF2pM55NFAyvPC83Uh1NPc2kknsGdL OKWTXyKhBw+0l1Is85nfxqTgOc3RLYWySwP1E1d6Zh3P2B2fZ+K5doMHJaGgrV0dCD62ipna6sXn GxwoXjwQBUlVDL4bTKinuqzTSWTqx5EnoPD47VyIZUnR/rrFGs5zy7Jo0jGn9GkRzHSmTUZmXX1Q x4/9gj7jwGckUqICidBlLqckS0pjL+9dozCR4lsBTcknxUcufe1OKYoAAAAAAAA= ------=_NextPart_000_0000_01D40C5E.C627C020-- From nobody Mon Jun 25 16:40:27 2018 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 B464C130EF2 for ; Mon, 25 Jun 2018 16:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 gPt78uN1D3vm for ; Mon, 25 Jun 2018 16:40:22 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id AB37C130E5C for ; Mon, 25 Jun 2018 16:40:22 -0700 (PDT) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 469023A02B for ; Mon, 25 Jun 2018 19:40:21 -0400 (EDT) Received: by mail-ot0-f175.google.com with SMTP id i19-v6so17019683otk.10 for ; Mon, 25 Jun 2018 16:40:21 -0700 (PDT) X-Gm-Message-State: APt69E3qBYnWWlOyavZyTk1GbiixtubWcyeH6ZoyDZfaocW4SnTjIQhM rsv0VFYaNzfIHI9wAtAwCWfuQSmfwtcwUcPm/qs= X-Google-Smtp-Source: AAOMgpdFFEf0WC97fqte6GVJLzZC92Xt8Xcw8D3USnDJ5TcQ3nvqnMLXd3lvVx3fnnntpA1zKW15oWRjZhZDtdAPdlg= X-Received: by 2002:a9d:1bd6:: with SMTP id v22-v6mr9029174otv.85.1529970020961; Mon, 25 Jun 2018 16:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 16:40:20 -0700 (PDT) In-Reply-To: References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> From: Patrick McManus Date: Mon, 25 Jun 2018 19:40:20 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: Patrick McManus , DoH WG Content-Type: multipart/alternative; boundary="0000000000009dd39d056f7fe719" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 23:40:25 -0000 --0000000000009dd39d056f7fe719 Content-Type: text/plain; charset="UTF-8" Hi Sara, + ### DNS Specific considerations > + > + Whilst DNS transports will generally carry the same privacy properties > of the > + layers used to implement them the standard DNS wireformat itself notably > + contains no client identifiers. > That's mostly true imo (modulo perhaps edns client subnet) Using HTTPS as a transport therefore introduces > + new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with regard > to > + additional data that may be visible to a DoH server compared to a DNS > resolver. > > I do agree that HTTP adds additional considerations, which is what the existing text describes. But I don't agree with this sentence which, significantly through the use of therefore, indicates HTTPS has client identifiers and other transports do not. The previous several paragraphs have enumerated client identifiers also present in IP (therefore UDP), TCP, and TLS. Everything that transports wireformat. What if, instead, we add a new first paragraph to the "In the server" section along the lines of "The original DNS wireformat contains no client identifiers, however various transports of the DNS wireformat do provide data that can be used for request correlation. HTTPS presents new considerations for correlation ranging from explicit HTTP cookies to implicit fingerprinting of the unique set and ordering of request headers." > + ### HTTP Specific considerations (#HTTPconsiderations) > > I think this is largely what the paragraph that begins "The DoH protocol design allows applications to fully leverage.." is conveying. Maybe it can move towards what you are thinking.. wdyt of: The DoH protocol design allows applications to fully leverage the HTTP ecosystem, including features not enumerated here. Utilizing the full set of HTTP features enables DoH to be more than an HTTP tunnel, but also opens implementations up to the full set of privacy considerations of HTTP. Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations are advised to expose the minimal set of data needed to achieve the desired feature set. --0000000000009dd39d056f7fe719 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sara,


+ ### DNS Specific considerations
+
+ Whilst DNS transports will generally carry the same privacy prop= erties of the
+ layers used to implement them the standard DNS wi= reformat itself notably
+ contains no client identifiers.

That's mos= tly true imo (modulo perhaps edns client subnet)

Using HTTPS as a transport therefo= re introduces
+ new privacy concerns over DNS over UDP, TCP or TL= S (RFC7858) with regard to
+ additional data that may be visible = to a DoH server compared to a DNS resolver.


I do agree that HTTP ad= ds additional considerations, which is what the existing text describes. Bu= t I don't agree with this sentence which, significantly through the use= of therefore, indicates HTTPS has client identifiers and other transports = do not.

The previous several paragraphs have e= numerated client identifiers also present in IP (therefore UDP), TCP, and T= LS. Everything that transports wireformat.

Wha= t if, instead, we add a new first paragraph to the "In the server"= ; section along the lines of

"The origina= l DNS wireformat contains no client identifiers, however various transports= of the DNS wireformat do provide data that can be used for request correla= tion. HTTPS presents new considerations for correlation ranging from explic= it HTTP cookies to implicit fingerprinting of the unique set and ordering o= f request headers."

=C2=A0
+ ### HTTP Specific considerati= ons (#HTTPconsiderations)


I think this is largely what the paragrap= h that begins "The DoH protocol design allows applications to fully le= verage.." is conveying. Maybe it can move towards what you are thinkin= g.. wdyt of:


The DoH protocol design allows app= lications to fully leverage the HTTP
ecosystem, including features not e= numerated here. Utilizing the full
set of HTTP features enables DoH to b= e more than an HTTP tunnel, but
also opens implementations up to the ful= l set of privacy
considerations of HTTP.

Implementations of DoH c= lients and servers need to consider the
benefit and privacy impact of th= ese features, and their deployment
context, when deciding whether or not= to enable them. Implementations
are advised to expose the minimal set o= f data needed to achieve the desired
feature set.

=C2=A0
--0000000000009dd39d056f7fe719-- From nobody Mon Jun 25 19:01:03 2018 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 0755C130E7A for ; Mon, 25 Jun 2018 19:01:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=dtRVLTP6; dkim=pass (1024-bit key) header.d=yitter.info header.b=eH5eZDhr 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 4OIdX1i9zuCD for ; Mon, 25 Jun 2018 19:00:57 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1199B130F4A for ; Mon, 25 Jun 2018 19:00:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id AD40DBE444 for ; Tue, 26 Jun 2018 02:00:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1529978425; bh=G6WT7k5A9coaa5K0i1OH02TIJd6uBkgZebg6wcM9NGA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=dtRVLTP6+ZiUlo6wxBclQrn/q/apGZO+WgL2MYVItG9X67d81CdfzWmgffLtdZzgu NPCYNHqY1aHhoVV4AKSlXkCPtGqkT1+dBAM+JKmeuzUVLEsSwjB4W3Oe/QF+OrnfrU 43buQZB2JPKU7dM+4urJtL1G9Sp5CnFE+FbbQgAQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXIkpHutdWJZ for ; Tue, 26 Jun 2018 02:00:21 +0000 (UTC) Date: Mon, 25 Jun 2018 22:00:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1529978420; bh=G6WT7k5A9coaa5K0i1OH02TIJd6uBkgZebg6wcM9NGA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=eH5eZDhrn8+uKiLxF0IvL8f07kVj/LRRgprU2M5ioWMwIwC1VXyc4oEl25VmI/tTn w+geTm19X+oCfAdTfDjHuZjCsTJeZA4nPLkBHCKFP/1fp3mwi+g2piV96naCX1yfw+ xQEvH2LtDetMM9zDo6USyhdSgsSjMA4eiFwJ0yCE= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180626020019.GL12999@mx4.yitter.info> References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 02:01:02 -0000 On Mon, Jun 25, 2018 at 07:40:20PM -0400, Patrick McManus wrote: > What if, instead, we add a new first paragraph to the "In the server" section > along the lines of > > "The original DNS wireformat contains no client identifiers, however various > transports of the DNS wireformat do provide data that can be used for request > correlation. HTTPS presents new considerations for correlation ranging from > explicit HTTP cookies to implicit fingerprinting of the unique set and ordering > of request headers." I think this is good (sorry for my recent silence, but I've been watching this discussion avidly & thank the editors for their good work). I particularly agree that it is fair to note that lots of servers have been doing various kinds of request correlation for a long time. > Implementations of DoH clients and servers need to consider the > benefit and privacy impact of these features, and their deployment > context, when deciding whether or not to enable them. Implementations > are advised to expose the minimal set of data needed to achieve the desired > feature set. I think this is good, too -- it's neutral while yet raising the right degree of alarm. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Jun 26 05:45:07 2018 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 694C2131024 for ; Tue, 26 Jun 2018 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cdt.org 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 eP3H-dac2bbS for ; Tue, 26 Jun 2018 05:45:02 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 A6D19131021 for ; Tue, 26 Jun 2018 05:45:02 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id j11-v6so4636861vke.8 for ; Tue, 26 Jun 2018 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=95PujZY/iuQFjnUE95NT/2ZUbNyKdhA0dAYFe7odtwM=; b=p0XgArbEmzusKS9f4TOJLbSHlamxSPHOBu4EpvW9LwLxMyA9VGPjKMLOq9Hms3DJ5E /tuVZJhu/MfF51oL2+dKnsM6+MosmcgB9WWwQyadr8NapWrMKfuDSAPhN74V3G396DBY bLMP8VzvcdONa9DO/UtdiF0UvCeq2i3PpiRhE= 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=95PujZY/iuQFjnUE95NT/2ZUbNyKdhA0dAYFe7odtwM=; b=PnoFUlpxzEGCFwnvQ6q93rxlJkW21qXkz0WfFPmFmZmsR986wTAfj+791JjSr4s3+M SE4UdkJUpZNk9xY0OEoybwmWXuQji/Kc9K1e3OpCvpyGixowE6EzK85kQCvF7w8sB400 //bqlg036UqvaSuPPzbt4WXI+ZJGdhzIOGgbjXt+oCfadMSHKcaRs4XBN2QDKbgLSFIi z8pbQiwOLsrZ3UrBp+MoMpHz+uiscRsxFlmx2usVcffEDlVJgVDumYHrGQFwSb6nDVAU VF2vi2pYpfFGS/PLc3rMxHcn9wNN/hZqqD7KwhJAyaXTxU8ZuTClHa0HrW/2atIw5tPA 97YQ== X-Gm-Message-State: APt69E0gWWrixP5fpo5EHBssyw0oK4etFsAtsFEhEV7MsJ1oneIV2YwL Qzv6wOTC8+UvlMX5z3QTwayxbIxKEAUSPI35jzDl9A== X-Google-Smtp-Source: AAOMgpcsUTee0Pa7+sbNgpHj1Q30ySkp5zlwbeGpCkK1H8XF2RBt0X+2RDDpBs+MXdq0UZF+QrZ/Btoh5mprA019VtM= X-Received: by 2002:a1f:9a09:: with SMTP id c9-v6mr498503vke.128.1530017101223; Tue, 26 Jun 2018 05:45:01 -0700 (PDT) MIME-Version: 1.0 References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> <20180626020019.GL12999@mx4.yitter.info> In-Reply-To: <20180626020019.GL12999@mx4.yitter.info> From: Joseph Lorenzo Hall Date: Tue, 26 Jun 2018 08:44:50 -0400 Message-ID: To: Andrew Sullivan Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1b14e056f8addb7" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 12:45:05 -0000 --000000000000d1b14e056f8addb7 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 25, 2018 at 10:01 PM Andrew Sullivan wrote: > > > Implementations of DoH clients and servers need to consider the > > benefit and privacy impact of these features, and their deployment > > context, when deciding whether or not to enable them. Implementations > > are advised to expose the minimal set of data needed to achieve the > desired > > feature set. > > I think this is good, too -- it's neutral while yet raising the right > degree of alarm. > Is there something this text could reference that DOH implementers could read that would allow them to navigate privacy in HTTP? (That is, rather than just raising the alarm, point to some reference that could allow them to choose a minimal set for their needs, etc.) best, Joe --000000000000d1b14e056f8addb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Jun 25, 2018 at 10:01 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

> Implementations of DoH clients and servers need to consider the
> benefit and privacy impact of these features, and their deployment
> context, when deciding whether or not to enable them. Implementations<= br> > are advised to expose the minimal set of data needed to achieve the de= sired
> feature set.

I think this is good, too -- it's neutral while yet raising the right degree of alarm.

Is there somethi= ng this text could reference that DOH implementers could read that would al= low them to navigate privacy in HTTP? (That is, rather than just raising th= e alarm, point to some reference that could allow them to choose a minimal = set for their needs, etc.)

best, Joe
--000000000000d1b14e056f8addb7-- From nobody Tue Jun 26 06:11:18 2018 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 21790131032 for ; Tue, 26 Jun 2018 06:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 Mcmvxpyhdtd2 for ; Tue, 26 Jun 2018 06:11:08 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4810C13107B for ; Tue, 26 Jun 2018 06:11:08 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 950813A02B for ; Tue, 26 Jun 2018 09:11:07 -0400 (EDT) Received: by mail-ot0-f176.google.com with SMTP id v24-v6so18922381otk.13 for ; Tue, 26 Jun 2018 06:11:07 -0700 (PDT) X-Gm-Message-State: APt69E09+QjFvM6PYiYJtiLz8BtXIh5+ZT3mKhFhB62uhj6Ttol/eHma 8Bpe05s2/KLkWWKeiFHmC9dyesRFuKrtUIqvT0I= X-Google-Smtp-Source: AAOMgpfHrGmMoZ+bwWXWTlb8R8PUPOqxCzfMxtLfrs5z6lt7C+7eL11SAOiLlE5mhvHymnyPVV0aaA8kxun4BtJLwYw= X-Received: by 2002:a9d:2c41:: with SMTP id f59-v6mr754918otb.263.1530018667274; Tue, 26 Jun 2018 06:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 06:11:06 -0700 (PDT) In-Reply-To: References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> <20180626020019.GL12999@mx4.yitter.info> From: Patrick McManus Date: Tue, 26 Jun 2018 09:11:06 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Joseph Lorenzo Hall Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000029a9d4056f8b3bc9" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 13:11:11 -0000 --00000000000029a9d4056f8b3bc9 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 26, 2018 at 8:44 AM, Joseph Lorenzo Hall wrote: > > > Is there something this text could reference that DOH implementers could > read that would allow them to navigate privacy in HTTP? (That is, rather > than just raising the alarm, point to some reference that could allow them > to choose a minimal set for their needs, etc.) > > Mark and I discussed that a little bit - because it certainly should exist in the HTTP world and ideally this section would just point to that and be 90% shorter. However we couldn't identify anything satisfying - but we did open an issue on BCP56bis which would be, imo, a fine place to cover this in more detail. But that doc isn't going to be complete soon. --00000000000029a9d4056f8b3bc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 26, 2018 at 8:44 AM, Joseph Lorenzo Hall = <joe@cdt.org> wrote:


Is there something this text could reference that= DOH implementers could read that would allow them to navigate privacy in H= TTP? (That is, rather than just raising the alarm, point to some reference = that could allow them to choose a minimal set for their needs, etc.)
<= div>

Mark and I discussed t= hat a little bit - because it certainly should exist in the HTTP world and = ideally this section would just point to that and be 90% shorter. However w= e couldn't identify anything satisfying - but we did open an issue on B= CP56bis which would be, imo, a fine place to cover this in more detail. But= that doc isn't going to be complete soon.


--00000000000029a9d4056f8b3bc9-- From nobody Tue Jun 26 07:11:59 2018 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 DDDD5124D68 for ; Tue, 26 Jun 2018 07:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cdt.org 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 TtspC_hvCxUw for ; Tue, 26 Jun 2018 07:11:51 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 68CB4130DE0 for ; Tue, 26 Jun 2018 07:11:51 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id q135-v6so10121895vkh.1 for ; Tue, 26 Jun 2018 07:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mbN53Bx3wCuWNAotSt+d7Y1uHzXn0bkKZxFyb88q66A=; b=LdaLxI6B0Rg9lWSy5KNlVoMHPLM9ernNbys2W0ZvmHEVBkFeCKgGTG7V6AnOEg6hC+ VjbIQMCs3AHeoV8Zy+/d0WbQ7uuqYMMm6VA+6tAG4LyY8iX4WLEhd9ruNgXrgY05FUFW Yt9Jq7OtYH4WBKm7mlaTPNvx98xmrnRA9MRnw= 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=mbN53Bx3wCuWNAotSt+d7Y1uHzXn0bkKZxFyb88q66A=; b=gMQCueh6vnJVDfvl28GLhqgjetj/pC/MvGdgeFY9wS0hNMTUzaYPj5YEMAD37rdPuZ WPMVrnsvAwDqUyzrZKqzZKHTB0hGBFsu9tYtnxhykcaA8uZsT01pPk5shd7RTXMBfbQR B87PWHKkBIbe8YuZKR8EDh+tBz2Wf23uqAIUWTlv7PHx2QymW1cRT9VG6CXza4QrtiEC MCR2/bbxRLn/Dd3WED6jtcDCrL9x9NId0wXLxnGJWdaTGrj7t6PPgsnNUDTL7YbNgkGo G3jHPJvsyFfVB/R6lHEj/9vCaCcomz3IR2m7GRhEy7+PReOyagjTGte3CbN0q6je4GCr uV8A== X-Gm-Message-State: APt69E3kOuSz8a8KLzmqccs6UxVhi1N/Jr+wDYlJalOt2jfN8YJFsaUi 0E8sde2HDFbC6qjxQrewPQtZM+OiQ4rFYBbmKbCgf1fs47E= X-Google-Smtp-Source: AAOMgpcmNP64L98E5EHb5V5IIYzKZTursYQ/7HZsqdh2QSdxBW+YmjPcld1pj4/bruc6/i7jWi4P/4o5Pb0jaVCZj9I= X-Received: by 2002:a1f:3989:: with SMTP id g131-v6mr1119333vka.100.1530022309952; Tue, 26 Jun 2018 07:11:49 -0700 (PDT) MIME-Version: 1.0 References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> <20180626020019.GL12999@mx4.yitter.info> In-Reply-To: From: Joseph Lorenzo Hall Date: Tue, 26 Jun 2018 10:11:38 -0400 Message-ID: To: Patrick McManus Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000489120056f8c14fa" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 14:11:54 -0000 --000000000000489120056f8c14fa Content-Type: text/plain; charset="UTF-8" On Tue, Jun 26, 2018 at 9:11 AM Patrick McManus wrote: > > > On Tue, Jun 26, 2018 at 8:44 AM, Joseph Lorenzo Hall wrote: > >> >> >> Is there something this text could reference that DOH implementers could >> read that would allow them to navigate privacy in HTTP? (That is, rather >> than just raising the alarm, point to some reference that could allow them >> to choose a minimal set for their needs, etc.) >> >> > Mark and I discussed that a little bit - because it certainly should exist > in the HTTP world and ideally this section would just point to that and be > 90% shorter. However we couldn't identify anything satisfying - but we did > open an issue on BCP56bis which would be, imo, a fine place to cover this > in more detail. But that doc isn't going to be complete soon. > Cool! Thanks and makes sense... -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --000000000000489120056f8c14fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Cool! Thanks and makes sense...

--
Joseph Lorenzo Hall
Chief Technologist,= Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington= DC 20005-3497
e: joe@c= dt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2= 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871

--000000000000489120056f8c14fa-- From nobody Tue Jun 26 09:06:38 2018 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 5F3B4130EC7 for ; Tue, 26 Jun 2018 09:06:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ru8DLLwmp_zn for ; Tue, 26 Jun 2018 09:06:35 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E75B131053 for ; Tue, 26 Jun 2018 09:06:35 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:49266 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fXqUB-0007LP-Fe (Exim 4.72) for doh@ietf.org (return-path ); Tue, 26 Jun 2018 17:06:31 +0100 To: doh@ietf.org From: Ray Bellis Message-ID: <779d9d3e-8218-b519-3122-1bca512420d5@bellis.me.uk> Date: Tue, 26 Jun 2018 17:06:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Doh] Call For Presentations - Joint CENTR-Tech / DNS-OARC Workshop, Amsterdam, NL, 13th/14th October 2018 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 16:06:38 -0000 The 29th DNS-OARC Workshop will be a joint workshop combined with CENTR-Tech and will take place at the Hotel Okura, Amsterdam, Netherlands, on October 13th and 14th 2018. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted on the first day of the workshop, until 4pm. The second afternoon of the workshop will start with a Members-only session which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. The Members-only session will be followed by the AGM. Workshop Milestones: 15 Jun 2018 - Submissions and Registrations open via Indico 13 Jul 2018 - Deadline for submission 17 Aug 2018 - Contribution list published 14 Sep 2018 - Full agenda published 06 Oct 2018 - Deadline for slideset submission 13 Oct 2018 - Workshop Details for presentation submission are published here: The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Ray Bellis, for the joint Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) From nobody Tue Jun 26 09:51:01 2018 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 B1E2313111F for ; Tue, 26 Jun 2018 09:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 oqFbUdn3cuQl for ; Tue, 26 Jun 2018 09:50:39 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 C5A35131115 for ; Tue, 26 Jun 2018 09:50:38 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=55553) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fXrAn-0002Ep-AK; Tue, 26 Jun 2018 17:50:37 +0100 From: Sara Dickinson Message-Id: <2BA95ED9-629A-44CD-A91E-0176F171D4E3@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E40D5A11-374A-444B-834C-36507CEA3673" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 26 Jun 2018 17:50:30 +0100 In-Reply-To: Cc: DoH WG To: Patrick McManus References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 16:51:00 -0000 --Apple-Mail=_E40D5A11-374A-444B-834C-36507CEA3673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Jun 2018, at 00:40, Patrick McManus = wrote: >=20 > Hi Sara, >=20 > Using HTTPS as a transport therefore introduces > + new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with = regard to > + additional data that may be visible to a DoH server compared to a = DNS resolver. >=20 >=20 > I do agree that HTTP adds additional considerations, which is what the = existing text describes. But I don't agree with this sentence which, = significantly through the use of therefore, indicates HTTPS has client = identifiers and other transports do not. Thats a pretty defensive reading of this given the 3 paragraphs that = precede it=E2=80=A6 it is intended to illustrate that the delta from = DNS-over-UDP/TCP/TLS to DoH introduces _additional_ transport client = identifiers, which it does.=20 >=20 > The previous several paragraphs have enumerated client identifiers = also present in IP (therefore UDP), TCP, and TLS. Everything that = transports wireformat. >=20 > What if, instead, we add a new first paragraph to the "In the server" = section along the lines of >=20 > "The original DNS wireformat contains no client identifiers, however = various transports of the DNS wireformat do provide data that can be = used for request correlation. HTTPS presents new considerations for = correlation ranging from explicit HTTP cookies to implicit = fingerprinting of the unique set and ordering of request headers.=E2=80=9D= But I can live with this suggested text=E2=80=A6 we could say = =E2=80=98standard=E2=80=99 (at the time or writing) here because RFC7871 = (EDNS Client Subnet) is actually only an Informational RFC and = =E2=80=98original=E2=80=99 could be read to imply there are later = identifiers defined.=20 >=20 > =20 > + ### HTTP Specific considerations (#HTTPconsiderations) >=20 >=20 > I think this is largely what the paragraph that begins "The DoH = protocol design allows applications to fully leverage.." is conveying. = Maybe it can move towards what you are thinking.. wdyt of: >=20 >=20 > The DoH protocol design allows applications to fully leverage the HTTP > ecosystem, including features not enumerated here. Utilizing the full > set of HTTP features enables DoH to be more than an HTTP tunnel, but > also opens implementations up to the full set of privacy > considerations of HTTP. I=E2=80=99d like to see this say =E2=80=98at the cost of opening up = implementations to the..=E2=80=99 to fully recognise the trade off but = otherwise I think we are as converged as we are ever going to be :-)=20 Thanks Sara.=20= --Apple-Mail=_E40D5A11-374A-444B-834C-36507CEA3673 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 26 Jun 2018, at 00:40, Patrick McManus <pmcmanus@mozilla.com> wrote:

Hi Sara,


Using HTTPS as a transport = therefore introduces
+ new privacy concerns over = DNS over UDP, TCP or TLS (RFC7858) with regard to
+ = additional data that may be visible to a DoH server compared to a DNS = resolver.


I do agree that HTTP = adds additional considerations, which is what the existing text = describes. But I don't agree with this sentence which, significantly = through the use of therefore, indicates HTTPS has client identifiers and = other transports do not.

Thats a pretty defensive reading of this given the 3 = paragraphs that precede it=E2=80=A6 it is intended to illustrate that = the delta from DNS-over-UDP/TCP/TLS to DoH introduces _additional_ = transport client identifiers, which it does. 


The previous several paragraphs have enumerated client = identifiers also present in IP (therefore UDP), TCP, and TLS. Everything = that transports wireformat.

What if, instead, we add a new first = paragraph to the "In the server" section along the lines of

"The= original DNS wireformat contains no client identifiers, however various = transports of the DNS wireformat do provide data that can be used for = request correlation. HTTPS presents new considerations for correlation = ranging from explicit HTTP cookies to implicit fingerprinting of the = unique set and ordering of request = headers.=E2=80=9D
But I can live with this suggested text=E2=80=A6 = we could say =E2=80=98standard=E2=80=99 (at the time or writing) here = because RFC7871 (EDNS Client Subnet) is actually only an Informational = RFC and =E2=80=98original=E2=80=99 could be read to imply there are = later identifiers defined. 


 
+ ### = HTTP Specific considerations (#HTTPconsiderations)


I think this is largely = what the paragraph that begins "The DoH protocol design allows = applications to fully leverage.." is conveying. Maybe it can move = towards what you are thinking.. wdyt of:


The DoH protocol = design allows applications to fully leverage the HTTP
ecosystem, including features not enumerated here. Utilizing = the full
set of HTTP features enables DoH to be more than = an HTTP tunnel, but
also opens implementations up to the = full set of privacy
considerations of = HTTP.

I=E2=80=99d like to see this say =E2=80=98at the cost = of opening up implementations to the..=E2=80=99 to fully recognise the = trade off but otherwise I think we are as converged as we are ever going = to be :-) 

Thanks

Sara. 
= --Apple-Mail=_E40D5A11-374A-444B-834C-36507CEA3673-- From nobody Tue Jun 26 11:17:04 2018 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 7063C1310F2 for ; Tue, 26 Jun 2018 11:17:02 -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 MAGJNehnptVs for ; Tue, 26 Jun 2018 11:17:00 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3742130F08 for ; Tue, 26 Jun 2018 11:17:00 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 472841A0433 for ; Tue, 26 Jun 2018 11:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1530037020; bh=I9P+MiIJt0I59wm6OkiHPLssuYU/8IhzaDSaf3PoiqA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DMN/ZpxwqL9iCpRvehkmvLZk2nc/+9G9t3YmXvGCPwf0Xf8v1TR/pmgVsh5NIfxa5 W4bbzgWNHIeW40NqV4ORs1Q/C+vzLse9sFyLgSTvn0Wi1qAQ05hiRfyheWHOOVjgP7 ZR7ixUnUuaroAd3kwUKeQHLibcN3EkbRnMl8xJFU= X-Riseup-User-ID: D6BA35AEFCD48C062A7FF0656D93D2C8CDD1E2D8BE85DC9657111DEE58F82E08 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 3D35EC8CB8 for ; Tue, 26 Jun 2018 11:16:58 -0700 (PDT) To: doh@ietf.org References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> 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: <26e87673-7823-9e02-6c97-2c363d65037e@riseup.net> Date: Tue, 26 Jun 2018 18:16:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Azyzv2564e9bsB5FJhoOKZ6c4bXWHwDCa" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:17:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Azyzv2564e9bsB5FJhoOKZ6c4bXWHwDCa Content-Type: multipart/mixed; boundary="vzCNP0Agz5eSvQ7LO2XM8aVkzUN9WwXcB"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <26e87673-7823-9e02-6c97-2c363d65037e@riseup.net> Subject: Re: [Doh] Privacy Considerations Text (#2) References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> In-Reply-To: --vzCNP0Agz5eSvQ7LO2XM8aVkzUN9WwXcB Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Sara Dickinson wrote: > I=E2=80=99ve done a PR > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/205 > which removes the above text and more clearly breaks down the issue alo= ng the lines of the layer model already used. Specifically it add this te= xt: >=20 > --- > Session resumption creates trivial mechanisms for a server to correlate= TLS=20 > connections together. >=20 > + ### DNS Specific considerations > + > + Whilst DNS transports will generally carry the same privacy propertie= s of the > + layers used to implement them the standard DNS wireformat itself nota= bly > + contains no client identifiers. Using HTTPS as a transport therefore = introduces > + new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with reg= ard to > + additional data that may be visible to a DoH server compared to a DNS= resolver. +1 to this, especially the following sentence is clear and explicit about= the privacy delta of DoH vs. i.e. DoT: "Using HTTPS as a transport therefore introduces new privacy concerns ove= r DNS over UDP, TCP or TLS (RFC7858)" --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --vzCNP0Agz5eSvQ7LO2XM8aVkzUN9WwXcB-- --Azyzv2564e9bsB5FJhoOKZ6c4bXWHwDCa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsygxIACgkQrWE4wkXN Qn6c1w//bAIrZcj16BnvpSsB5e0hzB5xkp+y3DdaTdrPEwcIZEWJjZZ7teIRkCpV NW48f6dY7vGmUOp/ejn2IT4xerU3iLm1KYx7rXIq/v/04B4Gr9gTzeQJ9Hv8KBq4 k5wdViYIUTiV5dslgwER8Pf13n0Pr/4Tof2P+6SbbOP1xX9i2EUa/QVnhM1rdM1E g7RNAIiATigdbwuBggfT/p68fAKIgTAPoxhi9RCaBnfVPdhMTsNMmzGsC+SAAPmx NZpndg2o8RF/5xnwimOKLq8Hwe+6s4E208rZwMna3dezRI0UXs7zt5rjB8pSD10G Dh64FzPQFn3fEacuWOyFIp+tMvM6ZorIRINpRt2Ax6Lo0ilXQmVriDgztMylZJDS OBWe5dj+HXRrKK2dw4BzDkFFLfy9IlgtoF0yAv6MCjbXTuiuPoz9PFYzFHj0VlQ/ sd6IhJKiN4uVWcPLGhY+wPx/B0Oh2rpvQFZPvivEo21d14Kco21iOiifq8UO6onk yipBKOddE4nLKWyaXRQYZBRqQyEj9a4qytLnzv3/W+mNaH6tinx3ec2dnCxASOZB MmSFdKlRMpU/8b58rWlaRT7D3KGOwzHI97JJ7RSbDBqxo5lDgRytChmsk/sF8OM6 KIGpG90Exr5O4RRgce8vQ1Kx7GX/N2/TjQRu6lUAR2ejDGsC4pI= =0Nto -----END PGP SIGNATURE----- --Azyzv2564e9bsB5FJhoOKZ6c4bXWHwDCa-- From nobody Tue Jun 26 11:18:26 2018 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 1217F1310F6 for ; Tue, 26 Jun 2018 11:18:20 -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 I7eYGmvmpmGn for ; Tue, 26 Jun 2018 11:18:18 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE329131145 for ; Tue, 26 Jun 2018 11:18:17 -0700 (PDT) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (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 74E281A0409 for ; Tue, 26 Jun 2018 11:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1530037097; bh=x/+Cp+GSXhjefofU/b5hWE7R57DfvK//tUyroJqEu/c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=p2ReSKyXAxJAs6UJ5zKSxWPLzoAjP8R1pDl32DxsrFuIde4vwset2BSxgKp/y9b7+ B8kL6WuKEZDAFfBLgAGqPn4qQoKqoFHpOsJ29+08CBO5agcO856NjX3Sbbm8PdRKOQ ysxyK4UL6UKn6Q7yGcCnALSTLn5GonYRTnaYeRxk= X-Riseup-User-ID: 866DEF88DB96ACA24D12CD1F2C1A4DC17CCE3F7339869C5F6C8280EBC35994B7 Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 7963CC8CC1 for ; Tue, 26 Jun 2018 11:18:16 -0700 (PDT) To: doh@ietf.org References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> 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: <4b143b17-852f-9bb8-de61-7c924292808f@riseup.net> Date: Tue, 26 Jun 2018 18:18:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qqYNTm8tyV9A3Cj1cVcVHVHjRTsEl6efM" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:18:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qqYNTm8tyV9A3Cj1cVcVHVHjRTsEl6efM Content-Type: multipart/mixed; boundary="GUwbVyG0s0stZv8UfNH7oNbY9faxlnN69"; protected-headers="v1" From: nusenu To: doh@ietf.org Message-ID: <4b143b17-852f-9bb8-de61-7c924292808f@riseup.net> Subject: Re: [Doh] Privacy Considerations Text (#2) References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> In-Reply-To: --GUwbVyG0s0stZv8UfNH7oNbY9faxlnN69 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Patrick McManus wrote: > That's mostly true imo (modulo perhaps edns client subnet) >=20 > Using HTTPS as a transport therefore introduces >> + new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with re= gard >> to >> + additional data that may be visible to a DoH server compared to a DN= S >> resolver. >> >> > I do agree that HTTP adds additional considerations, which is what the > existing text describes. But I don't agree with this sentence which, > significantly through the use of therefore, indicates HTTPS has client > identifiers and other transports do not. >=20 > The previous several paragraphs have enumerated client identifiers also= > present in IP (therefore UDP), TCP, and TLS. Everything that transports= > wireformat. >=20 > What if, instead, we add a new first paragraph to the "In the server" > section along the lines of >=20 > "The original DNS wireformat contains no client identifiers, however > various transports of the DNS wireformat do provide data that can be us= ed > for request correlation. HTTPS presents new considerations for correlat= ion > ranging from explicit HTTP cookies to implicit fingerprinting of the un= ique > set and ordering of request headers." "various transports" is less specific than previous proposals. Note the delta between "HTTPS presents new considerations for correlation= " and clearly stating: "introduces new privacy concerns" (previously prop= osed) Generally speaking I consider this less frank about the privacy implicati= ons of DoH than previous proposals from Sara but it is understandable that draft authors dislike having "int= roduces new privacy concerns" in their draft. >> + ### HTTP Specific considerations (#HTTPconsiderations) >> >> > I think this is largely what the paragraph that begins "The DoH protoco= l > design allows applications to fully leverage.." is conveying. Maybe it = can > move towards what you are thinking.. wdyt of: >=20 >=20 > The DoH protocol design allows applications to fully leverage the HTTP > ecosystem, including features not enumerated here. Utilizing the full > set of HTTP features enables DoH to be more than an HTTP tunnel, but > also opens implementations up to the full set of privacy > considerations of HTTP. also here, note "considerations" vs. "concerns" =20 I find Sara's version made it more clear that here has been made a=20 deliberate design decision to accept the privacy concerns=20 to retain full functionality. --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --GUwbVyG0s0stZv8UfNH7oNbY9faxlnN69-- --qqYNTm8tyV9A3Cj1cVcVHVHjRTsEl6efM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsyg2MACgkQrWE4wkXN Qn4hug//TXCfok0WrIUaHYmWuaoztRFepwJoECW8fTcEBefSAGNHTBZqlU7bCk/M Mmu0TUSqD+LS5MMbdURc+lsqpye4X1v4/zsw6l32Avh7rma8fFQstNiJqYiibZlv YgG2j5PEcjr+UDMCKOtyam7FNOsyvscHA0PB1zHhTRCTHZvQUqqH0Pu/zzwrBCZQ 5HE0Q8HkIYaNQ/wKZycWoDfjjmPEVBRIlwIuwGYprhH7HCStPF3oebWcgKszrWQ2 PTD1LDcPHp9dznEzfwZqURxqixH1KGv/pZAkLjTBf0E459XQQdsbeL9o+oV5docf XCZRjXyXE6NuSVSputbKq5wloDnA69Vazcft3DZPafM1qK6v4XwTqAIqmYCK70DI GGEi3JgdcAk7MT0MRdTuF0dNtcTPmVMXk07ugKW/uN+g+Nk7JzNHSqY5azYagsyn rtq6GF91T5rOABQsUhtRPTDANedaJ65iMvdM8mkRCCxr0KskJv5LRJIvBuisnkXV o2rS9kNgHKcqJTLpilSmxVqfjTjimvQqrHX+3yDjQ9SEL/hpgfPBL4Rpwweo2nP1 IQ51DEbgyX5U1duIV0jJkirKEVHMdl/vzzLHJFteWLKyV3MoAGkstK8YpG2Nb6uh ckThsTcfXCWB6h07S5yqRyKGLLrm92Xdm0dKW3+01ULsBszqeQw= =DH1A -----END PGP SIGNATURE----- --qqYNTm8tyV9A3Cj1cVcVHVHjRTsEl6efM-- From nobody Tue Jun 26 11:44:19 2018 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 8AA231310FB for ; Tue, 26 Jun 2018 11:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 VNe5vU9gbOCr for ; Tue, 26 Jun 2018 11:44:14 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 588681310F8 for ; Tue, 26 Jun 2018 11:44:14 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id C08BB3A05F for ; Tue, 26 Jun 2018 14:44:13 -0400 (EDT) Received: by mail-ot0-f176.google.com with SMTP id h6-v6so20186389otj.0 for ; Tue, 26 Jun 2018 11:44:13 -0700 (PDT) X-Gm-Message-State: APt69E2b07fIhsIbNQfuig5+SR/OBirOywYuwXKtvHGDA5mh1thX1miT Myd+3X7tUa8fb4Xg8AkBnZIlv/+QJUK3JENJBFg= X-Google-Smtp-Source: AAOMgpfzams6K67HM3Q8yE4FOzjTO6EtUj04uLahxw7Z5ZlSgkH55guVdDoscPBLaMEnMucEvLk7gaZyVnQclTiRn5I= X-Received: by 2002:a9d:cf2:: with SMTP id o47-v6mr742220otd.397.1530038653506; Tue, 26 Jun 2018 11:44:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 11:44:12 -0700 (PDT) In-Reply-To: <2BA95ED9-629A-44CD-A91E-0176F171D4E3@sinodun.com> References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> <2BA95ED9-629A-44CD-A91E-0176F171D4E3@sinodun.com> From: Patrick McManus Date: Tue, 26 Jun 2018 14:44:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: Patrick McManus , DoH WG Content-Type: multipart/alternative; boundary="0000000000006f6acd056f8fe266" Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:44:17 -0000 --0000000000006f6acd056f8fe266 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sara. Thanks again for this. https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/206 On Tue, Jun 26, 2018 at 12:50 PM, Sara Dickinson wrote: > > But I can live with this suggested text=E2=80=A6 we could say =E2=80=98st= andard=E2=80=99 (at the > time or writing) here because RFC7871 (EDNS Client Subnet) is actually on= ly > an Informational RFC and =E2=80=98original=E2=80=99 could be read to impl= y there are later > identifiers defined. > > my PR ended up saying "DNS wireformat {{RFC1035}}" .. > > I=E2=80=99d like to see this say =E2=80=98at the cost of opening up imple= mentations to > the..=E2=80=99 to fully recognise the trade off but otherwise I think we = are as > converged as we are ever going to be :-) > > sounds ok to me. --0000000000006f6acd056f8fe266 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sara. Thanks again for this. https://github.com/dohwg/= draft-ietf-doh-dns-over-https/pull/206

On Tue, Jun 26, 2018 at 12:50 PM, Sara Di= ckinson <sara@sinodun.com> wrote:

But I can live with this suggested text=E2=80=A6 we could say =E2=80= =98standard=E2=80=99 (at the time or writing) here because RFC7871 (EDNS Cl= ient Subnet) is actually only an Informational RFC and =E2=80=98original=E2= =80=99 could be read to imply there are later identifiers defined.=C2=A0


my PR ended up saying "DNS wireformat {{RFC1035}}&qu= ot; ..
=C2=A0

I=E2=80=99d like to see this say =E2= =80=98at the cost of opening up implementations to the..=E2=80=99 to fully = recognise the trade off but otherwise I think we are as converged as we are= ever going to be :-)=C2=A0

sounds ok to me.



=
--0000000000006f6acd056f8fe266-- From nobody Wed Jun 27 05:45:43 2018 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 443451277C8 for ; Wed, 27 Jun 2018 05:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de 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 OMl9tfFSEszi for ; Wed, 27 Jun 2018 05:45:39 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 CB4C5127598 for ; Wed, 27 Jun 2018 05:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:Subject:From:To:content-disposition; bh=zlJ6WpiI6Vvm99999sowBnrqpqen3WG6O+i2VIOOixM=; b=byBoOJmRrSqTM7cjL1TPnA4+1v XD4umR1w7p/iKbF+avXK5ewA8Rxh/aT7Hjk8cJYGDaSCeX1Cnn5ECjKaaMw646gBE4pfVNrh1N7n3 pCA4g1d/ABnAjCU8Ef6swGelnZR+Ep9wP8y/+a2fI/583W6SadHqq/LEydXtpVbFx5R/MwA9cZSMI o5JHLSYzCt6b0EDQ73MPIU8KDaInrItknasUlxsXXKNFst5RlfE+7xK9Bdx9kfD9VQmjQ8Hl65hJz wegls15Cx02rLgM1Coww++/z+kZmmTwzx53snFLA9AMDWxngZpzoCrbjcrP/nx3WpvhLQLF1ESbz2 0bx7SrSME8TTgCyxH3I/kkJtLr3LVI4BiOMmcV8BKlsPKZGF6UIaqDkMHIuMF8pLiimZuZbPegB+9 yOtMkp9qZN0xp/k8dF6MPxJP/vgmDrrNEzC4qbEixRvo2v32Trrkd6pHYMq+YWLrfWuHIq7a34Y65 rCkLCI88uWkyOtEcjIgzxv9meJXyyHCdUpabJJ3p2MsHeyuP3LF4+oQn9uVNspnNgUOZ+0cdLAUfA NtDQ0Nnwmna73UlHiF+g01jNhIuI5JSYoYrrQ9FQEsU46zST/5d2yh+4ph3H6a24zBzZ8+VOGfJB1 WG/DbUzwJfZUVeLCvZyBSp1pEFsy+uTtPMUXkSgEU=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fY9pF-0003zr-W0 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Wed, 27 Jun 2018 14:45:35 +0200 To: doh@ietf.org From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> Date: Wed, 27 Jun 2018 14:45:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 12:45:42 -0000 Hi, the AD-bit is just a flag forwarded by the DoH-server to the DoH-client. Nobody knows where or by whom DNSSEC-'validation' was done or if someone tampered with the AD bit on the DoH-server or any upstream server/connection. A security chain is only as strong as the weakeast link. To make matters worse router vendors lull users in a false sense of security by advertising DNSSEC support while only passing along the AD-bit instead of doing DNSSEC validation on the router. This undermines the reputation of DNSSEC. In my opinion the AD-bit should never ever have made it into the DNSSEC-RFCs. I suggest to replace the text 'It is the choice of a client to either perform full DNSSEC validation of answers or to trust the DoH server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.' in section '9. Security Considerations' with 'The DNSSEC AD (Authentic Data) bit MUST be ignored by DoH clients to avoid AD bits manipulated on the DoH server, upstream servers or upstream connections.' Regards, Renne From nobody Wed Jun 27 06:11:10 2018 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 38A0F12D7F8 for ; Wed, 27 Jun 2018 06:11:08 -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=yitter.info header.b=nkLdtJhS; dkim=pass (1024-bit key) header.d=yitter.info header.b=UQhg/2g9 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 9TgrUgOnSc0C for ; Wed, 27 Jun 2018 06:11:06 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E0A1277C8 for ; Wed, 27 Jun 2018 06:11:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id B9E95BE444 for ; Wed, 27 Jun 2018 13:11:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530105065; bh=gHOrFH+infWjkmSZpazCmRTt8LJ+VjsZ77UQKpaMvvk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nkLdtJhS3yhk5FOxzTiy5fcwHLSODkEm/pYPMgGuSweWYM0fFtmD/lJyezVn3NFX4 5GQgZ7LeEnXnN48JcHfcn3n05Yagd+rw4PUBgHg4K7ny1CzcLIsgziy8JRbtQ4SKek 1PRgg6h9RcQs/lBu1yuTKNdt+UWB5rF897CwGDc0= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slGh1oYgFjG1 for ; Wed, 27 Jun 2018 13:11:04 +0000 (UTC) Date: Wed, 27 Jun 2018 09:11:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530105064; bh=gHOrFH+infWjkmSZpazCmRTt8LJ+VjsZ77UQKpaMvvk=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UQhg/2g9p4NnBvZgs0LMDuP7aJmKk8UrUb6PI4RdTB+/l9aMMKFyykFXZ1OBy6HaL GOhWbyLfyNRttlnPz3gV8SjCDtUAGj7Xv1kmedb4qBBT9pGg7YYSmxK+oWK1w5MdDW v7pyuZk5NC0x7rGg8kMv1aFOoKC56+Xuh8usuqKY= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180627131102.GO22421@mx4.yitter.info> References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 13:11:09 -0000 Hi, On Wed, Jun 27, 2018 at 02:45:31PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Nobody knows where or by whom DNSSEC-'validation' was done or if someone > tampered with the AD bit on the DoH-server or any upstream > server/connection. While this is true, it is entirely possible to have an environment where you trust your upstream resolver to do the validation for you. For instance, in an enterprise environment where you control both the clients and the validating resolver, and you know what the policy is for that resolver, the AD bit can be useful. > To make matters worse router vendors lull users in a false sense of security > by advertising DNSSEC support while only passing along the AD-bit instead of > doing DNSSEC validation on the router. That would not be a case where you should trust the validator, because you did not control the configuration or verify that proper validation was being done. > In my opinion the AD-bit should never ever have made it into the > DNSSEC-RFCs. But it did, for the reasons above. In cases such as you describe, it is open to the client to do its own validation anyway, so I don't see why there is a problem. > 'The DNSSEC AD (Authentic Data) bit MUST be ignored by DoH clients to avoid > AD bits manipulated on the DoH server, upstream servers or upstream > connections.' I am very strongly opposed to this. It would be entirely wrong for DoH to change DNSSEC handling in this way. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jun 27 07:16:00 2018 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 9F7CD130DD3 for ; Wed, 27 Jun 2018 07:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 aOLVEefmIzu8 for ; Wed, 27 Jun 2018 07:15:56 -0700 (PDT) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [52.201.171.122]) (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 1C1D4130DCF for ; Wed, 27 Jun 2018 07:15:56 -0700 (PDT) Received: from zmcc-5-mta-1.zmailcloud.com (zmcc-5-mta-1.zmailcloud.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 699E14055C; Wed, 27 Jun 2018 09:25:01 -0500 (CDT) Received: from zmcc-5-mta-1.zmailcloud.com (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id DC78CC085B; Wed, 27 Jun 2018 09:15:54 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id CFE58C05A6; Wed, 27 Jun 2018 09:15:54 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ciNk-Oq4uubq; Wed, 27 Jun 2018 09:15:54 -0500 (CDT) Received: from [192.168.1.204] (unknown [83.136.45.239]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPSA id E7675C0867; Wed, 27 Jun 2018 09:15:53 -0500 (CDT) To: nusenu , doh@ietf.org References: <0c003af5-6258-6de5-fdaf-161402c60b4d@riseup.net> <4b143b17-852f-9bb8-de61-7c924292808f@riseup.net> From: Howard Chu Message-ID: <58d613be-38ff-5bde-b958-395178595271@symas.com> Date: Wed, 27 Jun 2018 15:15:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 SeaMonkey/2.53a1 MIME-Version: 1.0 In-Reply-To: <4b143b17-852f-9bb8-de61-7c924292808f@riseup.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Privacy Considerations Text (#2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 14:15:59 -0000 Agree with nusenu, Sara's original text is more explicit and that's what you need when the topic is privacy considerations. nusenu wrote: > > > Patrick McManus wrote: >> That's mostly true imo (modulo perhaps edns client subnet) >> >> Using HTTPS as a transport therefore introduces >>> + new privacy concerns over DNS over UDP, TCP or TLS (RFC7858) with regard >>> to >>> + additional data that may be visible to a DoH server compared to a DNS >>> resolver. >>> >>> >> I do agree that HTTP adds additional considerations, which is what the >> existing text describes. But I don't agree with this sentence which, >> significantly through the use of therefore, indicates HTTPS has client >> identifiers and other transports do not. >> >> The previous several paragraphs have enumerated client identifiers also >> present in IP (therefore UDP), TCP, and TLS. Everything that transports >> wireformat. >> >> What if, instead, we add a new first paragraph to the "In the server" >> section along the lines of >> >> "The original DNS wireformat contains no client identifiers, however >> various transports of the DNS wireformat do provide data that can be used >> for request correlation. HTTPS presents new considerations for correlation >> ranging from explicit HTTP cookies to implicit fingerprinting of the unique >> set and ordering of request headers." > > > "various transports" is less specific than previous proposals. > > Note the delta between "HTTPS presents new considerations for correlation" and clearly stating: "introduces new privacy concerns" (previously proposed) > > Generally speaking I consider this less frank about the privacy implications of DoH than previous proposals > from Sara but it is understandable that draft authors dislike having "introduces new privacy concerns" in their draft. > >>> + ### HTTP Specific considerations (#HTTPconsiderations) >>> >>> >> I think this is largely what the paragraph that begins "The DoH protocol >> design allows applications to fully leverage.." is conveying. Maybe it can >> move towards what you are thinking.. wdyt of: >> >> >> The DoH protocol design allows applications to fully leverage the HTTP >> ecosystem, including features not enumerated here. Utilizing the full >> set of HTTP features enables DoH to be more than an HTTP tunnel, but >> also opens implementations up to the full set of privacy >> considerations of HTTP. > > also here, note "considerations" vs. "concerns" > > I find Sara's version made it more clear that here has been made a > deliberate design decision to accept the privacy concerns > to retain full functionality. > > > > > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From nobody Wed Jun 27 07:48:25 2018 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 E7AF6130E8F for ; Wed, 27 Jun 2018 07:48:23 -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 JhFpu0tKno_f for ; Wed, 27 Jun 2018 07:48:22 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0BF130E71 for ; Wed, 27 Jun 2018 07:48:21 -0700 (PDT) Received: from [88.212.170.147] (port=55466 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fYBk2-0004iF-Lu (Exim 4.72) for doh@ietf.org (return-path ); Wed, 27 Jun 2018 15:48:18 +0100 To: doh@ietf.org References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> From: Ray Bellis Message-ID: Date: Wed, 27 Jun 2018 15:48:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180627131102.GO22421@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 14:48:24 -0000 On 27/06/2018 14:11, Andrew Sullivan wrote: > I am very strongly opposed to this. It would be entirely wrong for > DoH to change DNSSEC handling in this way. +lots. Ray From nobody Wed Jun 27 08:33:17 2018 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 8CD69130DF5 for ; Wed, 27 Jun 2018 08:33:15 -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] 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 YHl7gritZwUy for ; Wed, 27 Jun 2018 08:33:13 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 BAF9D130DE0 for ; Wed, 27 Jun 2018 08:33:13 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=60196) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fYCRQ-0007vA-9N for doh@ietf.org; Wed, 27 Jun 2018 16:33:12 +0100 From: Sara Dickinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 27 Jun 2018 16:33:06 +0100 References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> To: DoH WG In-Reply-To: Message-Id: <0410133C-7377-468D-94F6-663F4FD55001@sinodun.com> X-Mailer: Apple Mail (2.3445.8.2) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 15:33:16 -0000 > On 27 Jun 2018, at 15:48, Ray Bellis wrote: >=20 > On 27/06/2018 14:11, Andrew Sullivan wrote: >=20 >> I am very strongly opposed to this. It would be entirely wrong for >> DoH to change DNSSEC handling in this way. >=20 > +lots. +lots again Plus, I don=E2=80=99t believe this is within the charter of the WG.=20 Sara.=20= From nobody Wed Jun 27 08:45:00 2018 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 4A9E0130DF5 for ; Wed, 27 Jun 2018 08:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 0ysY3yWL4bYW for ; Wed, 27 Jun 2018 08:44:56 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 2C80D130DF2 for ; Wed, 27 Jun 2018 08:44:56 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b188-v6so245771wme.3 for ; Wed, 27 Jun 2018 08:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tJQGm3on9qK8CXeHMjy+sy99X75q2TJZjQE+r7ixiBA=; b=aGKilpPgLCgi3CZvXn7JBlF76YKOmEZXCk6/uN2y/mWHQM/06cRxzl4reJWgNXEwyh 9haWnKE0TRJJAMZr4lN8Xi5bAdtq2LQARhrTMAbQ0ZHQKEE2yw1eiJOZn7SN1w9MKcJJ ZhmbMvNUHqT/6u03oi9pQ9uE5nclHGU7qqiF6QjWgU+QuBIn/cR9ZV+oV9qyjS4tOniP YcuitCfiJmYAp2TPyCp7qu6a6QOouN5k0PH3Iap6W1MEgKOB5bVqUya7Hg/reBcuGjLz BcvTY7A6H8Ef5Y2JMdOzP0N3qgZKTQnA7rA0Sw4GRMnB3EK69YBfEF1K3lCn+xl/0yVO bMbw== 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=tJQGm3on9qK8CXeHMjy+sy99X75q2TJZjQE+r7ixiBA=; b=SYjqWTjO4rMcDbSh3iJeabz9aFaJr+NK4UfXtruk359h/HUq++Dk9w4DH3YcykvYkQ 2TmS8XGZ64nN9UQ3IGpoDvsYsU1RadUOoegwIWuuz9Z4qv/2ixNJwOvjGfi/lpdIauUx nyCOuwEwLrjXaxkwY+oSRkGt+/NYgNniOMa4dGOs/FmSpaLt4kZJjqIMifR2oBXvripF aG2dpetnnN6BC01Lc2Rk3AV2xx2/xypYGHKrsTX0D784T3WN/G1qkb8NouZIdMGk4xg8 p2GwTMLCRuWYZllViJ+qBx189bUUeQHe1aANGhkLfNqDj+tiTh4yNX3JVFJTiqVJjxWo mcxA== X-Gm-Message-State: APt69E1AngyBziDLMMC95rILJhBsCFdupqeHuf7GzTgF9uD+pMQw/56m Y9ZF9tNVyK1l/21L5sSNSts/Mup+uMR7bop12N75Ag== X-Google-Smtp-Source: AAOMgpc7Ozlixgnb1RpDuyBLI5Pu5qy4SPTZ+j51n5oKDXBCHWZEInCndy99AQ9HAEvYhHOgnFqPNuDZhJcEMVCq590= X-Received: by 2002:a1c:2442:: with SMTP id k63-v6mr3388147wmk.7.1530114294349; Wed, 27 Jun 2018 08:44:54 -0700 (PDT) MIME-Version: 1.0 References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> <0410133C-7377-468D-94F6-663F4FD55001@sinodun.com> In-Reply-To: <0410133C-7377-468D-94F6-663F4FD55001@sinodun.com> From: Warren Kumari Date: Wed, 27 Jun 2018 10:44:43 -0500 Message-ID: To: Sara Dickinson Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000fb1455056fa17e36" Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 15:44:59 -0000 --000000000000fb1455056fa17e36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2018 at 10:33 AM Sara Dickinson wrote: > > > > On 27 Jun 2018, at 15:48, Ray Bellis wrote: > > > > On 27/06/2018 14:11, Andrew Sullivan wrote: > > > >> I am very strongly opposed to this. It would be entirely wrong for > >> DoH to change DNSSEC handling in this way. > > > > +lots. > > +lots again Me too! > > Plus, I don=E2=80=99t believe this is within the charter of the WG. Agreed. W > > > Sara. > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000fb1455056fa17e36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed,= Jun 27, 2018 at 10:33 AM Sara Dickinson <sara@sinodun.com> wrote:


> On 27 Jun 2018, at 15:48, Ray Bellis <ray@bellis.me.uk> wrote:
>
> On 27/06/2018 14:11, Andrew Sullivan wrote:
>
>> I am very strongly opposed to this.=C2=A0 It would be entirely wro= ng for
>> DoH to change DNSSEC handling in this way.
>
> +lots.

+lots again

<a= ol>
Me too!
</aol>



Plus, I don=E2=80=99t believe this is within the charter of the WG.


Agreed.

W


Sara.
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--
I don't think the execution is relev= ant when it was obviously a bad idea in the first place.
This is like pu= tting rabid weasels in your pants, and later expressing regret at having ch= osen those particular rabid weasels and that pair of pants.
=C2=A0 =C2= =A0---maf
--000000000000fb1455056fa17e36-- From nobody Wed Jun 27 09:03:19 2018 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 4547D130DF7 for ; Wed, 27 Jun 2018 09:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 caiMv6FE0qvt for ; Wed, 27 Jun 2018 09:03:13 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 D3E00130DEE for ; Wed, 27 Jun 2018 09:03:13 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 16-v6so8302666itl.5 for ; Wed, 27 Jun 2018 09:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5hjV6E/mSUk3XiV6u7BC1rzHTgDTDJdvyi9zW3IG0Hk=; b=Wovcz1F7ogpDP2W8pnyHVGVWvIa1fJlsTq8CIkPNdGVz5rKlRRc6SwJX2iqZIyIE8L KTL+mLwfPdDh/8ADrzTCpxZNFzt3PI2stNI+OtTvObWyHbxsVv01blMnygKGGTLzmyiV 448N2e3B+o9m5I9rxP0PP+cNwHQhNSLgiNdKyW2Pg0hbSCeIm1X6dX8fHV/+tqim8ZK+ Eu4vHhzwnn/6MgCH1V/eFGUXRrYhU+C92KP08hpETGtsMespNGmPFFdnkYkJV8UunGIJ +asKYK9MktkVh5IB4x13YtV2QYM3625nlih7SxW99o+NpHheYyrlbHqafq2A9t0kiMC9 jXKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5hjV6E/mSUk3XiV6u7BC1rzHTgDTDJdvyi9zW3IG0Hk=; b=dOVka8Sk8hH4JKEaEl2ay3crK71M0UTQNi5L8O3MuNbC79wTuc42KnXbhEXwcLEd6b BDjbD4Yu6AmSKjrV8Uj1idmEZjZPn9f3awULCkG9tXXB2b4vzbwma68D5P8TbWTEE0GW KG9vmsK7cSUKxwckxtmOqlghQzefY1Wl+aCJQLvlyzcL0uQHblIMECvpwTDZGjqDbXfn sw0mIiJF4ddSFWuvF3COPPaXvMp5pfAWKx+eQl47bttVMg5sObgVsR78DO/CRTyyOTcC UBKa6vuOZzFTPnNEyqNsjKbkEJ+KYVmg4xrw3xCk3zk0BTLMkd5JjvCpkEi3Q/07CvuH D8cA== X-Gm-Message-State: APt69E2qLSIwhvbdxuitfMo9QxeQC4Qfa3H7LX6hbdXMDV7tP7mCHD8j menJNXJ1t5MVGXO/FBkbrz817rdYKzfccuxWU8lTeA== X-Google-Smtp-Source: AAOMgpdAxqtxgpRbLoFrVBdYlf4F4FpqXFw19MEtxXcow+0a3s4YchLWLoJSe2QljdatfB/MVNYCHLuhBCiHZqBnIrE= X-Received: by 2002:a24:8988:: with SMTP id s130-v6mr5453662itd.144.1530115392868; Wed, 27 Jun 2018 09:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5406:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 09:02:32 -0700 (PDT) In-Reply-To: References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> From: Ted Lemon Date: Wed, 27 Jun 2018 11:02:32 -0500 Message-ID: To: Ray Bellis Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000754168056fa1c016" Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 16:03:17 -0000 --000000000000754168056fa1c016 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hrr. I get that it feels wrong for DoH to change the resolver trust model, but I agree that the trust model is wrong. The only reason to ever trust the AD bit is that your communication with the resolver is authenticated such that you know that you are talking to the resolver and not an attacker. This is difficult to do with TSIG=E2=80=94it requires th= at every client have its own key, and that TSIG be configured on the client, which is never the case. So the set of situations where the AD bit can actually be trusted is actually very limited. Saying that "you should not trust the resolver in this case" represents an incorrect mental model of how this can work. There is no person who is making trust decisions here. Either the software trusts the resolver on some basis, or else it does not. Interestingly, DoH in principle provides a basis for trusting the resolver: you can validate the resolver's TLS cert, and that cert can be marked "trust" or "don't trust" and then the software can automatically implement the trust decision configured in the user interface. So a better approach than saying "don't trust the AD bit" would be to say "here is what is required in order to trust the AD bit" and then state that explicitly, and by default say that the AD bit should not be set, and should be ignored if set, when such a trust relationship has not been validated. I really don't see any reason why the document should not do this. If you are strongly opposed to this as well, it would be good if you could give some reason other than "this is the way we've always done it" or "the user knows." On Wed, Jun 27, 2018 at 9:48 AM, Ray Bellis wrote: > On 27/06/2018 14:11, Andrew Sullivan wrote: > > > I am very strongly opposed to this. It would be entirely wrong for > > DoH to change DNSSEC handling in this way. > > +lots. > > Ray > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000754168056fa1c016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hrr. =C2=A0 I get that it feels wrong for DoH to change th= e resolver trust model, but I agree that the trust model is wrong. =C2=A0 T= he only reason to ever trust the AD bit is that your communication with the= resolver is authenticated such that you know that you are talking to the r= esolver and not an attacker. =C2=A0 This is difficult to do with TSIG=E2=80= =94it requires that every client have its own key, and that TSIG be configu= red on the client, which is never the case. =C2=A0 So the set of situations= where the AD bit can actually be trusted is actually very limited.
Saying that "you should not trust the resolver in this cas= e" represents an incorrect mental model of how this can work.=C2=A0 Th= ere is no person who is making trust decisions here. =C2=A0 Either the soft= ware trusts the resolver on some basis, or else it does not.

=
Interestingly, DoH in principle provides a basis for trusting th= e resolver: you can validate the resolver's TLS cert, and that cert can= be marked "trust" or "don't trust" and then the so= ftware can automatically implement the trust decision configured in the use= r interface.

So a better approach than saying &quo= t;don't trust the AD bit" would be to say "here is what is re= quired in order to trust the AD bit" and then state that explicitly, a= nd by default say that the AD bit should not be set, and should be ignored = if set, when such a trust relationship has not been validated.
I really don't see any reason why the document should not = do this. =C2=A0 If you are strongly opposed to this as well, it would be go= od if you could give some reason other than "this is the way we've= always done it" or "the user knows."

On Wed, Jun 27, 2018 at 9:4= 8 AM, Ray Bellis <ray@bellis.me.uk> wrote:
On 27/06/2018 14:11, Andrew Sullivan wrote= :

> I am very strongly opposed to this.=C2=A0 It would be entirely wrong f= or
> DoH to change DNSSEC handling in this way.

+lots.

Ray

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--000000000000754168056fa1c016-- From nobody Wed Jun 27 09:05:37 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5867B130DF7; Wed, 27 Jun 2018 09:05:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153011553033.15468.17520622437264456798@ietfa.amsl.com> Date: Wed, 27 Jun 2018 09:05:30 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-12.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 16:05:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS (DoH) Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-12.txt Pages : 21 Date : 2018-06-27 Abstract: This document describes how to make DNS queries over HTTPS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-12 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 27 09:15:34 2018 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 2E0FA130E1E for ; Wed, 27 Jun 2018 09:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_MED=-0.01, 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 qNhNt1VvwTG9 for ; Wed, 27 Jun 2018 09:15:30 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 B3509130E19 for ; Wed, 27 Jun 2018 09:15:30 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id e15-v6so2434064iog.1 for ; Wed, 27 Jun 2018 09:15:30 -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=7fYDXC7c+H0zQwspfDy8ZCQOuDaYwkc3FmQLMIvtFTU=; b=QUpP7Y+5jQJ3x9nb7G9Ay67VFcnPkVMpnQkD/sJIh+6HE8O+jV3qKicSF93uN+FWZJ GygPmHMVv6AAjs7OhoEbe7HU4+e4aqkkhzUsoGgH9zMeEkrNB1TQmxngmpaOqEpZ2tQ4 0paQDzry5yiiEq0HwewPP+ANqdv5mr4dj0Smu9YC9+cn44ZEUMScAb3eg0VfK7y1Fu6K 72+FsslYhw9NP8keIBq8Fi15Z4scTVmqXHtfQU2JzvxFjNCjkh8VGCJLfFQtxlrqFBGU IFayy15RFQPPIq8u4Zqah5fiBKEfCImXbvo7OG7GtCDa5H9cl4QoSROGnfVGMymB/FNR WBBg== 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=7fYDXC7c+H0zQwspfDy8ZCQOuDaYwkc3FmQLMIvtFTU=; b=HhzpBUQD3Yi28vsbV+6QScI3XO9fFnHPYwNmQC3mwsz06Ir5QEGT497B+QRu/AfCIy Cydt5MILGAN88iZdmtLL1cf5EgF4wK+R9OoaT9jXpe4gI43S3EPY/Zu+z+gpbcPwIVEm 87OjetlV/2CI/1dysQaLfVqs/5qZNhYWomvxjVf5SNR5x8YkFzAl80GYiEcx4WDfL5OF 7JnyE34IgAzYhXQn938/7GcnsP2eswJQPBKdVEChU67EHRyx01ilAQKeTOr+KkTeJp/u Erw1sR28wCl/5cxF7WSMEVfe7lRJG6RRbAUFLpsmV9PJRH7fTSWikIlnhwRLSl6e5XEZ vNoA== X-Gm-Message-State: APt69E3RlU/RLN6Kk6ET2NJoQ/NDXV6iaEI2t+pcJO42EM0y3YNmb8rD ejzoGG7rg2pueicUCX73miDywfA6ZYqvs36+74uUrrp2 X-Google-Smtp-Source: AAOMgpcieF/8FqRhkYCeHe0kzfgpqeP7Y4ufOAnWPkSknYSKKBY0kv5QUMSSd+JprJUNWlweseeo17saQw9lXX1azIU= X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr5224396ioh.235.1530116129539; Wed, 27 Jun 2018 09:15:29 -0700 (PDT) MIME-Version: 1.0 References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> In-Reply-To: From: Ben Schwartz Date: Wed, 27 Jun 2018 12:15:18 -0400 Message-ID: To: Ted Lemon Cc: Ray Bellis , DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000067e8ac056fa1ec01" Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 16:15:33 -0000 --00000000000067e8ac056fa1ec01 Content-Type: multipart/alternative; boundary="0000000000005e5b49056fa1ec39" --0000000000005e5b49056fa1ec39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2018 at 12:03 PM Ted Lemon wrote: > Hrr. I get that it feels wrong for DoH to change the resolver trust > model, but I agree that the trust model is wrong. The only reason to ev= er > trust the AD bit is that your communication with the resolver is > authenticated such that you know that you are talking to the resolver and > not an attacker. This is difficult to do with TSIG=E2=80=94it requires = that every > client have its own key, and that TSIG be configured on the client, which > is never the case. So the set of situations where the AD bit can actual= ly > be trusted is actually very limited. > > Saying that "you should not trust the resolver in this case" represents a= n > incorrect mental model of how this can work. There is no person who is > making trust decisions here. Either the software trusts the resolver on > some basis, or else it does not. > > Interestingly, DoH in principle provides a basis for trusting the > resolver: you can validate the resolver's TLS cert, and that cert can be > marked "trust" or "don't trust" and then the software can automatically > implement the trust decision configured in the user interface. > > So a better approach than saying "don't trust the AD bit" would be to say > "here is what is required in order to trust the AD bit" and then state th= at > explicitly, and by default say that the AD bit should not be set, and > should be ignored if set, when such a trust relationship has not been > validated. > I think that this is an interesting line of reasoning, but I believe that it is outside the scope of this working group. I really don't see any reason why the document should not do this. > DNS over HTTPS will be, to the best of my knowledge, the third standardized transport for DNS with TLS certificate validation, after DNS over TLS (RFC 7858) and DNS over DTLS (RFC 8094). There may well be yet more authenticated transports defined in the future. Your proposal here applies to all authenticated transports, not just DOH, so it is not suitable for this document or this working group. I would be interested in seeing your proposal in DNSOP, where there is more expertise on the likely impact of a change to the specified usage of the AD bit. > If you are strongly opposed to this as well, it would be good if you > could give some reason other than "this is the way we've always done it" = or > "the user knows." > > On Wed, Jun 27, 2018 at 9:48 AM, Ray Bellis wrote: > >> On 27/06/2018 14:11, Andrew Sullivan wrote: >> >> > I am very strongly opposed to this. It would be entirely wrong for >> > DoH to change DNSSEC handling in this way. >> >> +lots. >> >> Ray >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000005e5b49056fa1ec39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Jun 27, 2018 at 12:03 PM Ted Lemon <mellon@fugue.com> wrote:
<= div dir=3D"ltr">Hrr. =C2=A0 I get that it feels wrong for DoH to change the= resolver trust model, but I agree that the trust model is wrong. =C2=A0 Th= e only reason to ever trust the AD bit is that your communication with the = resolver is authenticated such that you know that you are talking to the re= solver and not an attacker. =C2=A0 This is difficult to do with TSIG=E2=80= =94it requires that every client have its own key, and that TSIG be configu= red on the client, which is never the case. =C2=A0 So the set of situations= where the AD bit can actually be trusted is actually very limited.
Saying that "you should not trust the resolver in this cas= e" represents an incorrect mental model of how this can work.=C2=A0 Th= ere is no person who is making trust decisions here. =C2=A0 Either the soft= ware trusts the resolver on some basis, or else it does not.

=
Interestingly, DoH in principle provides a basis for trusting th= e resolver: you can validate the resolver's TLS cert, and that cert can= be marked "trust" or "don't trust" and then the so= ftware can automatically implement the trust decision configured in the use= r interface.

So a better approach than saying &quo= t;don't trust the AD bit" would be to say "here is what is re= quired in order to trust the AD bit" and then state that explicitly, a= nd by default say that the AD bit should not be set, and should be ignored = if set, when such a trust relationship has not been validated.
<= /blockquote>

I think that this is an interesting line of= reasoning, but I believe that it is outside the scope of this working grou= p.

I really don't see any reason why the document should not do this.

DNS over HTTPS will be, to the bes= t of my knowledge, the third standardized transport for DNS with TLS certif= icate validation, after DNS over TLS (RFC 7858) and DNS over DTLS (RFC 8094= ).=C2=A0 There may well be yet more authenticated transports defined in the= future.=C2=A0 Your proposal here applies to all authenticated transports, = not just DOH, so it is not suitable for this document or this working group= .

I would be interested in seeing your proposal in= DNSOP, where there is more expertise on the likely impact of a change to t= he specified usage of the AD bit.
=C2=A0
=C2=A0 If you are strongly opposed to = this as well, it would be good if you could give some reason other than &qu= ot;this is the way we've always done it" or "the user knows.&= quot;

= On Wed, Jun 27, 2018 at 9:48 AM, Ray Bellis <ray@bellis.me.uk> wrote:
On 27/06/2018 14:11, And= rew Sullivan wrote:

> I am very strongly opposed to this.=C2=A0 It would be entirely wrong f= or
> DoH to change DNSSEC handling in this way.

+lots.

Ray

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000005e5b49056fa1ec39-- --00000000000067e8ac056fa1ec01 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDvtOr1xfnQJwWJES1B/vdM ahssSFYe7VnHZChVqbGH6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA2MjcxNjE1MzBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGUfaPRHWg86bQP1VeBe6/SfiAnxS4a4uR7t6ZmRq 4H0B6RbifOg0jSRiY1wAun87AcQF5xOzgMQMeCVUo/voTDLWXEsQomd1ZcXp32txkrM0VZ8kyVf3 EYVSPntC91O92p4VIVVJ2SZ1sZaoC0FQbmBZc2XqX88qVBRJn0w6SJonBqniCtUReMUV5xFs0Z89 ydysDOVks5l6HKv/+NPKuVRQ4y+BCNUlJgrz09YfbBzSRbEo+qVowSthLAa76kOl7YpnTl8WGsg6 jxlwtINz0JH1zfKCllX5sR7UzT8geW2UM/m3OPmrpU3zCNNxAwXAlu64hSFpWxhI67wvY2+0Uw== --00000000000067e8ac056fa1ec01-- From nobody Wed Jun 27 09:19:17 2018 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 2AEA9130E1E for ; Wed, 27 Jun 2018 09:19:16 -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=yitter.info header.b=c7EQjVNs; dkim=pass (1024-bit key) header.d=yitter.info header.b=C6IX3kKd 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 bAKTvHo1piZX for ; Wed, 27 Jun 2018 09:19:14 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0627E130E19 for ; Wed, 27 Jun 2018 09:19:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 47B97BE444 for ; Wed, 27 Jun 2018 16:18:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530116323; bh=3ManU1nDD742CbnpAfNTiHCmAuMKByGNzU1Pri+AlGg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=c7EQjVNsKlN/0EH77NesjemCJgCr/AJWb588OdhL7A4g72kMHUjaDAVk4q0LAebdq Z71diCFO4s3miU58HKqIulk6Rki2wpC4dPil1DieAeVtl2NbQHGKeYvrscnH5UOH5v lwRnZwGTCd0x2F0JVQyckrgto0StieE4TKtASx8U= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT6gvD_bopkp for ; Wed, 27 Jun 2018 16:18:41 +0000 (UTC) Date: Wed, 27 Jun 2018 12:18:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530116321; bh=3ManU1nDD742CbnpAfNTiHCmAuMKByGNzU1Pri+AlGg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=C6IX3kKdLibJulMBeypIOycMpJjc0MpvK4cJTQqPUMDWAqDXlLMHN57ZtAYFvuJv9 3Fv0QkKHKgp5sb9gMgePPqTKsr0rCw4fEh/PQVfM5z1yoh+ziSbDnPKBHM4htU+Y1b XrFhVPE5YjjiOAyVx9ZGsYp3rV6RStlpx+8tSuik= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180627161839.GZ22421@mx4.yitter.info> References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 16:19:16 -0000 On Wed, Jun 27, 2018 at 11:02:32AM -0500, Ted Lemon wrote: > Hrr.   I get that it feels wrong for DoH to change the resolver trust model, > but I agree that the trust model is wrong. If you are using a random resolver that you got from DHCP, I agree that the trust model is entirely wrong. But there are other ways to get configured. And note that you are _supposed_ to configure your DoH resolver, which is a debate we already had. If you did, and you have validated the certificate and all that, then the trust model with AD is not wrong. > that TSIG be configured on the client, which is never the case.   So the set of > situations where the AD bit can actually be trusted is actually very limited. One that I know Microsoft was proposing at one point was an enterprise environment where IPSec is in use and secure communications are established to a domain controller that provides the necessary configuration. > Saying that "you should not trust the resolver in this case" represents an > incorrect mental model of how this can work.  There is no person who is making > trust decisions here.   Either the software trusts the resolver on some basis, > or else it does not. Yes, and there are ways that you _could_ be configured in which the software can trust the resolver. (I was speaking colloquially when I said "you".) > Interestingly, DoH in principle provides a basis for trusting the resolver: you > can validate the resolver's TLS cert, and that cert can be marked "trust" or > "don't trust" and then the software can automatically implement the trust > decision configured in the user interface. Yes. > So a better approach than saying "don't trust the AD bit" would be to say "here > is what is required in order to trust the AD bit" and then state that > explicitly, and by default say that the AD bit should not be set, and should be > ignored if set, when such a trust relationship has not been validated. I am not the document editor, but I can see how such text could be useful in the Security Considerations section if someone were to prepare it & submit it for consideration. I don't especially think it is needed, however: I don't think DoH adds anything special to the AD bit handling. You should only trust the AD bit when you can trust the resolver and trust that your hop to that resolver is properly secured. That was always true, and remains true now. RFC 4035 has this to say about it: In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel. I don't see what's new here. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jun 27 09:34:56 2018 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 AE79C130E60 for ; Wed, 27 Jun 2018 09:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de 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 kXy4Fl4mjKTR for ; Wed, 27 Jun 2018 09:34:51 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 128A0130DEE for ; Wed, 27 Jun 2018 09:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:From:To:Subject:content-disposition; bh=5UKdKiEy+NkKJ/Cs8DkT/oeK2m7nXAqsaez4TI7H2aY=; b=Yz0onEIKrpaD1z4TIVn3OJo8vj /FTOlPVX3Ri1lJtwnT75XXZSCoNg5qoVtr+kmG2NY8UGYRIzUwiVoy5Eqnt0EtETw1CLGpnthpi1g aXwpl7fcLOiVxZMqBNhCnthfPSEezoJQ+1qszCipi9CxvesO0UCMXhty0fXHCzrxbcd1omLxP3zl1 1sQ2vjawNUHdnAu2Tl1karNHo7/lHQA/xoyO9OWMKNAvmbZ4AA6h4id6rKF6y+7lueOp3beNwoca9 gikdazEFp7CHPcGpF73SQTbPlDCuLDppycEm/DekAb0STRuqioxUdlfECVCRP/gbwO12KxLSTvQTQ iIUi7+wiwNlDuIGTXu3mWZIUMppLUVITRp4ZGECjfufYT9zyxQV6xBdlzs4Zm2UJyy8ExNa0gHqvW OZ9+gArOmp5zfZNDjQYjVZPJrBezGGV+bPRunhHhYhnvmhECOn8l8UjQIA7mKY3caHdD2mTJkCp3d dMl3BJUTpXgsszdv/JurEOjCl20cG221SQzPRQt3fLOSDtSo08C5UrSTlLKCAaBOWF/LJVTX0JEc2 2comhFz3VCqogoY96mtJL9S64us/Kk2gigBc8+xdjfgLfzUBBHSCo8jJJD5JHOoSXCWR8XW1mFH+I L0/NXx5D9ZUP40o4mRuGrKN4l6OukKvvD1kCPHI0k=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fYDP6-0000M7-FD with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Wed, 27 Jun 2018 18:34:49 +0200 To: doh@ietf.org References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> <20180627161839.GZ22421@mx4.yitter.info> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Wed, 27 Jun 2018 18:34:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180627161839.GZ22421@mx4.yitter.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 16:34:54 -0000 Am 27.06.2018 um 18:18 schrieb Andrew Sullivan: > RFC 4035 has this to say about it: > > In any case, a security-aware stub resolver MUST > NOT place any reliance on signature validation allegedly performed on > its behalf, except when the security-aware stub resolver obtained the > data in question from a trusted security-aware recursive name server > via a secure channel. > > I don't see what's new here. > The fact that e.g. home router vendors define the DSL line and the network path to the resolver of the ISP as trusted to print 'DNSSEC' on the retail package without having to develop a full DNSSEC implementation for the router. Best regards, Renne From nobody Wed Jun 27 09:46:08 2018 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 242D2130DFE for ; Wed, 27 Jun 2018 09:46:06 -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=yitter.info header.b=d1HTejwi; dkim=pass (1024-bit key) header.d=yitter.info header.b=gErLJIOZ 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 VQakM5cvsVIk for ; Wed, 27 Jun 2018 09:46:04 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC88130DEE for ; Wed, 27 Jun 2018 09:46:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 5EB5EBE444 for ; Wed, 27 Jun 2018 16:46:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530117963; bh=O2xl3IZ7+5m+Cd2S7P6+oRQSinfUzj05Ndttus/H3C0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=d1HTejwiRtYBuJ8LuoOVsuiGXLZ0ctUd7UkGHBAL1CpjBDr2d4lG8auVzM+lLKq9Z toQ02Bi9Rx1uj3CfYUk9y1+S3wMFht9sQ9CQtfpxB8ydj+H7XHl/BOADIj+IW230Bh e5OPCPKo69na6nQvjBsQk6P8IkpuumPnCfsF/ed4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf67XFHE9BIQ for ; Wed, 27 Jun 2018 16:46:02 +0000 (UTC) Date: Wed, 27 Jun 2018 12:46:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1530117962; bh=O2xl3IZ7+5m+Cd2S7P6+oRQSinfUzj05Ndttus/H3C0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gErLJIOZdJ+YxMHgHFiVUqrwcjOb4sLODtrZu7uach3WKS1LlqFThEXeWxHB5zVIX yoITrTKSxklGdoU4aJVAumuChaGJfDb70VtUTHgL7rAkH+JidU9rEZr7kbSYc8eYWH OBHhiL59zwH3OPqdf1dxvsbn0umGzgMNCqoCO5ls= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180627164600.GB22421@mx4.yitter.info> References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> <20180627161839.GZ22421@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 16:46:07 -0000 On Wed, Jun 27, 2018 at 06:34:47PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > The fact that e.g. home router vendors define the DSL line and the network > path to the resolver of the ISP as trusted to print 'DNSSEC' on the retail > package without having to develop a full DNSSEC implementation for the > router. What's new about that? Why do you trust such a resolver? People have always been able to lie about what they're doing -- that's the whole point of the text in RFC 4035, and why you are in a position to do validation yourself anyway. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jun 27 23:38:02 2018 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 523E5130E7A for ; Wed, 27 Jun 2018 23:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 hAhtniSF8Wg9 for ; Wed, 27 Jun 2018 23:37:58 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 25D0E130E25 for ; Wed, 27 Jun 2018 23:37:58 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id b10-v6so2968350otl.10 for ; Wed, 27 Jun 2018 23:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sL90YGtaNTODucSqhpWbEcBpHKF4XejhQo0KMKMIxJg=; b=FRtrxMZwQTECNTuhHpgkiTmZGCUreRaivbWBuA+6clIRDBPbQnqjW5TbpsFmUDmwDM RbkcCniPRv5zk8y4iE0WffyYRoxCUjR0XFOokUe2qR2J0hu+K+tkYznJkfG5gIBbwmi1 KsOj94ci7Jip4sYfnaYOt960OkDn/p93XdiE83kLuSwq1HAoWgQ853/guWSyGhZVwKIp CgqE1BweimtfHk6g3YQuDhjF0kmhmmdUYodSp4gXs1/tUbJ5sppO4rPTMHFeYuLKGFz0 DoUkVgrwN9mjCE1wTZRF3shvcZtuhjtkwZ9fKRgwT8YvDKdsSy3TkDIcrYFFWUsbZyWN wvSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sL90YGtaNTODucSqhpWbEcBpHKF4XejhQo0KMKMIxJg=; b=MNSZdD0D/AA+C7jG6RiU46beA2//2Y0vb8lsVtAivdoB2r5oRFXQY7mnm299G78e61 cROt3cRoQ7HrgTUaQySiRlugvwuZQYKY2o5pgLTKakKocARPniFS98/rSSJxiqeNw951 llDt02fH4Yw78W/JfQ772r5vKKwb7jtgIAJw4PxmBU7li8eOigyky/C+t3928RjoUE2T WGk5PvGCZLWY9/KYCLgP9Hh5Fo/IAonAefV5qNC1trNUmZ0mvXFTYfAGucuvz8fE2rjX hvMJkw5WYtOVv6b1bqgaffdWB4HWN5tVSlG0Ua57aEQBBOrnK9WLIBqzNTZMvW67gekm zvzw== X-Gm-Message-State: APt69E3/RLWI9RhKpsXqaR0OEKsWJeMbAyR2B8CNGIpbBLyXYuRM7C/N y5EVjYzgSKzqbRHj8d3/4KmFiwWSH5802TlvfSk7g0f8 X-Google-Smtp-Source: AAOMgpcnlLH/0DjcpT/48GOBEsZvkmumb5xr42Z42RQEnV4aqdbnBhaEjjAJEBCJ75BOzLyrS46f/4w6XN7Tkc8JcKc= X-Received: by 2002:a9d:1a0e:: with SMTP id a14-v6mr5723286ote.314.1530167877597; Wed, 27 Jun 2018 23:37:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:ad8f:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 23:37:56 -0700 (PDT) In-Reply-To: References: From: Loganaden Velvindron Date: Thu, 28 Jun 2018 10:37:56 +0400 Message-ID: To: Patrick McManus Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] New Privacy Considerations Section Proposal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 06:38:01 -0000 There is the mention of padding which was added in the security section. RFC 7830 talks about padding but does not mention padding length. I've made a PR here for pointing to draft-ietf-dprive-padding-policy which discusses padding length choices: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/207. From nobody Thu Jun 28 03:24:26 2018 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 95665130F2C for ; Thu, 28 Jun 2018 03:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 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] 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 v2ty4Enb24vK for ; Thu, 28 Jun 2018 03:24:22 -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 E04A61274D0 for ; Thu, 28 Jun 2018 03:24:21 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:c881:de7a:1f41:9139] (unknown [IPv6:2001:67c:1220:80c:c881:de7a:1f41:9139]) by mail.nic.cz (Postfix) with ESMTPSA id 282BD60600 for ; Thu, 28 Jun 2018 12:24:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1530181460; bh=fdpP3DPke2AbAYaFB4urC68shoyOx40wX10m9WTcf54=; h=To:From:Date; b=d+xI4y4l2EdNm76QB+g+D9i9wmZgboRXOoOzkSt+PtHsAw8U26dJpO8NhQgWukFtr /lWK5S/CJCtxXpRYZIO2S/t8mHz2czFniZmcx1NXRmEYCvbDgoeDy0F7hqS6s0VjDW 5PjvnuQUPQvHLUU1X0EyzBmwdSI2/TE2mTVCCW0o= To: doh@ietf.org References: <01d7c5ff-fd05-d0c8-b243-78b1b5762cad@bartschnet.de> <20180627131102.GO22421@mx4.yitter.info> <20180627161839.GZ22421@mx4.yitter.info> <20180627164600.GB22421@mx4.yitter.info> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Openpgp: preference=signencrypt Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= xsFNBFhri/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+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABzSJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+wsF9BBMBCAAnBQJYa4wfAhsDBQkDwmcABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEM6N1qGlCiHkjGoP/3fvimzczcaqPM8lgY9fKKcr2DhH 42HF+fXsj0SvPeEoYDuWwIcsTGna6sdmrhCD/mB6eCNivAOcZYDH7j3YDgdFX2xy1sRY0ylF uyfcOT1Qn1xNTglSaf00gUWDgLBQB/USphB9Of6U1ka4gLJpCWKoZ3cLQe09cUpq9HOZYs/g WSNx9UTr06fcO0rtgZpg+IZJN/R2ORhQBwk4n2Dtx5J+Xyoy7ht1Fwz07BWAGJ4P8oJOhsi1 LukDD8ul3+6IeoSbRvyGpP6boegaMwxPR10VgsrYU2t1cK58iRv/xJ3TClb0JBn5aI3Bmh1j mPROrC55tvxRoeRLmxXHzbPZpWdbRjEcf9SEiAGNTgo9C+eXbubeSETWgisfJhZ4ebhkHnfz e+e+hvbaTSoFyMbKeOlfoYCmaDRBgT53i72HIkvO+HrVcmulZytw/yyOHuwObEFVgn3AeORv rb8I1kiv5W4wnZxDslhCeRR+wMGiKhc9ewU/mg3Rqo6GN+8mT0DHnsHuq1lu3WYslfNYkBSo nFcctFD2KXVozrwpn3vWJ4Qt6qu5XS1lDCD5WshZXh7qoISWnnMqsMyBW/R7WyiABeIz4uOg SkRwT2wSUYr+JtBZIjREy2JQDVhjf18DL1Qa7OxSes8YwWSx1pQAzwbfFx0gzRDyIT/39le4 pX430yTQzsFNBFhri/0BEADFp4ZfxSoKTAad0IkFK9CVoZ6XKywYLFNPPhzw++gbvHL2EX7Q qhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQou0FeSNnzRGb607U8OFOPQ+ei92Mm 1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkhwtWU/6yo+RZs7cFRuihuLl8FuoP0 A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAwGDtjWkBVawpoHWwq58OQSx5piwyO CnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdWJw5OV9BoA7UTHG95xVHV5QiEm6q6 igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8mmKyS8E+mSh3djmqdJNHF1pJqKxA xPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03duzocyU95DfP/lwNJr5SH918Vf1t7 WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkSeXNoMlHJOIqbqm7N414I0HytbENf 7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw3f3Gn3+PDzGEHI9sfQv/mYvO77oR SGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6IfZZ0OIWKLSRa/DQARAQABwsFlBBgB CAAPBQJYa4v9AhsMBQkDwmcAAAoJEM6N1qGlCiHkn54P/AgyzrffYzRq6d7vHfFhd8HzHHrU BtOK+5182DME1JX9Aow5Dy9kbfxAfTc4tbCY5EnhoUICbmVAJ5wL5lrGxQPSnulIyF8OmJjc VlGI6zXYvP0VHZ/L8dPcf+RPqhMCPpaxe2+h5XpPxvOkDLlnCrsA4J1bAGW5kpxdGnY4aRrv aKhtGMqgSwSx25l3RnoOROU/hTDV4EHCuTkMRfILmsuNT7It40iL5nyDiJ8o3p1CLjRwUzVn 4r4jE8DXhbWXaKJ0KQZpKiQDVV7qJcJIeBJvZpFfxJ44LxBct9TkC69ROntYhd6M7031DT3P IYW9VyMhLN5dRfzhEdFUc+3AlnoOOKcGwYiCnH2DwDva3ZicOAH8099mWZcwVL/sjKKbJGPo JbdT9C3gSnsoa3uBbsiChRhAno80Jsk/igb4QaMw4PsS3230kfBGkQ/oAPPM0iJ9kn8NXB/9 iBe5cKEUiiYQfSn9x1HyG0sT3/jSYaq3obmBNHJE24w/RKWoPsaKjoyaInAuU5L0cNZ30OWd eWFREIxlajFl2vXb9nCc80/i6PceJySiyJgd5cYEL4hfn/B6RXph9kAJySsqlIZoBhcwneGX mAS0M41jJjuIQdt5pkLhM9XoXjBFMGGtA/CtiicEgitItJfVCxdLG4bZOCrfPmevMGLxpEmB GouQ9dVQ Organization: CZ.NIC Message-ID: <402d115f-cce9-d81f-5a5f-45de8226667f@nic.cz> Date: Thu, 28 Jun 2018 12:24:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180627164600.GB22421@mx4.yitter.info> 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] Ignore AD (Authentic Data) bit X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 10:24:25 -0000 On 27.6.2018 18:46, Andrew Sullivan wrote: > On Wed, Jun 27, 2018 at 06:34:47PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > >> The fact that e.g. home router vendors define the DSL line and the network >> path to the resolver of the ISP as trusted to print 'DNSSEC' on the retail >> package without having to develop a full DNSSEC implementation for the >> router. > > What's new about that? Why do you trust such a resolver? People have > always been able to lie about what they're doing -- that's the whole > point of the text in RFC 4035, and why you are in a position to do > validation yourself anyway. +1 I fully agree that DoH does not bring anything new with respect to AD bit. -- Petr Špaček @ CZ.NIC From nobody Fri Jun 29 08:33:57 2018 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 CA18612D7F8 for ; Fri, 29 Jun 2018 08:33:55 -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, FREEMAIL_FROM=0.001, 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 cnUbO_JyA5Bq for ; Fri, 29 Jun 2018 08:33:53 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 DBE88126CC7 for ; Fri, 29 Jun 2018 08:33:52 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 30929 invoked from network); 29 Jun 2018 17:33:48 +0200 Received: from acpr178.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.223.178]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 29 Jun 2018 17:33:48 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Geert Stappers , Nicolas Cavallari , DOH Cc: dnsmasq-discuss@lists.thekelleys.org.uk, Kurt H Maier References: <360883b6-2d1a-a68b-81a2-c7902e29e0f2@o2.pl> <20180614203224.GA45519@wopr> <7da6219a-9ceb-4563-5077-116b6dec6f96@green-communications.fr> <20180620085756.GY30489@gpm.stappers.nl> Openpgp: preference=signencrypt Autocrypt: addr=mat.jonczyk@o2.pl; prefer-encrypt=mutual; keydata= xsFNBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/qDoPh52f ExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkxJww5X/2ZAtFjUJxO QjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOadTy5hvwv0rjNjohau1y4XfxU DdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSEAhs2rOTN6pnWJVd7ErauehrET2xo2JbO 4lAv0nbXmCpPj37ZvURswCeP8PcHoA1QQKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzg jxSYVZRAWVsdNakfT7xhkaeHjEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7yln DRrda+1EVObfszfBWm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnS RP/s9t+C8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaGDhVeLUVF Q+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQABzSRNYXRldXN6IEpv xYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD7CwX4EEwECACgFAlqMDyQCGwMFCRLMAwAGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhhCv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI 1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsUUAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52 hZxMsCQyzjGOcBAi0zmWGYB4xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU 9bzFCyqZ8kAqwOoCCx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3 ADg8sGuq4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbydWVke0FSR AzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFjGdeeggv668M7GmKl +SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXCVEwW4q17v8gNsPyVUVEdIroK cve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOWmyzCLQ1YoUZMxH+ddivDQtlKCp6JgGCz c9YCESxVii0vo8TsHdIAjQ/px9KsuYBmOlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7I U16IAtK5b7RpzsFNBFqMDyQBEACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+p Bw5/D2ruHhj1Bgs6Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01 ltYrMYV1IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv830ZCQ5Ds U0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2ISO0OAAMBKea7slr mu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJFyiZ0vYAUTwtITyjYxZWJbKJh JFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S4 16W9lBDJeHhmcVOsn+04x5KIxHtqAP3mkMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXf kgWJtW+JziZf6LYx4WvRa80VDIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9Sm kfTFrHOgiTpwZnI9saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABwsFl BBgBAgAPBQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbljJusw6xQ iKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbHb1GJtLF5HyI1q4j/ zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9mmDLEwO4ULK2quF6RYtbvg+2 PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dEjTx+uYCWpvcw3rRDz7aMs401CphrlMKr WndS5qYcdiS9fvAfu/Jp5KIawpM0tVrojnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y 6LHzJWsnLnL1o7MUARU++ztOl2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuw gF7DbkdscM7fkYzkUVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X2 0nI2LedLnIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fww8Ihl8aS TANkZ3QqXNX2 Message-ID: Date: Fri, 29 Jun 2018 17:33:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180620085756.GY30489@gpm.stappers.nl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6ay8EiRezw8hBg2Qr2QlTxe3tdNrhal0k" X-WP-MailID: d2b9aa2748756f7b39770d6feec67c57 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [YXNU] Archived-At: Subject: [Doh] [Dnsmasq-discuss] Implementation of DOH in dnsmasq X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 15:33:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6ay8EiRezw8hBg2Qr2QlTxe3tdNrhal0k Content-Type: multipart/mixed; boundary="31fllaRgvbjyUELjsqPnng9GYM8mmQY4C"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Geert Stappers , Nicolas Cavallari , DOH Cc: dnsmasq-discuss@lists.thekelleys.org.uk, Kurt H Maier Message-ID: Subject: [Doh] [Dnsmasq-discuss] Implementation of DOH in dnsmasq References: <360883b6-2d1a-a68b-81a2-c7902e29e0f2@o2.pl> <20180614203224.GA45519@wopr> <7da6219a-9ceb-4563-5077-116b6dec6f96@green-communications.fr> <20180620085756.GY30489@gpm.stappers.nl> In-Reply-To: <20180620085756.GY30489@gpm.stappers.nl> --31fllaRgvbjyUELjsqPnng9GYM8mmQY4C Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 20.06.2018 o=C2=A010:57, Geert Stappers pisze: > On Wed, Jun 20, 2018 at 10:11:53AM +0200, Nicolas Cavallari wrote: >> On 14/06/2018 22:32, Kurt H Maier wrote: >>> On Thu, Jun 14, 2018 at 09:38:42PM +0200, Mateusz Jo??czyk wrote: >>>> >>>> How difficult would it be to add support to DNS over HTTP/2.0 in dns= masq, for >>>> example in constrained environments like home routers? >>>> >>> >>> This should be handled with a wrapper program. HTTP/2.0 is an enormo= us >>> and ill-defined specification and it would not be appropriate to bolt= it >>> directly into dnsmasq. A dedicated HTTP/2.0 daemon can talk to dnsma= sq >>> on the backend to provide this service. Home routers are not >>> particularly constrained in this regard, since they generally have we= b=20 >>> services running to begin with. >> >> It's much more than that. To be secure, TLS requires time, entropy and= a CA >> list. Many home routers fails at having all three, or require the DNS = to get >> time and CAs... DOH server certificate could be provided together with the DOH server IP.= Thank You. So, as has been said above, implementing HTTP/2.0 may be more difficult then implementing HTTP/1.1. I would therefore propose to add the following text to the DOH draft (at = the end of section "HTTP/2"): However, older versions of the HTTP standard are simpler to implement, and have enough capabilities for limited capability servers on embedded devices so DOH clients SHOULD be able to use DOH servers that support only older version(s) of the HTTP standard, such as HTTP/1.0 {{RFC1945}}= and HTTP/1.1 {{RFC7230 - RFC7235}}. >> >>>> Please send any replies to the DoH mailing list at . >>> >>> Why? I asked this just for the sake of convenience. Greetings, Mateusz Jo=C5=84czyk --31fllaRgvbjyUELjsqPnng9GYM8mmQY4C-- --6ay8EiRezw8hBg2Qr2QlTxe3tdNrhal0k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEVwj0eFevwwaT4Zqs+9ZauGEK/sYFAls2UVoACgkQ+9ZauGEK /sYMGw/+PFBQ6TzoE2WbkzbZmpG56gYJEpeE4LytcDJbo//FFnjJuzM5Ld+j+QIO Ea7nIzLGh8NZJWrZxH4FxaO3hQAf+R2+VJdYd350fR5nRAnHZ3Xspppz0JG7fJbC uzRZc0hDnISgjF1CFu4iomMy0nTmyBSIwsRjJecYexCblcqUvwxmR2GL2zTx/11V SYy8mmsOfk0LMPjSvMzG1kJ1ond+aHdv/LXnsn+ajvcQy5siZnuFrJYTLWZ5jdel ioUL6EyWkS7cpneB0893VNLLpOC+eSRouq8bfBCwKv0kZUXC1YWiBbiLwFpsCC6o R4z7mTaPsXp6CoWvYkQepHtogImQGwHBvRLuDyYMAcgAa3A+r8fdbc/fRUnJrp3R zI5mth1HeigfAWj1I3TgB1Rn11On6KCrkdxdFJLDOVI/WKmQRD3J64SH4J6cUEER Xl/0oy8GjqyOzZipzHzoK+gpNlMXHmofHJlvnm6bVcEJaT8yVkbyeNwsAetWws4I THKSztIUPtrk8xNz6GzVdN2oPaClVyV074MBguLjGt/zQnRfIclrt9yILjharjVe fmoVY6DnU7XQLhau/E6ZoCqy0vw/K+0bps6udi5EIq4yGrYI2fJnCxaWRv504oPk URw+wN6kEJs7SbmdLs36OUiRl6QQB6KUUZeknSW9TEWjhhWqbqg= =0tZx -----END PGP SIGNATURE----- --6ay8EiRezw8hBg2Qr2QlTxe3tdNrhal0k--