From nobody Wed May 3 11:17:24 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB4712947F for ; Wed, 3 May 2017 11:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31jcIDkleO_8 for ; Wed, 3 May 2017 11:17:19 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9684512948D for ; Wed, 3 May 2017 11:15:18 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E0FABF98C; Wed, 3 May 2017 14:15:18 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CD6242061B; Wed, 3 May 2017 14:15:13 -0400 (EDT) From: Daniel Kahn Gillmor To: HTTP Working Group Cc: DNS Privacy Working Group Date: Wed, 03 May 2017 14:15:10 -0400 Message-ID: <87tw51remp.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:17:22 -0000 --=-=-= Content-Type: text/plain Hi HTTP folks-- I've just pushed a revision to a recent individual submission about a technique for hiding DNS traffic that makes use of HTTP: https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ It describes how a TLS server can offer both HTTPS and DNS-over-TLS on the same port, because valid initial messages from the client in each protocol are always distinguishable by the server. I brought this up first over on the DPRIVE mailing list (in CC), and i've made some initial cleanup and improvements based on the suggestions i got there. But i also wanted to bring this to the HTTP working group for feedback, since it's possible that i've mischaracterized the current state of HTTP in my analysis. Please review and let me know if i've gotten anything wrong! Also, if adopted widely, the draft has implications for the future evolution of stream-based HTTP as well as stream-based DNS (see below). And Joe Touch pointed out that the draft should explicitly update the HTTP as well as DNS specifications, so i've marked the latest revision of the draft that way. If you think that's OK (or if you think it's unnecessary), please let me know! Assumptions about HTTP ---------------------- The main constraints that the draft places on future stream-based versions of HTTP (that is, HTTP-over-TCP or HTTP-over-TLS, but not HTTP-over-QUIC any other fun non-stream transport) are: (a) it assumes that stream-based HTTP will remain a client-speaks-first protocol. (b) it assumes that the first flight of data sent by the client without expecting a response from the server will be at least 14 octets. (c) it requires that none of the first 14 octets of the stream sent by the client to the server be below 0x0A (LF) or above 0x7F. AFAICT, These constraints are already met by HTTP/1.0 and HTTP/1.1 and HTTP/2, as documented in the draft. Please tell me if that's wrong! Given HTTP/2's "connection preface", i've imagined thus far that future stream-based versions of HTTP would be fine having their own "connection preface" that meets constraints (b) and (c), and i don't see how a future version that listens on the same port as existing versions of HTTP could in any way violate constraint (a). I hope the members of this fine WG will tell me otherwise if that's not a good assumption. Also, if you review the draft and you think it's placing some additional constraint on future versions of stream-based HTTP that i haven't mentioned, please call it out! Implementation status --------------------- I have a functional implementation listening behind a TLS frontend on TCP port 443 on dns.cmrg.net right now, if anyone wants to experiment with it. Consider all the possibilities of this terrible layering violation! Both of these commands work just fine: wget -O- https://dns.cmrg.net/ kdig +tls @dns.cmrg.net:443 www.ietf.org The implementation is in C, freely-licensed, and available at https://gitlab.com/dkg/hddemux for anyone who wants to play with it. It's also available in Debian's unstable distro: https://packages.debian.org/unstable/hddemux Followup -------- The IETF mailing lists aren't well-structured for conversations that need to happen between WGs. I'm subscribed to both ietf-http-wg@w3.org and dns-privacy@ietf.org, and i welcome feedback from both working groups. But maybe some folks who want to follow up are not subscribed to both. Unless either WG complains, i encourage followup to be made to both mailing lists unless it's clearly specific to one protocol only, and i humbly ask admins of both lists to allow traffic from the other community through. Minor editorial cleanup can be made as a merge request or issue at https://gitlab.com/dkg/hddemux or by private e-mail. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKHi8ACgkQFJitxsGS MjcxWRAAl7yWsrJsawSNtv0FMI83+vKIPsv0x3fU2uPyq6uhK+BytsGHUNQ3aF2z M23PpvAHGv84WGE8g6li3qNMoje6XvcAKHJ7lISxfIRt9RKqq7Q4E10BEqVUXc6y wKr4UhfX60v2gkxrrfr+dDPf6tQOJd/oAd1MEPEokXQs6kbmiuHO4Pf/2Ctj/g+5 PKncwTvuejxmPsY+UCRubt0b0SMGsFjFNRX94jlMitur5Csp/3IeskKO2bWsSUEm xk60z+OjfIUOtK/s17+SKgK/g6P7KU34aJ7YZ7hMIaNrVw/FoqNcILDvNsVD+BJV 50JM4+vL4aKhlAmgsfgxHm9ooGcB6cbtaQk9klR56sCu7V5oTHup+IBEffvMPPWl XOEDwbTbedm5iO6X49Ji+mpG+MjE98q68Qqt40e6Tz2AKXOb1ZjXkJBKi++a+P0y 9a08Jl6kk4JsItTj0tCp0AaBNVVDmcGm9a7yZ3pe7COKxb8rZCDqQJWxWEaq8HHQ tfBeTMb0ZvMvij3yWr5ZMQaSdyvRlkq/bsyQdefPtnS7frhkVxmguMMxTXrVRdTo dcq6O2DImfvlZ2W1j3VJq6i1cyO8sFMrWg/dzbFGCe1WUJDSyrj3D09HzzSgn1Ih edVTbOaUi0U0CrEjfKwwJdrH8juUlrctVej49Q9jEz6lbL/LkTw= =bA0W -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 11:36:12 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7A129B65 for ; Wed, 3 May 2017 11:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 nLKC8PdeDVW0 for ; Wed, 3 May 2017 11:36:09 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 28F7412948F for ; Wed, 3 May 2017 11:33:55 -0700 (PDT) Received: from [128.9.184.18] ([128.9.184.18]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v43IXcnr022588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 3 May 2017 11:33:39 -0700 (PDT) To: Daniel Kahn Gillmor , HTTP Working Group Cc: DNS Privacy Working Group References: <87tw51remp.fsf@fifthhorseman.net> From: Joe Touch Message-ID: <0a2e075d-59fc-1e0d-d745-31f5608a525c@isi.edu> Date: Wed, 3 May 2017 11:33:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <87tw51remp.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-MailScanner-ID: v43IXcnr022588 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:36:11 -0000 Hi, all, FWIW...speaking from the experience I have leading the IANA ports expert review team and developing BCP165 (RFCs 6335 and RFC7605): On 5/3/2017 11:15 AM, Daniel Kahn Gillmor wrote: > And Joe Touch pointed out that the draft should explicitly update the > HTTP as well as DNS specifications, so i've marked the latest revision > of the draft that way. If you think that's OK (or if you think it's > unnecessary), please let me know! > > Assumptions about HTTP > ---------------------- I would characterize this as redefining ports 80 and 443 to include DNS as part of the HTTP specification. That has some very important ramifications, indicated here as "assumptions", that limit the future development of HTTP (notably reserving certain prefixes and patterns to differentiate DNS requests from HTTP). That could constrain all current and future uses of ports 80 and 443, and could potentially affect any other service that uses HTTP as a framing layer. Joe From nobody Wed May 3 12:28:37 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14BA129AB8 for ; Wed, 3 May 2017 12:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-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 ZKjJP180dwzS for ; Wed, 3 May 2017 12:28:34 -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 76A5D127A91 for ; Wed, 3 May 2017 12:26:41 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id j17so18869684ybj.0 for ; Wed, 03 May 2017 12:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tOkneZEv+NNmAIP2cYU/iZMtQxwlcvViYtuhkBCC3pg=; b=HutaKpu6zH+yFNogfBqQvOLmNYksXA41ldYuhxHbZbhBQS7BZWsv2YW0Q5atTRtqNg wGxALWIQa6MAhmNPMKclcEy02WRfbP9CsTTOO5/xaO8J0Z61/q0Q9o9YiM93e03hZe7i 0O83Jiedv5f47mcLCYVZSixNbnOteUomewQ2G3XPihHo9c4Ux4Lfk/TrYUlGUV6lgkhx ASoP0T4lBPfFgdzFRJPnHJ2Y1B0gzY2UJzoV9HXCU7juPcqJZEckEAVlC9rH7dthwybp YE7eHao130Hx0XdNouoToVn1aij/NJHpaqbXR2qS2CevfsX8GQseOFsgykH04EygeOJ/ oTHQ== 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=tOkneZEv+NNmAIP2cYU/iZMtQxwlcvViYtuhkBCC3pg=; b=klR1BWM8X0T/ilxeM2mdqijUfoTfhvkMwquQQ9JJcX7TIpgiD4iuqbO2XjFTSU8yys nx6NXT8QkNbZ727vU11DBLtyUfdBnMP8w0XHuDDK0tRMv9RmZX+OZNiRrJfXYcj/qslt TLXKfzVLNLCaERq6dsF6G28W1cpznpjP5eZp2J4AGSx43zEB9grV25+ugZJMqdsOTvpS 4+cXDC1S0Q+tA7LYhvDajdQ2Bvd9rIauMLC3/Ae5tGQrq06f9NrBTJ7A6nAgnruPg8xr r60VuwVn+RNRJU7Ztm1jk2+axfNUesiAzQ7XsstB8omCeovY9L50nEZluMmg6JxR/FlL LcPg== X-Gm-Message-State: AN3rC/4D5GoG8tZbARYTokIUd5eMidS/wIfBWeQgJHZ/PfYuyyMvBtxD xiDqltAuLaBhVxP5B82SZGhEcWmn6A== X-Received: by 10.37.198.147 with SMTP id k141mr30094817ybf.27.1493839600773; Wed, 03 May 2017 12:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.57.67 with HTTP; Wed, 3 May 2017 12:26:40 -0700 (PDT) In-Reply-To: <87tw51remp.fsf@fifthhorseman.net> References: <87tw51remp.fsf@fifthhorseman.net> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 May 2017 12:26:40 -0700 Message-ID: To: Daniel Kahn Gillmor Cc: HTTP Working Group , DNS Privacy Working Group Content-Type: multipart/alternative; boundary=94eb2c08c53cc1f0a5054ea3a20e Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 19:28:37 -0000 --94eb2c08c53cc1f0a5054ea3a20e Content-Type: text/plain; charset=UTF-8 On Wed, May 3, 2017 at 11:15 AM, Daniel Kahn Gillmor wrote: > Hi HTTP folks-- > > I've just pushed a revision to a recent individual submission about a > technique for hiding DNS traffic that makes use of HTTP: > > https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/ Cool idea. One concern might be compatibility with other similar mechanisms. For example, there are protocols such as Netscaler Client IP: https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ or HAProxy's Proxy Protocol: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt Where proxies may insert their own pre-amble on the connection, to pass on something like an L4 X-Forwarded-For. Sometimes the backends behind these proxies have to accept traffic directly too, and they fingerprint the first few bytes to determine whether it's a direct HTTP connection, or a proxied request. I haven't thought through it, but it might get a little complicated doing two levels of demuxing, and it might not even be possible in some cases. -- Colm --94eb2c08c53cc1f0a5054ea3a20e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, May 3, 2017 at 11:15 AM, Daniel Kahn Gillmor <= dkg@fifthhorsema= n.net> wrote:
Hi HTTP folks--

I've just pushed a revision to a recent individual submission about a technique for hiding DNS traffic that makes use of HTTP:

=C2=A0 https://datatracker.ietf.org= /doc/draft-dkg-dprive-demux-dns-http/

Cool idea. One concern might be compatibility with other similar m= echanisms. For example, there are protocols such as Netscaler Client IP:



Where proxies may insert their own pre-amble o= n the connection, to pass on something like an L4 X-Forwarded-For.=C2=A0

Sometimes the backends behind these proxies have to = accept traffic directly too, and they fingerprint the first few bytes to de= termine whether it's a direct HTTP connection, or a proxied request. I = haven't thought through it, but it might get a little complicated doing= two levels of demuxing, and it might not even be possible in some cases.= =C2=A0

--
Colm=
--94eb2c08c53cc1f0a5054ea3a20e-- From nobody Wed May 3 12:37:40 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33C12946C for ; Wed, 3 May 2017 12:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.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 lSxCf6idR_4I for ; Wed, 3 May 2017 12:37:37 -0700 (PDT) Received: from homiemail-a68.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758FB129B21 for ; Wed, 3 May 2017 12:35:53 -0700 (PDT) Received: from homiemail-a68.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a68.g.dreamhost.com (Postfix) with ESMTP id BB6B348000B33; Wed, 3 May 2017 12:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=zgA82WxXD4pygTWFGGZlbEOFUEE=; b=RF6Tgt5sL2ZRBiAxA9u4wQiUWx4M w6sFDQHH+3ePuFl9ljtaYI8D1a3cO+nDzUclp9HFscN2cOi5MM40tKPL3/259XLV 3moaKNvvd/z77gIGVsHWUD51UcSH0KNzMhXsqtIgXDFpYRvkzS4vF45aG0CvdaVD f10TWOcsbrTuucg= Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a68.g.dreamhost.com (Postfix) with ESMTPSA id 9F65748000B30; Wed, 3 May 2017 12:35:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Roy T. Fielding" In-Reply-To: <0a2e075d-59fc-1e0d-d745-31f5608a525c@isi.edu> Date: Wed, 3 May 2017 12:35:52 -0700 Cc: HTTP Working Group , DNS Privacy Working Group Content-Transfer-Encoding: 7bit Message-Id: References: <87tw51remp.fsf@fifthhorseman.net> <0a2e075d-59fc-1e0d-d745-31f5608a525c@isi.edu> To: Daniel Kahn Gillmor , Joe Touch X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 19:37:39 -0000 > On May 3, 2017, at 11:33 AM, Joe Touch wrote: > > Hi, all, > > FWIW...speaking from the experience I have leading the IANA ports expert > review team and developing BCP165 (RFCs 6335 and RFC7605): > > On 5/3/2017 11:15 AM, Daniel Kahn Gillmor wrote: >> And Joe Touch pointed out that the draft should explicitly update the >> HTTP as well as DNS specifications, so i've marked the latest revision >> of the draft that way. If you think that's OK (or if you think it's >> unnecessary), please let me know! >> >> Assumptions about HTTP >> ---------------------- > I would characterize this as redefining ports 80 and 443 to include DNS > as part of the HTTP specification. > > That has some very important ramifications, indicated here as > "assumptions", that limit the future development of HTTP (notably > reserving certain prefixes and patterns to differentiate DNS requests > from HTTP). That could constrain all current and future uses of ports 80 > and 443, and could potentially affect any other service that uses HTTP > as a framing layer. > > Joe I agree with Joe. My answer would be "no". It certainly isn't an Update for the HTTP specs. I see no reason to suggest that spraying DNS on an HTTP connection would be interoperable. HTTP/1.x has a tradition (good or bad) of allowing robust parsing of bad messages, which means no analysis of DNS uniqueness can guard against the potential variance of a thousand or so independent implementations of servers and intermediaries (there are at least four figures of independent server development in the craft-your-own-microserver category). In contrast, it is trivial to transform a DNS query into a GET request which can be handled by any current or future version of HTTP. All you need is the absolute URI, which is already defined, and a media type for the response payload. That would just be using HTTP, so no need to call that an update either. ....Roy From nobody Wed May 3 16:22:12 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC72A127876 for ; Wed, 3 May 2017 16:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 sw1S-eDtgxNt for ; Wed, 3 May 2017 16:22:09 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B961F124234 for ; Wed, 3 May 2017 16:22:06 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 434A2F98C; Wed, 3 May 2017 19:22:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0E20B20C10; Wed, 3 May 2017 19:12:04 -0400 (EDT) From: Daniel Kahn Gillmor To: "Roy T. Fielding" , Joe Touch Cc: DNS Privacy Working Group , HTTP Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> <0a2e075d-59fc-1e0d-d745-31f5608a525c@isi.edu> Date: Wed, 03 May 2017 19:12:01 -0400 Message-ID: <87r305r0vy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 23:22:11 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2017-05-03 12:35:52 -0700, Roy T. Fielding wrote: > I see no reason to suggest that spraying DNS on an HTTP connection would > be interoperable. HTTP/1.x has a tradition (good or bad) of allowing > robust parsing of bad messages, which means no analysis of DNS uniqueness > can guard against the potential variance of a thousand or so independent > implementations of servers and intermediaries (there are at least four > figures of independent server development in the craft-your-own-microserv= er > category). Perhaps the draft needs to be clear that this draft provides guidance for servers that *want* to be able to distinguish a DNS-over-TLS stream from an HTTP-over-TLS stream. According to the published specs, a server is within its rights to not treat invalid HTTP requests as valid HTTP requests, right? > In contrast, it is trivial to transform a DNS query into a GET request > which can be handled by any current or future version of HTTP. > All you need is the absolute URI, which is already defined, and a > media type for the response payload. That would just be using HTTP, > so no need to call that an update either. Agreed on this one, quoting from the draft: If being able to interleave DNS queries with HTTP requests on a single stream is desired, a strategy like {{I-D.ietf-dnsop-dns-wireformat-http}} is recommended instead. The advantage of draft-dkg-dprive-demux-dns-http over this approach is that existing DNS-over-TLS clients (of which there are several) don't need to learn any HTTP framing or parsing, and can simply be repointed to a server that already supports this demultiplexing on port 443. For folks in the HTTP world that might sound like "just use HTTP", but for an existing DNS client, it's an entirely different codebase to adopt (or to build), with all the attendant bugs and maintenance risks. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIyBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKY8EACgkQFJitxsGS MjdKBw/4iAFYAZ+E6WroYfk3x45ttO2aycaUS7NKgHd3jD/cwUc1051IyJKyGjID mrLCCHhslMN3e1+yva3hSEoeDq/9+JhF4mBIiAnvO6vEYAzyZvcY0T/SpCo1Da5G fn1w6Zc3UoR2dReaZbYtbJzqilubgTnsMd3hHozfYDgUlw7OPXKsOg19uKrL9WRG 8pUtHgfff2gh2WKPusUDGmIAPG3Z8go2DfSzDHVa0zdTrr50HNX9HlNv/W9zAkLr CSRXj2gbNfq1Q5bumj5eGC/fscuFbm7Q3YDnlK/seCYEAXjzVFP9Ezq5Aa2I+FOC AYZ53gD8Q/5M1nJi3O/KrbmGkXfr/QZyxlQlcxoq8VPuCrkqUq2IZDQsvyZYTaeh +1/vkCuYVs2hlYASaG5y2VP+sPNQPuFmUfDO1fkLxbByzAxNk0si6QjTFxJwy/TJ 7v+EP0vTloMsAUF/yKhb5hiVvxwgPls1TVkxWeKp1RbNeIO9xmaY5NCnGDBOiK6v js4AQWmDliYHQv2DsOwJpKFcxecQrf6U+sepHCV+2wWHhILoPRAiDPNus6li82IB k3vHf0o2+OLuS6PfMQXCSlvpJe1kNwXXDHg/S/Iw7/LBItsCOomJp7NROakuh/6n SISDOEK8fH8BZgP09SihH9aJxw0x8HeM9c6CS6qZps164dOT3Q== =KS6C -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 16:22:27 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1489C124234 for ; Wed, 3 May 2017 16:22:12 -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=[BAYES_50=0.8] 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 rAxma32QcgBY for ; Wed, 3 May 2017 16:22:09 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B96CD12778E for ; Wed, 3 May 2017 16:22:06 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5806BF993; Wed, 3 May 2017 19:22:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 245C120CBD; Wed, 3 May 2017 19:17:46 -0400 (EDT) From: Daniel Kahn Gillmor To: Patrick McManus Cc: HTTP Working Group , DNS Privacy Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> Date: Wed, 03 May 2017 19:17:42 -0400 Message-ID: <87o9v9r0mh.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 23:22:12 -0000 --=-=-= Content-Type: text/plain Hi Patrick-- On Wed 2017-05-03 14:57:24 -0400, Patrick McManus wrote: > My initial response is that legacy HTTP/1 implementations will sink you by > scanning for stuff that looks like HTTP in your stream - even if the > leading bytes don't match the production those RFCs required (and HTTP/1.0 > is only informational anyhow). You can look at the websockets masking > madness to see the lengths the community went to to avoid that kind of > detection in rfc 6455. Are you talking about an existing HTTP/1 server implementation? The idea of the demuxing stage is that a server that opts into this would put the demuxing *before* the HTTP/1 server implementation gets access to the data. > Coincidentally I have a draft with Paul Hoffman that we're close to > publishing, that describes how to do DNS over https:// in a way that I > think will play better with both the http and dns ecosystems than previous > work in that area. It wouldn't be a http-wg item though, we don't normally > take FOO-over-HTTP drafts here. That might be a better option - if you want > to use the https port, and the https alpn token, perhaps the https protocol > (without constraining its future) is the right choice :) is the draft you and Paul are working on different than ietf-dnsop-dns-wireformat-http ? Can they be reconciled? See my response to Roy T. Fielding (upthread) for why the demux approach seems cleaner and safer for clients as long as we're using stream-based transport. I certainly wouldn't want this work to get in the way of ietf-dnsop-dns-wireformat-http (or any similar proposal), but i don't think it does. does it? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKZRcACgkQFJitxsGS MjcpLg/+IANNNiqdcRiNPtqoTeSAhn+FIfjXM2CIp0BvxHmRGrnOMtWpb8UZdWPm OJZ9BuAWhQVz5KO5Ezd7jSmTePQ3rllaeS7T1kamuUcDxG4tgCJdZpaeo3YIEhKL DldNMrtPqI+NvqsTqpTDGPNSH7OJhrf8uxzrnPMSuRGlJfnp9zWwV1xlpyjD52GB Klg1FZ3NHSjLhXRBcJCjdWY8j+DnowCNdKpCn+CN0ZR3DjNllx7KwBbXi1+cwwLE 3mhKCwJWxLEMnPAGDpa8uIZcEuBhURjAYDtLX8AgdTW1G19sfIEpz45NeL4mA6Xz JKl4IcjqH1v5mPzoREB8i2MaE0e27Et3EYBwaTnJj/taH1sdZUmqLNFQ1J6soO9J zcdpuk0bHIgskvE0IfEw0B9VVFDgcuoltndBz1nzG9KoyglE2N+aex18QX6ey71/ 51f9gbvsSr1hkh+rOfukHFEqsdP8ifRWVN4kjYnx3qjlc6qgN96srTDwyEAHuqzH mqky/V+ewjRBYLudR19jzjKvVFybjpIF59xbGSNFS35jkmJVvRrzgXE8ydeRlCrz 7m1cTpVnDmVLYugE8nS/YuWmh0zexbqljIkjed4DXuM3DMIJk0lqUYUwBYu3IkUF o5EVoM4r+/dUQvP8AeN3iQDf4B2Y+HwDiXkqcOeKTWXgIGY1d+c= =3iIK -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 16:32:25 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D199128959 for ; Wed, 3 May 2017 16:32:24 -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=[BAYES_50=0.8] 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 M0-m9VLDQEZd for ; Wed, 3 May 2017 16:32:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3711287A0 for ; Wed, 3 May 2017 16:32:23 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5DCDAF997; Wed, 3 May 2017 19:22:06 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2E4C72126D; Wed, 3 May 2017 19:21:48 -0400 (EDT) From: Daniel Kahn Gillmor To: Patrick McManus , Patrick McManus Cc: HTTP Working Group , DNS Privacy Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> Date: Wed, 03 May 2017 19:21:44 -0400 Message-ID: <87lgqdr0fr.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 23:32:25 -0000 --=-=-= Content-Type: text/plain On Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote: > I forgot to mention another potential challenge with the demux approach - > h2 is not client send first.. typically both sides send SETTINGS > simultaneously.. and its important to the server not to hold those back > .5RTT as it can contain a bunch of configuration information (buffer > sizing, levels of parallelism, extension negotiation, etc..) that it wants > the client to start honoring asap. (Whether this is actually simultaneous > boils down to which flavor of tls handshake is done.) Ah! Thanks for this heads-up. That's definitely an interesting wrinkle. How does this interact with HTTP/1 clients connecting to the service? or is it only possible to do this because of the negotiated ALPN? If so, perhaps the demuxing needs to be done only when not sending an alpn of "h2", and the draft can drop the HTTP/2 section. What do you think? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKZggACgkQFJitxsGS Mjc+tA//dhF87czK2DA2rHibeHOe+SWhEGnbJfqsP7KDVa/VmEMPHZDFsZodznrC cf0s25ANKBNfcZE+Rgmg0p6KN+wWcO6gJqY1xFX24TTix5jDR7gC+er2DIQAAOi2 BBrO/lYKGUOwhRAbOi1J/qMfsbNauth8DubayoeSY92SGPur8un8zVZvC82uc9hD D5KQuqgscK0k+ROyLWOKBMOdZZIo4XXLb4QCzU0Kr1N+qmq0QeFWX5KqbuRCEXFL 994UY3UmpWZ90MkVQ24wcMYrlsoRaBE505lKzLcwImmBALpp//XZtDOiCCYSGX7m yxNWOLfwjkuPScuzTxR9hNYwaM8ARqnlAXuuaErEZE5h3LgSRMKYEXJgFHQNOkMb Uxi3p3By6QFkCFsJciDjZlU2u+KHSY+b0FD8xSLe2pi/2mwyNBGj3FcewDUfX8vR EV08eitJCVXA1Jo7rSUMSZwueou+iz+u0HbLUcGKHmcmGdFqavRs5PcdcB8InV4W UzQxpRb1MRouWMDCV1blhu6k9Zy26lzBe51NorqASsVIIZ3DCkgpcZWaf5O2riXc ynUgq2U+IQhp+HY9JtU5WmZL1ogOq/X7XuahF15T8wtgLsoQ4K4HSTt5Lo47C0Ra AXYMvVp9QpOEzS2h02Pw0p0APL20zYjyNpl77cnmk5KOJcw5J+4= =Wb/p -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 16:50:11 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77379128959 for ; Wed, 3 May 2017 16:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jTXQbXHNOxv for ; Wed, 3 May 2017 16:50:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 47286127A91 for ; Wed, 3 May 2017 16:50:07 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A7156F98C; Wed, 3 May 2017 19:50:07 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 533D020C10; Wed, 3 May 2017 19:50:03 -0400 (EDT) From: Daniel Kahn Gillmor To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Cc: HTTP Working Group , DNS Privacy Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> Date: Wed, 03 May 2017 19:50:00 -0400 Message-ID: <87inlhqz4n.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 23:50:09 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Colm-- On Wed 2017-05-03 12:26:40 -0700, Colm MacC=C3=A1rthaigh wrote: > Cool idea. One concern might be compatibility with other similar > mechanisms. For example, there are protocols such as Netscaler Client IP: > > https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-= option-of-netscaler/ > > or HAProxy's Proxy Protocol: > > https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt > > Where proxies may insert their own pre-amble on the connection, to pass on > something like an L4 X-Forwarded-For. > > Sometimes the backends behind these proxies have to accept traffic direct= ly > too, and they fingerprint the first few bytes to determine whether it's a > direct HTTP connection, or a proxied request. I haven't thought through i= t, > but it might get a little complicated doing two levels of demuxing, and it > might not even be possible in some cases. Thanks for the pointers to these protocols! It's good to know that people are already doing this sort of demuxing on the fly in some cases, and that they haven't broken HTTP for everyone else yet :) One approach for the current draft would be to explicitly call these protocols out as things that are incompatible with he proposed form of demuxing. I'd be happy to add a generic "do not mix this mechanism with other similar mechanisms" section. I've just opened https://gitlab.com/dkg/hddemux/issues/2 to make sure that doesn't get lost. FWIW, it actually looks like both versions of haproxy's Proxy Protocol can be distinguished from DNS just by looking at the same octet ranges. For the human-readable protocol, its first many octets (more than 14 of them) are all within the 0x0A and 0x7F range. for the binary protocol, its initial static 12-octet preamble puts a 0xD nybble directly in the DNS header's RCODE field, which should be 0x0 in a DNS stream assuming the initial client message must be a Query and not a Response. But i don't plan to turn this draft into a generic how-to-demux-anything-with-anything draft, so i don't think i'll write that up more formally ;) So i think the result is to say that if a server is already demuxing an inbound stream based on the same octets, they might not want to adopt this. Do you have any qualms with making this particular concern something that is out-of-scope for the draft? Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKbKgACgkQFJitxsGS MjdEwBAAhk6rxWvB/Ct4Kz5swsOzy6ZU/dBXC7ETYRWIkOSYAO/DPmRE6AqWlraf aS+il9AzQsUeb4sD0DUgcGYSUJMD1hvQ5HTP3/+6lVivSTzKA3PtTsx5R1VoQvRi FhXP3qbtR/+oRUkT7bD863A5nSyvYPwCrfEPRdHT22Ci2i3wJTfJi9IpOnygpyPp NFjs6L4ds//5X3ycs1hrgf56kADrsWUnWhbdl5mg4/dWXl90fqFG+ggzGH7f3LY6 adYuAZw+HXfV3xDGY5S0KtSIzIMN7FTcYIoli6AORsW4gxwgT4o1+BOzOsb+Z6mK BYBqWJTfcrzWkpR+9Yqu4CIkb5C117iUxI1EG2ELJu1BnqWp6Ods//YHcCkws2vT W0ZAiHFapW1JeIrT95vdYmjZvUXUpHxwEClZJ+zRxKdj7JdGRByIbymgvl+HZNCd GG2yauqW+O3VqVh0l+pwhKwmcmr3m2rqZ3q0gohyUYx5tJimfuK2R2H9JM9CTa8r jbBi/PaGGCgYleQOw8DO9ERN6ziaeIgXTXoOjNOgvjazpSJnS8kwmrBtycAy4wXk wSG8D3wjzbgvLoV6kS+Ti7bv56LUwysxR8hF+x+BFNct4jL30bc5nTS0ZcadXVqU 8IqV4/E7IKFx4qMwQHf1m0xIMoOTDW3z015KkLmFi/raqLHbIxs= =WJMe -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 17:14:51 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4EA128D6F for ; Wed, 3 May 2017 17:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 oJoTQMSfF-Gs for ; Wed, 3 May 2017 17:14:47 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0138.outbound.protection.outlook.com [104.47.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DEB126CBF for ; Wed, 3 May 2017 17:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xJZTWRu98gCm/xWe5Xc7Ac+MvFSAYtC5gZR3+FVq0uU=; b=TDD3eRY3XaOVBztILUqPYQ7pnAX9T7caOiC5ig8Oz6pLQXXcUSEYfboLX160RXSW/qv5yllh/NhZLM4HqDNvgHTfT2ROxoxBiPt5nUxaykhOYEuntL/mO30nIl29+y1UV3Je/Bw9a510dLhnUI5qy/HMiAeAnSUEPBQu0iiA6ZU= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 00:14:44 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1061.021; Thu, 4 May 2017 00:14:44 +0000 From: Mike Bishop To: Daniel Kahn Gillmor , Patrick McManus , Patrick McManus CC: HTTP Working Group , DNS Privacy Working Group Thread-Topic: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] Thread-Index: AQHSxGSVzArpJBnINkKlwlv/ObjAOKHjTeBg Date: Thu, 4 May 2017 00:14:44 +0000 Message-ID: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> In-Reply-To: <87lgqdr0fr.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8080:63a8:2891:f5f5:9743:f4c8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:qD/5pVDcjbf7FxJLFSuGiFWR1Mj4TQ8Dca6/QMtOcPcKHIRVolI7BDSciW3p1tziDec3xZFJsdGAPoG2aCf16+7K5DrMgY1LEjRCLg3bqmTQY6UMkiCBexDd/DQ6UjSp7zUWa/1u5Dc3GUABCgyAL4hVnHqYfmQSWt7ri2EpkADO68DuajgoB2HG6g+11CAl0M20tRQiuYNSZX7g5USBcHafg9/vHXSJnV4Ov9XxpeAYTJ6CwoyYAtiJpKJU3MCZnPmO8EN/Phxtj6+XPWbKCZrwP1A9PLEnNEgxIHxO1tynMYGCRzjsOlFLyMNfExZEm8exW9rXHYOiGMy211scnuA+pafm7lhE2frCGmI0iKQ= x-ms-office365-filtering-correlation-id: 68bad1e6-e3c1-4391-97ef-08d492829155 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(35073007944872); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39840400002)(39850400002)(39450400003)(13464003)(76104003)(24454002)(377454003)(377424004)(305945005)(6436002)(54906002)(77096006)(6506006)(74316002)(7736002)(10290500003)(53546009)(3280700002)(33656002)(99286003)(7696004)(86612001)(25786009)(478600001)(38730400002)(9686003)(53936002)(86362001)(4326008)(5660300001)(55016002)(230783001)(76176999)(2950100002)(50986999)(54356999)(229853002)(122556002)(8676002)(3660700001)(93886004)(189998001)(6116002)(2906002)(81166006)(8936002)(10090500001)(102836003)(6246003)(15650500001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 00:14:44.5480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:14:49 -0000 It's ALPN. At first blush, I would pick a different ALPN token for h2+DNS = and define it as a new, derivative protocol. -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net]=20 Sent: Wednesday, May 3, 2017 4:22 PM To: Patrick McManus ; Patrick McManus Cc: HTTP Working Group ; DNS Privacy Working Group Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version = Notification for draft-dkg-dprive-demux-dns-http-02] On Wed 2017-05-03 15:13:43 -0400, Patrick McManus wrote: > I forgot to mention another potential challenge with the demux=20 > approach - > h2 is not client send first.. typically both sides send SETTINGS=20 > simultaneously.. and its important to the server not to hold those=20 > back .5RTT as it can contain a bunch of configuration information=20 > (buffer sizing, levels of parallelism, extension negotiation, etc..)=20 > that it wants the client to start honoring asap. (Whether this is=20 > actually simultaneous boils down to which flavor of tls handshake is=20 > done.) Ah! Thanks for this heads-up. That's definitely an interesting wrinkle. = How does this interact with HTTP/1 clients connecting to the service? or i= s it only possible to do this because of the negotiated ALPN? If so, perhaps the demuxing needs to be done only when not sending an alpn = of "h2", and the draft can drop the HTTP/2 section. What do you think? --dkg From nobody Wed May 3 17:21:26 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3276129407 for ; Wed, 3 May 2017 17:21:24 -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, FREEMAIL_FROM=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 u-UsTAeMOUoY for ; Wed, 3 May 2017 17:21:23 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 500E71293E8 for ; Wed, 3 May 2017 17:21:23 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id t144so2571582lff.1 for ; Wed, 03 May 2017 17:21: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=5pHo9jTgG3PxiuKa+ewHKExo4yHmjAxVbKL7MDL798E=; b=XhTjbVrgdLNLQCfu5rAO/D6JjY0pYrLYW+Hn8eX06OsoGF1k3tg6dENhSueZZtBbk/ 3cBLY/Z8mvwHrEem0gSinRgbyEGllJrpDejrOs2E3yiw9OgpPGEp2Ogf4fQ1MaGQxph5 Dh6N50Vbi75TG6acjYejE2WJJRh6WIsYmeXg8wh0XU4fbJz5pNw2kwoQ9Wua4myeNDgo gzHZVAq+AfSqr/MwJZQ7B01J7MuwycqMqqyusuI09JXT1ZRI0ZJgMP+Go1l8Z20J0oht Tep/eRgF6Db4g9EgarOkIBIL8yqUQSePMMXTaijnTSM2ZyK9BZqvqhSQvODi5x9V8Dcf GzzA== 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=5pHo9jTgG3PxiuKa+ewHKExo4yHmjAxVbKL7MDL798E=; b=S65s1q2bLesYRMwc0TY+OIPtBWBWwxXt2fuT1szEnB9g9l4A4913FdSkNP1LBaZZQA N5sZw961qaTTbwHE2fsjTqWEE1enf0igXuv36vIKKfalsaKsJZPl1DzsV8GexlhPhs30 n3zYlsC0S+q0RSmu3n1qxAafzNDN6KYmr/rbNHjV2A6f6Jau5CXTkwxfbjiskuv+CnSY nK7TR47KfbOfu+5vNdd4y7iJ8XelcMewfV5qzoG/9q8YpKAMfdYQk6HFc3Mtq0W/V435 DflVNiYmwsSLK4lHez1VxVsuhO2aw2rnDt3b9RT8yuZEu8t+8EzvIHhHhYNCyjLBwzla NZYw== X-Gm-Message-State: AN3rC/7hL+v0zavZvTLwfET+y1dUeeobDtlV3JG8TiKDibpA3LTJoGrI QIIs6bGov5dVpbhXpBBvhY96dif253FI X-Received: by 10.25.76.6 with SMTP id z6mr12722463lfa.172.1493857281605; Wed, 03 May 2017 17:21:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 17:21:20 -0700 (PDT) In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> From: Martin Thomson Date: Thu, 4 May 2017 10:21:20 +1000 Message-ID: To: Mike Bishop Cc: Daniel Kahn Gillmor , Patrick McManus , HTTP Working Group , DNS Privacy Working Group Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 00:21:25 -0000 On 4 May 2017 at 10:14, Mike Bishop wrote: > It's ALPN. At first blush, I would pick a different ALPN token for h2+DNS and define it as a new, derivative protocol. For DKG to realize his goal, every client would have to offer that label. That's not impossible, nor does it make it a bad choice, but you have to realize that this isn't as good an outcome. From nobody Wed May 3 18:07:01 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB16F129479 for ; Wed, 3 May 2017 18:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 Im2ZLtkpHJSg for ; Wed, 3 May 2017 18:06:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 749371294BC for ; Wed, 3 May 2017 18:06:58 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 64FD5F993; Wed, 3 May 2017 21:06:58 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 268D720CBD; Wed, 3 May 2017 20:43:44 -0400 (EDT) From: Daniel Kahn Gillmor To: Martin Thomson , Mike Bishop Cc: Patrick McManus , HTTP Working Group , DNS Privacy Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> Date: Wed, 03 May 2017 20:43:40 -0400 Message-ID: <87bmr9qwn7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:07:01 -0000 --=-=-= Content-Type: text/plain On Thu 2017-05-04 10:21:20 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:14, Mike Bishop wrote: >> It's ALPN. At first blush, I would pick a different ALPN token for >> h2+DNS and define it as a new, derivative protocol. > > For DKG to realize his goal, every client would have to offer that > label. That's not impossible, nor does it make it a bad choice, but > you have to realize that this isn't as good an outcome. if you're going to define an ALPN label, you might as well just pick "dns" and then do straight DNS-over-TLS with it (no need for in-stream demuxing). The problem with this approach is that the network monitor can observe which clients are picking "dns" and which ones are picking "http/1.1", which puts you back in the position where the network adversary can trivially hobble DNS-over-TLS requests while permitting HTTPS. I address this in the draft section "Why not ALPN?" -- if anyone thinks the text there could be improved, i'd be happy to hear suggestions for how to change it. All the best, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKeT0ACgkQFJitxsGS MjcPjRAAi8DDsy4TnuDhvpABwrULuHcKynWilhNHr4KRch1NI8H4ekSOSjvcYo5r D43r0YCtsxLe4hcxMqHwd+BT0f3rPUTzI/tDEDULVnvNsLoXR9+NMKSyXc++0irf wEjWhgOZxgivKsOGSDxlD5hWZJSAWvitbLT4e54nixVNOy6xyZgEjXC0XvvCNFMg oVaxyRqHwjBIKcUXBoEOvGgvPPpEXXUSSizeTe3SsudvYDRfkNNRG4K8G/dnvj2w vWlvMvOczD504sXDRlqCinHgUB4rIyE4b54pXdd1ctWCf8SGXluR3XgTVQjtL+qq k24/DVVN3TFM2gMt/0bNbSTIpQmL10tMZWocSjiJkoKthSO7jRa3OHK/csDi0BwC 7Sg1nDsBmnWwQYOmdWJvotiFp95kFwdqedb0fA3Wu+hxY6b0FCBfJiUWrgTABkwS Nl+p79J8ZGVONGhTkZUEVMGC4qA50dZ1vBE8unbA0txuG48++/zrQxMRqUf+OVg6 6hhu7QluVdtR+TrblDoL1C0/w/xluQsPzKvuSsxBoINZOF0a42qeAReEYj+Wzc5h OPCgJLOzIHvXq5sWM+FrxmhOgL4kbL0nhbPVOmfeqdIbV+fBG+g6DLSGzrNxt7qB E1YsLbmtU1WsplomUNWCtNfv5KTd83eQO1ybgIpYSjdype1f2Ww= =L7LX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 18:07:16 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFCF129479 for ; Wed, 3 May 2017 18:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 1L3Q5eqip3-q for ; Wed, 3 May 2017 18:07:00 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7471D12947A for ; Wed, 3 May 2017 18:06:58 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B32A2F997; Wed, 3 May 2017 21:06:58 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C464E20C10; Wed, 3 May 2017 20:38:24 -0400 (EDT) From: Daniel Kahn Gillmor To: Alex Rousskov Cc: HTTP Working Group , DNS Privacy Working Group In-Reply-To: <2564afa5-1a0d-c3e0-e620-37d67482ce28@measurement-factory.com> References: <87tw51remp.fsf@fifthhorseman.net> <87o9v9r0mh.fsf@fifthhorseman.net> <2564afa5-1a0d-c3e0-e620-37d67482ce28@measurement-factory.com> Date: Wed, 03 May 2017 20:38:21 -0400 Message-ID: <87fuglqww2.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:07:01 -0000 --=-=-= Content-Type: text/plain Hi Alex-- On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote: > On 05/03/2017 05:17 PM, Daniel Kahn Gillmor wrote: >> The idea of the demuxing stage is that a server that opts into this would >> put the demuxing *before* the HTTP/1 server implementation gets access >> to the data. > > Think of the HTTP proxies, not just origin servers. Using an HTTP proxy > is often _required_ when sending traffic over an HTTP port. These HTTP > proxies will break all the muxed DNS traffic they will get. Opting them > "in" will be a lot more difficult than opting a specialized origin > server that wants to participate... > > And yes, this deployment concern applies to port 443 traffic as well, > unfortunately. Thanks for this, but i'm not sure i understand the whole situation you're describing. Can you help me make more sense of it? Here's a few things i think you might be saying: 0) A DNS client shouldn't expect this mechanism to work in the clear over port 80, because existing transparent HTTP proxies that the client doesn't know about will likely choke on it. I've noted this as https://gitlab.com/dkg/hddemux/issues/3 1) A DNS client shouldn't expect to use this mechanism through an explicit HTTP proxy either, as the explicit proxy will also choke on it. However, i'm not sure how this works for port 443. I think you're saying that the common network interference pattern is to block outbound TCP port 443 explicitly, but to allow HTTP CONNECT when established through the local required HTTP proxy. Is that right? I've tried to capture this as https://gitlab.com/dkg/hddemux/issues/4 I'm not sure what the right tradeoffs are here, or how widespread such network interference is. I am aware that the draft under discussion can't solve all problems for all networks. But i imagine that any network that blocks TCP port 443 outbound and expects clients to route through an HTTP CONNECT to an explicit proxy has already blocked TCP port 853 outbound, so the DNS client that tries to use DNS-over-TLS is no worse off for trying 443 instead of 853, at any rate. Am i missing some other details of the circumstances you're describing? Do you have suggestions of text for the draft that would address these concerns? Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKd/0ACgkQFJitxsGS MjfgQw/7B4j4PKmHn2+TUfT/IkkEKlWdqQ8icepEAZy78PQqVtVsSdsyhpCBEW8O mieqh+aJtOJ4oM/Bucak5Unslyq/RpT05x5so8uf+b2zd43z7IIxUwxx2dk/lNu+ 83ZhaeQ0cL5FQ5QD0oMlfgKqk85BxtTN5aUTcF86Frr7FYZrRMKRDpn3TNqaRJuD pzRlKJo9pS2FFVB38Qv44Z/qYJG8QWwmgAhSPLETSxuZd3Be+mWdJlE7Ng2J048c /ZiiYwnBdLUkM2okp96SBAuZLBktGALDDaDPz0Ev3dtn+rrGPYrhnK7z1NofW4lq 2cQ4oHbEAN888LPSSpC+VdXBe/PTLXG+NVWhEzCWE6tZWN3fHqwBogtQT1nv/5Sn J3ItVMvhMPrYl8o01o4aKibtVMtA7lREdyohioYLzma1VpAC9d44Fy/MIbbFC4F7 DZ4lqjMWrZFd46FRHhEzRkRvQuLpZpcB7j7VS3CD5J0mxbuRMYjnnhi61gWM2dfi pnUOg96teKXW5JY+8oZJCpIV6S0Su4d8b34qDoLkiH22wq3ipB3ENXBF5Jq3L0ve WHozWn8DrBu7jiIyWVXvlkSZsNUgRgLD7+8Xus+fW3z1qeORfeeqnl4J24TUHmtn xNYy/ogRmQrK9HS2rWwJdOo0PU4zjWcw5i1pM4rlrOQXDfD85TI= =At8S -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 18:12:05 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB37212953B for ; Wed, 3 May 2017 18:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 FRO481KFQgZL for ; Wed, 3 May 2017 18:12:02 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 436EF129530 for ; Wed, 3 May 2017 18:12:02 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id t144so2926627lff.1 for ; Wed, 03 May 2017 18:12:02 -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=Lx7ckVHO8WUZkjHx7lKfOH/5AOejT1jwwsGseeApvdM=; b=avJ/CWSKCl7FV3VceCblrizmHAARf/fXgmZfkzNi4SwsmKhkyuSv1bRkZ2S43+XI99 Frv4VqXFa7uSptx84h6zGJ+AYot9dx1eTrgZ0CAqtm/UPI0LuP2MD3aMQjWS77Ca4xmT wesYqF3Ohh8iYvAbCPl6b3TaI+BVsdJFu9g4yqBdCTAuYmP5PknHOQ/mbw3RBYC90rAi rEPfUbMmS6CnRTiDMoHx6QalClUpVo075X/AIVcM8c7dlGQckTu+VxvzStec/Ch3jTGM F1oi8K7O39WG8jOr41oXNK5bsgDSSOQnm38r38g1BdzltYCOIKTge89ebJxj6Kp46wEl Eo8w== 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=Lx7ckVHO8WUZkjHx7lKfOH/5AOejT1jwwsGseeApvdM=; b=tChm3JJ/lE2SNKhsFxX/qAflqtXB4qwLb8fzx4cVKg2DQBJGWzY2bQrm2rmEmA3GNw BHPEzXPNb5bljFZlXXgEnsVtmyYf7U+I7lk+nVtwPvrPn/d6O4EAB3DUBGl2waRPUfin hLaqNUUlu+4PEjw9lptHoLHyqqe3ol/GwXdJhad/kpsPDsqvyhch3SZp0OESX/jxrT9x FIC8T09G6cpfTHctvdk7anVEhhdwzzop7p9ZciaJSSNw+5mF9jet3lgxuaUdvrb3PzAK 2aEo5tFSlLbhZ8XEhvWlv3NN6emcPl5sPWDPRV/7VfYdsLZ6trF4Nia17E0mJSVuGZgP OKdQ== X-Gm-Message-State: AN3rC/4meFvGU1m1nIs2c80cX+4+P3TB1i7m5bUchY8K0ZQmZOc4CH59 Fqt1wwpy/h7dw4IUhL+uyIquHarIpg== X-Received: by 10.25.160.147 with SMTP id j141mr11483374lfe.19.1493860320426; Wed, 03 May 2017 18:12:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 3 May 2017 18:11:59 -0700 (PDT) In-Reply-To: <87bmr9qwn7.fsf@fifthhorseman.net> References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> From: Martin Thomson Date: Thu, 4 May 2017 11:11:59 +1000 Message-ID: To: Daniel Kahn Gillmor Cc: Mike Bishop , Patrick McManus , HTTP Working Group , DNS Privacy Working Group Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:12:04 -0000 On 4 May 2017 at 10:43, Daniel Kahn Gillmor wrote: > I address this in the draft section "Why not ALPN?" -- if anyone thinks > the text there could be improved, i'd be happy to hear suggestions for > how to change it. Mike is suggesting that you define one that is "http + dns" or maybe "http or dns", which would mean that you could use either. Then you convince existing HTTP clients to use that (a few browsers would do the job). Even if they didn't actually DO DNS, you would still be able to hide in the mass/mess that they represent. In TLS 1.3, the server choice is hidden, so even where the server doesn't pick this choice, it works. In TLS 1.2, you probably want to convince a few servers to pick this new thing, but that obviously means more work for those servers. From nobody Wed May 3 18:12:27 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176FE127058 for ; Wed, 3 May 2017 18:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lHFoMzTMFo3c for ; Wed, 3 May 2017 18:12:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id BED8A1294F8 for ; Wed, 3 May 2017 18:12:23 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5D37DF98C; Wed, 3 May 2017 21:06:58 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BD5112126D; Wed, 3 May 2017 21:06:50 -0400 (EDT) From: Daniel Kahn Gillmor To: Patrick McManus Cc: HTTP Working Group , DNS Privacy Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> <87o9v9r0mh.fsf@fifthhorseman.net> Date: Wed, 03 May 2017 21:06:50 -0400 Message-ID: <878tmdqvkl.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:12:26 -0000 On Wed 2017-05-03 20:37:21 -0400, Patrick McManus wrote: >> is the draft you and Paul are working on different than >> ietf-dnsop-dns-wireformat-http ? Can they be reconciled? > > its a superset of that -more aligned with HTTP than that draft, but it can > also carry wireformat. > > your work doesn't break it anymore than it breaks h2 generally :) Is your draft h2-specific, or is it valid for http/1.x as well? >> response to Roy T. Fielding (upthread) for why the demux approach seems >> cleaner and safer for clients as long as we're using stream-based >> transport. > > I totally support the end goal here of dns looking like https.. but > honestly I didn't hear anything about cleaner and safer. I heard that you > wanted to use the https port, the https alpn token, and constrain the http > protocol, but found the requirement to implement http burdening :) :) I'm not actually interested in constraining the http protocol, i'm just trying to make something that works with existing versions of the http protocol. I documented my expectations of future versions of HTTP to make sure that they're understood, which got me to your helpful point about h2 not being client-speaks-first. I've documented that here now, btw: https://gitlab.com/dkg/hddemux/issues/5 I'd expect this draft to work with no ALPN token at all (which is the traditional HTTP/1.1-over-TLS use case, and ALPN is still not mandatory for TLS, right? the "cleaner and safer" remark was from the DNS client point of view: they already implement DNS-over-TLS, they just need to be pointed to the right server and the right port -- that's literally no change to the existing code, and as long as they don't indicate an alpn of "h2" they should be safe, right? > The most straightforward way seems to make dns look like https is to > actually carry it in https. > > perhaps we could work together on making a dns client more capable in > this regard? I'd be happy to do that to make something like this work with HTTP/2. I'll contact you off-list about what might be sensible next steps. It occurs to me that an h2 CONNECT stream to localhost:53 ought to be sufficient to do a stream-based wireformat transition (assuming that there was a local DNS-over-TCP service active). Does that seem right to you? If that's the case, then a DNS-only client would "only" need to know enough HTTP/2 to establish the connection and to parse the incoming frames. Are there specific advantages of making the protocol entanglement more complex? ---- Given that not everyone is adopting HTTP/2 right away, though, do you think the proposed draft would be acceptable if it was limited in scope to demuxing DNS with HTTP/1.x? Regards, --dkg From nobody Wed May 3 18:14:10 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA94127058 for ; Wed, 3 May 2017 18:14:08 -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=[BAYES_50=0.8] 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 buHVmzMk7Wp1 for ; Wed, 3 May 2017 18:14:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id B229B1294F8 for ; Wed, 3 May 2017 18:14:06 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 33263F98C; Wed, 3 May 2017 21:14:07 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5972620C10; Wed, 3 May 2017 21:14:02 -0400 (EDT) From: Daniel Kahn Gillmor To: Patrick McManus Cc: HTTP Working Group , DNS Privacy Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> Date: Wed, 03 May 2017 21:13:58 -0400 Message-ID: <8760hhqv8p.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:14:09 -0000 --=-=-= Content-Type: text/plain On Wed 2017-05-03 20:49:22 -0400, Patrick McManus wrote: > the http/1 share of https:// traffic is dwindling fast. Its down to about > 1/3 of https for me. So if you're looking to hide in a big pool, that's a > shrinking segment. 1/3 of https traffic is still huge collateral damage to inflict, if a network adversary were to try to block things to stamp out encrypted DNS traffic. > imo its a bigger problem because any rfc that required h1 would > dis-incentivize h2 which is something the IETF should surely not want to do > for many reasons. I also wouldn't want to disincentivize h2. But any server which still offers h1, at any time in the future could implement this approach with relatively little overhead (and no impact on h2 adoption) and it already works today. So an updated draft would be intended mainly as a stopgap measure while we're getting DNS-over-h2 spec'ed and implemented, and as something a server can offer to clients that don't yet speak h2. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKgFYACgkQFJitxsGS MjeKFg/+KZ9IdQLO9XyCT4dFQtw0CqBkU6Itrbxf/dbO0ArXOJPkzBCAVKL12y7N ifuJar3bs1TWhiUVTAQncEYX5VN1fo8An+FFVsiWlo+EMV+5X2OeMvFUrpjcMCho 7np4J9ScCCal8xKpbNx/jaB/6xiTmxiq3KbxetCetVGB1gEJHH3RnNCgzL+IVGKC 34OX8g/8Umo9+RsHNqnqQtpIs8y4ZfbxAKZ45KSZeM3vXfFHf1wYaK8+okslK0oh lQPSWkagDv9atdWYv3zOqv3sTcYnxZvw4nHwkqgGwi8iPCGUg3ERxKTFujcveMkW G5ItkFrZ4YrjEj/YBZ4GHU/8GPFANXezpLwnPSH2l5dhr7unC7mcxIX+ZJQUprrZ vfh/SlTZIFNpMS+dOjJIB35ABL/L+Du98QvrlnaqfmlqT39b3Jx2s6C4fagSfRvW I8H/8za3pj6LtowQu+7h/8GH/RKMwtOD1CiYJkC/yM9PXJFDhfdb3SRgoH8XMhs7 Ab5UDN0XMs3TTqPPHmTIAxdVsk8mO++dpC6UCy4clIA1qYeM2INeS9Z4sEnuEMCQ NIpcAmjingNwNGxpc1RcO+aTx40r3gaBmzIupJz8tDKnppaSQjm1Fzk1C9xAf0ll waACUCnJFRitdYvBOXuYoKwOYhmepnKK4DzL1r86sdc4F/yiWaA= =C5oG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 18:35:51 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ED812785F for ; Wed, 3 May 2017 18:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_kNmp4sH30o for ; Wed, 3 May 2017 18:35:48 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 95C35127058 for ; Wed, 3 May 2017 18:35:48 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 0D83CF98C; Wed, 3 May 2017 21:35:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 621ED20C10; Wed, 3 May 2017 21:26:49 -0400 (EDT) From: Daniel Kahn Gillmor To: Martin Thomson Cc: Mike Bishop , Patrick McManus , HTTP Working Group , DNS Privacy Working Group In-Reply-To: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> Date: Wed, 03 May 2017 21:26:46 -0400 Message-ID: <8737clqund.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:35:50 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:43, Daniel Kahn Gillmor wrote: >> I address this in the draft section "Why not ALPN?" -- if anyone thinks >> the text there could be improved, i'd be happy to hear suggestions for >> how to change it. > > Mike is suggesting that you define one that is "http + dns" or maybe > "http or dns", which would mean that you could use either. Then you > convince existing HTTP clients to use that (a few browsers would do > the job). Even if they didn't actually DO DNS, you would still be > able to hide in the mass/mess that they represent. hm, it sounds like that won't work for h2, given Patrick's point that h2 isn't client-speaks-first. Right? If we tried to do something like "h2|dns", it seems like it would introduce a potential latency hit for any h2-specific client that proposed it, because the server couldn't send its first frame unsolicited. I know you can't speak for Mozilla, but would you imagine firefox opting into this for normal http/2 connections? > In TLS 1.3, the server choice is hidden, so even where the server > doesn't pick this choice, it works. In TLS 1.2, you probably want to > convince a few servers to pick this new thing, but that obviously > means more work for those servers. For http/1.x, the draft is arguing that using an ALPN label is unnecessary -- so if that's right, what would we gain from a new ALPN label over using the existing HTTP/1.1 mechanism (i.e., either no ALPN or the ALPN token "http/1.1")? It looks to me like the new ALPN label introduces costs: * implementations on both server and client need to specify it =20 * client implementations need to verify that it was chosen, and fail if not =20=20=20 * network monitors can see that it was offered and discriminate against the offerer at least (TLS 1.3), and in some cases the established connections (TLS 1.2 and earlier). What are the benefits of introducing a new ALPN label for demuxing HTTP/1.1 from DNS? Thanks for the discussion, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAlkKg1YACgkQFJitxsGS Mje4ug//fxLhk5XrLe+SVanHk3lCpe2vHg8hdAb5FVDXEGgDHryUmygZhH6WIBPz tIk6DLbx5AYoWdlLJBv517KCJFlADz1yOtYldr6PNeT58ufTU7/ns2YJBAPYHTn7 lVO4JvN7VF1ftMXwm5MWpwBxjbvxmaqOEzQ5KH4J9fqJ5gtVtdbkU/ZTn0hKq0HS b46dAV9sllp1emY/7NDqH4+QYMTV2XMyimi/h3eSkLnUcpZgcLs1BsEJ8Opi5XRz 4a4FIMfptoPFtSqoVm0N86xtTlBGpOCSp2/Ry8ocvtCrjNGx88zW22QAd2cKxo11 Fc4E5YvIMpSQ5yr4YglVzKMAjZs8fLDjUpOT0jY0dlP+F5LF9ZX4Hd74mJ6FTThy B3eQTLM9V/T2ncpsE5fGlOTfKqptu0ktCVzb1YI437fjoCRQ7OWD/NkEVPwSgbp7 kPVeNNSIkkT1TdshsKXU0u40hZdgLcrrqR6n79wscMFXEYeebXMXdiSKDsqTX47O 4fn8G0OBvWzLWoFtF7a5nd/4UaFRnTD5VKc5G7Q2VPH2XDl7zryopsidZyDkUwsV RlZL8LNlwC0/myXEcnr+6ZxwvpM2qTEp+zlQ5cuCnjX2vjezRBR53gbhICxmq05P 95mSXsvKJXde1mTf2+f2ntOtbPvTbqUWExxSg5JuhkF4vCi225I= =xLvM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 3 18:44:35 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998D12785F for ; Wed, 3 May 2017 18:44:32 -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, FREEMAIL_FROM=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 ZEJitFZUNLuj for ; Wed, 3 May 2017 18:44:30 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C35129493 for ; Wed, 3 May 2017 18:44:27 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n4so210916qkc.0 for ; Wed, 03 May 2017 18:44:27 -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=LiG3HTApyk5sO53k1j0SBXynOvYFpC3LZbyr3HzJwDU=; b=iS20iQKjNrs27WZQi3VTNeM1ILcY6MXyUEKaMrXvSQYUIGieQc01oGz0OJKi/JRdYq InkNFQSuxTzV+9aJtBgdwGQQMpbNjHQFoUKELy+e0GIxKGDTGCp2ESIOQixjdkfu17+Z 7k1sNJZkHyYFNSHjtDxd8/T29mem3qE5nvJbRIqw5xGBNW1FDio1D5FrGTlnzkf7tQ5q GNjJAGueeFtmbwg3a4PfnmYXdFWg7faX5Z8aAMY5lE/b99gLi1Ds3Un4ZTwzwgR/sHeU /nldeGobPOsYHv/0H92loAzThq4zbvbJHxNaGopUAESuBwO0WKE7fsIWHwEyFi7OsF8q QEVw== 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=LiG3HTApyk5sO53k1j0SBXynOvYFpC3LZbyr3HzJwDU=; b=VqPq+3CR7AdLlgEc22VX3XOBMTaOCWoHxCzkTBG3vSgdxB/UAwWsuZddINDfrSjgZU RBdEX0XaiSyUSTRF5vgUff8JeGBSr0PcXrWI7IoRdKMUt5ctXN9xyZVodX503KTLaBS0 Jl0t31stN3FApiIyyVgFa5NhgKCAKxfDwrWArCojy6nMdgK6Xzo4VuzJ/Lrt4ailr9Wp oHfQ5sNiqzTArQVUKJezwBUFxTkjPTJC2kSpzjQNqYIoobtAjNy7OEA2WdyOPhQKoMiv ICzsySG8uCxzV0Xv1oGcEMIJFv/6gHvHLCscW8dMmX/TD+qaof/RSKyo9gttM3Fr1Rr/ sqHg== X-Gm-Message-State: AODbwcAL+Ci5FhO5wQmms0qodYot8igbtCri/0odq/VTjwvNnCDZi06J D+JNhYVCgxw5YN0EmP+tBoi1vSOThg== X-Received: by 10.55.146.68 with SMTP id u65mr803428qkd.77.1493862266855; Wed, 03 May 2017 18:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.168.137 with HTTP; Wed, 3 May 2017 18:44:22 -0700 (PDT) In-Reply-To: <8737clqund.fsf@fifthhorseman.net> References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> <8737clqund.fsf@fifthhorseman.net> From: Martin Thomson Date: Thu, 4 May 2017 11:44:22 +1000 Message-ID: To: Daniel Kahn Gillmor Cc: Mike Bishop , Patrick McManus , HTTP Working Group , DNS Privacy Working Group Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 01:44:33 -0000 On 4 May 2017 at 11:26, Daniel Kahn Gillmor wrote: > hm, it sounds like that won't work for h2, given Patrick's point that h2 > isn't client-speaks-first. Right? If we tried to do something like > "h2|dns", it seems like it would introduce a potential latency hit for > any h2-specific client that proposed it, because the server couldn't > send its first frame unsolicited. I know you can't speak for Mozilla, > but would you imagine firefox opting into this for normal http/2 > connections? Patrick owns that decision and could tell you. The cost would be on the DNS-enabled client, who would have to detect and ignore any h2 preface from a server for that protocol. > For http/1.x, the draft is arguing that using an ALPN label is > unnecessary -- so if that's right, what would we gain from a new ALPN > label over using the existing HTTP/1.1 mechanism (i.e., either no ALPN > or the ALPN token "http/1.1")? Upthread we see several reasons why that argument might not be valid. > It looks to me like the new ALPN label introduces costs: > > * implementations on both server and client need to specify it > > * client implementations need to verify that it was chosen, and fail if > not I would have thought that these are benefits. > * network monitors can see that it was offered and discriminate against > the offerer at least (TLS 1.3), and in some cases the established > connections (TLS 1.2 and earlier). A lot depends on the population size. If this were enabled in a sizeable chunk of the browser market, then the TLS 1.3 option goes away. Note that you only create the full exposure if you decide to implement this at a server without also implementing TLS 1.3. > What are the benefits of introducing a new ALPN label for demuxing > HTTP/1.1 from DNS? Certainty, primarily. A clear signal that both peers agree to use the same protocol. It might also reduce ossification effects, but I haven't gamed that out. From nobody Wed May 3 19:53:46 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA81296D2 for ; Wed, 3 May 2017 19:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 yB4FNWn3qnpM for ; Wed, 3 May 2017 19:53:42 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0090.outbound.protection.outlook.com [104.47.32.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEB61296C9 for ; Wed, 3 May 2017 19:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1KxOD8FbPj0rCfYt+lMzT0FYLIZFLtjfE8GqCtNPDcU=; b=e1a3QV4iHJiO2vcGO80t8AnpRH5TVa1H84rXhkrlHvlEU8CFQtIKf1aEqYv0SnOMiKFN57LK6R5E28Ld0pu8W/D0HV/3sRtuzCQ/7QZk7+rXi+KGK+00iA71i2Mb6EfZ/MxddiN11oQy5Phh2g4YaC/7NXUqVnX0yjlHtsqNbds= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 02:53:38 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1061.021; Thu, 4 May 2017 02:53:38 +0000 From: Mike Bishop To: Daniel Kahn Gillmor , Martin Thomson CC: Patrick McManus , HTTP Working Group , DNS Privacy Working Group Thread-Topic: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] Thread-Index: AQHSxGSVzArpJBnINkKlwlv/ObjAOKHjTeBggAACCwCAAAY+AIAAHrUg Date: Thu, 4 May 2017 02:53:38 +0000 Message-ID: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> In-Reply-To: <87bmr9qwn7.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8080:63a8:969:514e:fb21:d263] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:vDj3ZzA0Poqg6bbFZT9wo203q+smOevwM7Cu865zCYD1lCHoN/xue6CrRZlp6isixDIRM2my3wrTfS4W51569WoKGeHxCO7hzPqu9mtr6Nl82Fnzw/oYPbQM6Zn1edC4VEvypawWhoZzz/Igk7VUdGsU1ZMdn4s21vr0AQlX5Wb4na04dzp5kvuq7cPmlQi8KZDlpOnAzNdwDqdLwCBdDv0c036uPNQZJBQoY/Ixef11yjNg0k3/Lpon5jXKunwLHkGPiaLALzxn9E+HTOtHq0VKOO9Ur87/oEbqLt+i2hCRp7pXMQvEjldbXqTUooZqEcrUkZstYvYWSXpt7BYKby2667hyjR6gvSb3nPpoX8k= x-ms-office365-filtering-correlation-id: a719f59e-c7b5-4269-65dd-08d49298c3c2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN6PR03MB2707; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39400400002)(39410400002)(39860400002)(39840400002)(24454002)(377424004)(377454003)(13464003)(74316002)(53546009)(2950100002)(6116002)(5660300001)(8990500004)(10090500001)(7696004)(5005710100001)(2900100001)(102836003)(229853002)(305945005)(3660700001)(15650500001)(3280700002)(2906002)(7736002)(478600001)(189998001)(81166006)(8676002)(86612001)(38730400002)(93886004)(25786009)(10290500003)(230783001)(122556002)(86362001)(8936002)(33656002)(39060400002)(6436002)(53936002)(54906002)(76176999)(9686003)(99286003)(54356999)(4326008)(6246003)(6506006)(77096006)(55016002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 02:53:38.1782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 02:53:44 -0000 No, the network observer can observe which clients are offering that protoc= ol as one of a set of options -- selection happens server-side. In TLS 1.3= , the selection is part of the EncryptedExtensions, no? Which means an obs= erver can tell that the client offers it, but can't tell whether the server= is selecting it at any given time. (Without making the same offer to the = server and seeing what it chooses for them, at least.) As Martin says, if you can get a broad set of clients to start offering it = all the time, a network controller would have to kill a lot of connections = to be sure they didn't let DNS traffic out. (Of course, if major networks = start killing connections with this ALPN token, major implementations would= probably find themselves having to implement a fallback, and you haven't w= on.) My other major issue with your approach is something we learned while= prototyping h2c: Looking at the content of a message and dynamically swap= ping out parsers takes a lot of investment to do performantly. You can bou= nd it by only looking at the beginning of the stream, as you do, but it sti= ll hurts. If you want to do this transparently inside of HTTP without looking differe= nt on the outside, define an HTTP/2 extension for tunneling DNS. Unknown f= rame types and settings MUST be ignored -- the client can start shipping DN= S queries on stream 0 speculatively and have them ignored if the server doe= sn't speak your extension, or wait to see if the server's SETTINGS frame in= dicates that it supports the extension (after 1 RTT), both without any loss= of compatibility or performance (other than extra bytes). It doesn't get = you HTTP/1.x compatibility, but I'm dubious anything you do within that can= be done performantly nor is it a long-term pool to hide in. -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net]=20 Sent: Wednesday, May 3, 2017 5:44 PM To: Martin Thomson ; Mike Bishop Cc: Patrick McManus ; HTTP Working Group ; DNS Privacy Working Group Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version = Notification for draft-dkg-dprive-demux-dns-http-02] On Thu 2017-05-04 10:21:20 +1000, Martin Thomson wrote: > On 4 May 2017 at 10:14, Mike Bishop wrote: >> It's ALPN. At first blush, I would pick a different ALPN token for >> h2+DNS and define it as a new, derivative protocol. > > For DKG to realize his goal, every client would have to offer that=20 > label. That's not impossible, nor does it make it a bad choice, but=20 > you have to realize that this isn't as good an outcome. if you're going to define an ALPN label, you might as well just pick "dns" = and then do straight DNS-over-TLS with it (no need for in-stream demuxing).= The problem with this approach is that the network monitor can observe wh= ich clients are picking "dns" and which ones are picking "http/1.1", which = puts you back in the position where the network adversary can trivially hob= ble DNS-over-TLS requests while permitting HTTPS. I address this in the draft section "Why not ALPN?" -- if anyone thinks the= text there could be improved, i'd be happy to hear suggestions for how to = change it. All the best, --dkg From nobody Wed May 3 20:36:54 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D031129B41 for ; Wed, 3 May 2017 20:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 O4ABrICVfs-1 for ; Wed, 3 May 2017 20:36:52 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32FE129B14 for ; Wed, 3 May 2017 20:36:51 -0700 (PDT) Received: from [169.254.178.128] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v443aRGB055969 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 3 May 2017 20:36:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.178.128] From: "Paul Hoffman" To: "dns-privacy@ietf.org" Date: Wed, 03 May 2017 20:36:49 -0700 Message-ID: <41EE33B8-0FB9-432C-83C7-69DE9F115BD9@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [dns-privacy] draft-hoffman-dns-over-https X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 03:36:53 -0000 This has a similar filename and title as previous drafts, but we started a -00 because the content is different. The discussion should probably happen on the https://www.ietf.org/mailman/listinfo/dnsoverhttp mailing list for now, but it is our intention to bring this to the DISPATCH WG because the draft is more about "foo over HTTP" (which is the purview of DISPATCH) than "DNS in private", even though the latter is assured by the protocol. --Paul Hoffman Name: draft-hoffman-dns-over-https Revision: 00 Title: DNS Queries over HTTPS Document date: 2017-05-03 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-hoffman-dns-over-https-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/ Htmlized: https://tools.ietf.org/html/draft-hoffman-dns-over-https-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoffman-dns-over-https-00 Abstract: DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. This document describes how to run DNS service over HTTP using https:// URIs. [ This paragraph is to be removed when this document is published as an RFC ] Comments on this draft can be sent to the DNS over HTTP mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp . From nobody Thu May 4 02:42:36 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05A912E855 for ; Thu, 4 May 2017 02:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=ahgFkeSF; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=SFfB3UIH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TDXhhQ72Jt9 for ; Thu, 4 May 2017 02:42:32 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AEB12E6D7 for ; Thu, 4 May 2017 02:42:30 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id A450715A057E; Thu, 4 May 2017 11:42:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1493890948; bh=RW52BSMhYeVa50zffCHVhMzmq2uo48N92i9EaTqI+Gs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ahgFkeSFl5/lUIn/tmH3RL9ZkANV2KkTAQ3pKz3OxBD188tTCwPVdIScXwJo3p9Df bQXS5ez4AmbcdtqekEGy376orBXyn7H/1bY+0hOOI8UnPRzaAI1yze4OC5jLBX2LUK zOfuVFAtjpwtHdCjfA/m5LwP/OwLot6eij6rmsnU= Received: from delight.greenbytes.local (unknown [217.91.35.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 1FCBA15A0535; Thu, 4 May 2017 11:42:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1493890946; bh=RW52BSMhYeVa50zffCHVhMzmq2uo48N92i9EaTqI+Gs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=SFfB3UIHIMkaazBM8JQ9vaVkWkni1nwvyBtTGlX8PWVChL/NWjpCOwl1mQ0RF5aZp e4lJIiMISRXyyCbAE0QXW1xk6xUMEnGo2z9z6GCarPRTvaBtK9f/oxdHsHfyDR2aFB 9UY3ruKvtnFvc65xETAkXnqxMB8T7C9/O5XRQezU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Stefan Eissing In-Reply-To: Date: Thu, 4 May 2017 11:42:25 +0200 Cc: Martin Thomson , McManus Patrick , HTTP Working Group , DNS Privacy Working Group , Mike Bishop Content-Transfer-Encoding: quoted-printable Message-Id: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 09:42:35 -0000 > Am 04.05.2017 um 04:53 schrieb Mike Bishop = : >=20 > If you want to do this transparently inside of HTTP without looking = different on the outside, define an HTTP/2 extension for tunneling DNS. = Unknown frame types and settings MUST be ignored -- the client can start = shipping DNS queries on stream 0 speculatively and have them ignored if = the server doesn't speak your extension, or wait to see if the server's = SETTINGS frame indicates that it supports the extension (after 1 RTT), = both without any loss of compatibility or performance (other than extra = bytes). It doesn't get you HTTP/1.x compatibility, but I'm dubious = anything you do within that can be done performantly nor is it a = long-term pool to hide in. I recommend this as a h2 based solution. If a client wants to use the = connection purely for DNS traffic, you just need to add the static = preamble and SETTINGS bytes and prefix each data chunk (of max 16K) with = a 9 byte h2 frame header. And read the same in answers from the server. = Ignoring any frame type you do not know. Flow control is done entirely = by TCP. This gives you an up and down byte stream transferred as h2 extension = frames. The connection handshake looks 100% identical before the strong = encryption kicks in. And you could the same, maybe with some tweaked = frame identifiers, on a QUIC connection in the future, I would assume. If you want to define something that really lives besides other h2 = streams on the same connection, then you need to make use of h2 flow = control and other features. But as I understood, this is not a scenario = you are aiming for. Cheers, -Stefan (h2 in Apache httpd)= From nobody Thu May 4 03:16:13 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AECB12E855 for ; Thu, 4 May 2017 03:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.82 X-Spam-Level: * X-Spam-Status: No, score=1.82 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 dhJe7o6w0zRb for ; Thu, 4 May 2017 03:16:09 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id C77181294F4 for ; Thu, 4 May 2017 03:16:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 9348B20D7D; Thu, 4 May 2017 13:16:06 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id yNDnvQuweoag; Thu, 4 May 2017 13:16:05 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5292CC4; Thu, 4 May 2017 13:16:05 +0300 (EEST) Date: Thu, 4 May 2017 13:16:04 +0300 From: Ilari Liusvaara Cc: DNS Privacy Working Group , HTTP Working Group Message-ID: <20170504101604.GA31988@LK-Perkele-V2.elisa-laajakaista.fi> References: <87tw51remp.fsf@fifthhorseman.net> <87inlhqz4n.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87inlhqz4n.fsf@fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 10:16:11 -0000 On Wed, May 03, 2017 at 07:50:00PM -0400, Daniel Kahn Gillmor wrote: > > Sometimes the backends behind these proxies have to accept traffic directly > > too, and they fingerprint the first few bytes to determine whether it's a > > direct HTTP connection, or a proxied request. I haven't thought through it, > > but it might get a little complicated doing two levels of demuxing, and it > > might not even be possible in some cases. > > Thanks for the pointers to these protocols! It's good to know that > people are already doing this sort of demuxing on the fly in some cases, > and that they haven't broken HTTP for everyone else yet :) > > One approach for the current draft would be to explicitly call these > protocols out as things that are incompatible with he proposed form of > demuxing. I'd be happy to add a generic "do not mix this mechanism with > other similar mechanisms" section. I've just opened > https://gitlab.com/dkg/hddemux/issues/2 to make sure that doesn't get > lost. Note that in case of PROXY, you shouldn't try to discriminate it from DNS. Read the PROXY header if source is configured to have one and then tell apart HTTP and DNS if appropriate. Other reverse proxying schemes that actually play with HTTP headers are incompatible with demuxing HTTP and DNS this way, since those assume that all traffic is HTTP. -Ilari From nobody Thu May 4 11:23:41 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ECC128BB6 for ; Thu, 4 May 2017 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 P78zqF4OYZ0T for ; Thu, 4 May 2017 11:23:37 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B9A12706D for ; Thu, 4 May 2017 11:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I0pW1gtzGjJpTuwiimpL3R9nWjfcPy+amDEaf7JEwSk=; b=jsrIl66j2VOf0fhxHvHH2Y3JLJ3lTMUCudUQ4xpt1Za5O4hdeFIYjFG/QgPxzx3n7i8tQ25nYPhfskGXn6OKFs6LbbDghE1B3eT8/22k1U7lrul0jpDPAeie6LFoxOzfmSGCe2SgMIP/f4ea349Uu36xfpkpSrokL7OXlpwJnDE= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 18:23:36 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.1061.021; Thu, 4 May 2017 18:23:36 +0000 From: Mike Bishop To: Stefan Eissing , Daniel Kahn Gillmor CC: Martin Thomson , McManus Patrick , HTTP Working Group , "DNS Privacy Working Group" Thread-Topic: Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] Thread-Index: AQHSxLrAwbR+E75n5kCXertTWK9cC6HkfSsA Date: Thu, 4 May 2017 18:23:35 +0000 Message-ID: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:8::de] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:h//u0C1E8bDoMR6GzBay2Ln2GCURPCEt4CaX36N8en0zKvqW7fcxmJpvJlxIWPEDvCLs602UxeLl+ZgXZEISZiQ21LyaTo9WphZJ7KMK+b36DQM5Yvi9w6SAF8SOnwZqvKkyX/OUaWD+Hgop22r4SZ8ZOl0dMVFhQ/VAo4Ji73K9ops4h9ba2EkVNSQgIkn7EQeHYKjDSQNruK6RpmYG9ed6zHM1zTNws+Miqblslr2m8tBwaPe3KfVSURJ4KnZpNoU+bITiOW1VGkG01+A1yPIKwuIpNMcaBU12rfVStHyJV9DPtJ3TNzP9nG5DdJ4Utp6zUd/axk50wf0F6avP1qE8pg18P/nJaXv3Keo+dx4= x-ms-office365-filtering-correlation-id: 93f9de20-299a-4c27-05b2-08d4931aadf0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN6PR03MB2707; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39410400002)(39400400002)(39850400002)(39450400003)(13464003)(377454003)(8990500004)(25786009)(53936002)(10290500003)(2900100001)(38730400002)(53546009)(5005710100001)(6506006)(478600001)(6246003)(6436002)(50986999)(86612001)(15650500001)(77096006)(76176999)(54356999)(55016002)(86362001)(99286003)(9686003)(54906002)(74316002)(305945005)(102836003)(6116002)(229853002)(7696004)(5660300001)(93886004)(33656002)(122556002)(39060400002)(2950100002)(230783001)(7736002)(8936002)(81166006)(189998001)(8676002)(3660700001)(10090500001)(3280700002)(2906002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 18:23:35.9671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 18:23:40 -0000 Even on the same connection as HTTP traffic, this would work -- it just wou= ldn't be flow-controlled beyond TCP, while the HTTP/2 streams would be. -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]=20 Sent: Thursday, May 4, 2017 2:42 AM To: Daniel Kahn Gillmor Cc: Martin Thomson ; McManus Patrick ; HTTP Working Group ; DNS Privacy Working G= roup ; Mike Bishop Subject: Re: Demultiplexing HTTP and DNS on the same listener [New Version = Notification for draft-dkg-dprive-demux-dns-http-02] > Am 04.05.2017 um 04:53 schrieb Mike Bishop = : >=20 > If you want to do this transparently inside of HTTP without looking diffe= rent on the outside, define an HTTP/2 extension for tunneling DNS. Unknown= frame types and settings MUST be ignored -- the client can start shipping = DNS queries on stream 0 speculatively and have them ignored if the server d= oesn't speak your extension, or wait to see if the server's SETTINGS frame = indicates that it supports the extension (after 1 RTT), both without any lo= ss of compatibility or performance (other than extra bytes). It doesn't ge= t you HTTP/1.x compatibility, but I'm dubious anything you do within that c= an be done performantly nor is it a long-term pool to hide in. I recommend this as a h2 based solution. If a client wants to use the conne= ction purely for DNS traffic, you just need to add the static preamble and = SETTINGS bytes and prefix each data chunk (of max 16K) with a 9 byte h2 fra= me header. And read the same in answers from the server. Ignoring any frame= type you do not know. Flow control is done entirely by TCP. This gives you an up and down byte stream transferred as h2 extension frame= s. The connection handshake looks 100% identical before the strong encrypti= on kicks in. And you could the same, maybe with some tweaked frame identifi= ers, on a QUIC connection in the future, I would assume. If you want to define something that really lives besides other h2 streams = on the same connection, then you need to make use of h2 flow control and ot= her features. But as I understood, this is not a scenario you are aiming fo= r. Cheers, -Stefan (h2 in Apache httpd) From rousskov@measurement-factory.com Fri May 5 09:27:24 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C28129AE7 for ; Fri, 5 May 2017 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoZCtebQyjDo for ; Fri, 5 May 2017 09:27:23 -0700 (PDT) Received: from mail.measurement-factory.com (mail.measurement-factory.com [104.237.131.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0373C129AD1 for ; Fri, 5 May 2017 09:27:23 -0700 (PDT) Received: from [65.102.233.169] (unknown [65.102.233.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.measurement-factory.com (Postfix) with ESMTPSA id 300BDE02F; Fri, 5 May 2017 16:27:22 +0000 (UTC) To: Daniel Kahn Gillmor References: <87tw51remp.fsf@fifthhorseman.net> <87o9v9r0mh.fsf@fifthhorseman.net> <2564afa5-1a0d-c3e0-e620-37d67482ce28@measurement-factory.com> <87fuglqww2.fsf@fifthhorseman.net> Cc: HTTP Working Group , DNS Privacy Working Group From: Alex Rousskov Message-ID: <26d3a30c-02bd-faca-5bc8-a7d9748a753c@measurement-factory.com> Date: Fri, 5 May 2017 10:27:21 -0600 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87fuglqww2.fsf@fifthhorseman.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 16:30:36 -0000 On 05/03/2017 06:38 PM, Daniel Kahn Gillmor wrote: > On Wed 2017-05-03 17:34:47 -0600, Alex Rousskov wrote: >> Think of the HTTP proxies, not just origin servers. > Here's a few things i think you might be saying: > > 0) A DNS client shouldn't expect this mechanism to work in the clear > over port 80, because existing transparent HTTP proxies that the > client doesn't know about will likely choke on it. I've noted this > as https://gitlab.com/dkg/hddemux/issues/3 > > 1) A DNS client shouldn't expect to use this mechanism through an > explicit HTTP proxy either, as the explicit proxy will also choke on > it. Yes, both. You can address (1) if you add support for HTTP proxies to the DNS client, but, at that point, you should just do the Right Thing and implement DNS-over-HTTP instead IMHO. > However, i'm not sure how this works for port 443. Due to the success of the "TLS everywhere" campaign, port 443 is nearly the same as port 80 from the deployment point of view these days. There are proxies that intercept and inspect port 443 traffic (just like they intercept and inspect port 80 traffic) and there are explicit proxies that inspect CONNECT tunnels, just like they inspect unencrypted HTTP messages. Needless to say, your DNS client may prohibit such inspections (like some HTTP sites/apps do) at the risk of being blocked or let the users/admin configure who to trust (like HTTP clients do). > Do you have suggestions of text for the draft that would address these > concerns? AFAICT, these concerns cannot be properly addressed in the proposed DNS-or-HTTP framework. They can only be addressed by a proper DNS-over-HTTP protocol. HTH, Alex. From nobody Sat May 6 13:31:14 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AAD124E15; Sat, 6 May 2017 13:31:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149410267259.23107.8936430130975036477.idtracker@ietfa.amsl.com> Date: Sat, 06 May 2017 13:31:12 -0700 Archived-At: Subject: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 20:31:13 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- S 9 mandates RFC 7250: o Raw public keys [RFC7250] which reduce the size of the ServerHello, and can be used by servers that cannot obtain certificates (e.g., DNS servers on private networks). This needs to be updated to indicate that the client MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise you're going to have interop problems. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- TECHNICAL S 5. subsequently connect. The rationale for this is that requiring Strict Privacy for such meta queries would introduce significant deployment obstacles. This profile provides strong privacy guarantees to the client. This Profile is discussed in detail in Section 6.6. This point seems unclear. If you do these queries unprotected, then you don't have strong privacy guarantees. I think you mean that you get them via some trusted mechanism such as DHCP. widespread adoption of Strict Privacy. It should be employed when the DNS client might otherwise settle for cleartext; it provides the maximum protection available. I don't think this statement is accurate. It provides the best protection that the attacker will allow. Table 1 seems to have N and D paired, so maybe you can coalesce them? S 6.4. A DNS client that is configured with both an authentication domain name and a SPKI pinset for a DNS server SHOULD match on both a valid credential for the authentication domain name and a valid SPKI pinset (if both are available) when connecting to that DNS server. The overall authentication result should only be considered successful if both authentication mechanisms are successful. You should cover the topic of user-defined trust anchors. Here's the relevant text from 7469: For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform). EDITORIAL Do you want to cite TLS 1.3 at this point? S 3. o Any server identifier other than domain names, including IP address, organizational name, country of origin, etc. addresses, names, for parallel structure with domain names S 9. There are known attacks on (D)TLS, such as machine-in-the-middle and protocol downgrade. These are general attacks on (D)TLS and not specific to DNS-over-TLS; please refer to the (D)TLS RFCs for discussion of these security issues. This text seems pretty unhelpful. Given that you are specifying 1.2, if you also require the relevant strong algorithms, then there should not be downgrade or MITM attacks. From nobody Mon May 8 01:21:32 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F1712426E; Mon, 8 May 2017 01:21:25 -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 QTHFj5S_GaNG; Mon, 8 May 2017 01:21:23 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AE7120724; Mon, 8 May 2017 01:21:23 -0700 (PDT) Received: from [2a02:8010:6126:0:a50b:3fa2:10d3:edf3] (port=50916) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1d7duu-0002As-Ji; Mon, 08 May 2017 09:21:19 +0100 From: Sara Dickinson Message-Id: <79402B6C-B8FB-4115-AB12-9943FF585D21@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4A8C5307-C02B-41F5-8239-D10F65CCF7CD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 8 May 2017 09:21:10 +0100 In-Reply-To: <149410267259.23107.8936430130975036477.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org To: Eric Rescorla References: <149410267259.23107.8936430130975036477.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 08:21:25 -0000 --Apple-Mail=_4A8C5307-C02B-41F5-8239-D10F65CCF7CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 May 2017, at 21:31, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss Many thanks for the review. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > S 9 mandates RFC 7250: > o Raw public keys [RFC7250] which reduce the size of the > ServerHello, and can be used by servers that cannot obtain > certificates (e.g., DNS servers on private networks). >=20 > This needs to be updated to indicate that the client MUST NOT > offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have interop problems. Agreed. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > TECHNICAL > S 5. > subsequently connect. The rationale for this is that requiring > Strict Privacy for such meta queries would introduce significant > deployment obstacles. This profile provides strong privacy > guarantees to the client. This Profile is discussed in detail in > Section 6.6. >=20 > This point seems unclear. If you do these queries unprotected, then > you don't have strong privacy guarantees. I think you mean that > you get them via some trusted mechanism such as DHCP. No, we mean they could be done either via Opportunistic lookups or DHCP = (see table 2.) The meta queries contain no information about what DNS lookups the = client is doing other than what DNS Privacy server they are going to use = to do their queries. But you are correct that the =E2=80=98strong = privacy guarentees=E2=80=99 apply only to the subsequent queries to the = Privacy server and the text should be updated to clarify that. =20 >=20 > widespread adoption of Strict Privacy. It should be employed > when > the DNS client might otherwise settle for cleartext; it provides > the maximum protection available. >=20 > I don't think this statement is accurate. It provides the best > protection > that the attacker will allow. Agreed - will update.=20 >=20 > Table 1 seems to have N and D paired, so maybe you can coalesce them? That specific question was asked on the WG mailing list and the answer = was =E2=80=98no, please keep both=E2=80=99: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html = >=20 >=20 > S 6.4. > A DNS client that is configured with both an authentication domain > name and a SPKI pinset for a DNS server SHOULD match on both a valid > credential for the authentication domain name and a valid SPKI > pinset > (if both are available) when connecting to that DNS server. The > overall authentication result should only be considered successful > if > both authentication mechanisms are successful. >=20 > You should cover the topic of user-defined trust anchors. Here's the > relevant text from 7469: >=20 > For example, a UA may disable Pin Validation for Pinned Hosts whose > validated certificate chain terminates at a user-defined trust > anchor, rather than a trust anchor built-in to the UA (or underlying > platform). We purposely avoided adding any details on the SPKI mechanisms in this = document because this document simply refers to RFC7585 which then = directly references RFC7469. But if you think this is needed here also = then I=E2=80=99ll add it. >=20 > EDITORIAL > Do you want to cite TLS 1.3 at this point? Early on we chose not to include a normative reference to the TLS 1.3 = draft to avoid the dependancy on that becoming an RFC but are you = suggesting we do that now or just include an informative reference? Do you think Section 9 the right place to talk about TLS 1.3 in general = or do you feel there are specific points to made elsewhere in the text?=20= >=20 > S 3. > o Any server identifier other than domain names, including IP > address, organizational name, country of origin, etc. >=20 > addresses, names, for parallel structure with domain names Ack. >=20 >=20 > S 9. > There are known attacks on (D)TLS, such as machine-in-the-middle and > protocol downgrade. These are general attacks on (D)TLS and not > specific to DNS-over-TLS; please refer to the (D)TLS RFCs for > discussion of these security issues. >=20 > This text seems pretty unhelpful. Given that you are specifying 1.2, > if you also require the relevant strong algorithms, then there should > not be downgrade or MITM attacks. How about moving the justification later in the section: =E2=80=9C Clients and servers MUST adhere to the (D)TLS implementation recommendations and security considerations of [RFC7525] except with respect to (D)TLS version. Since encryption of DNS using (D)TLS is a green-field deployment DNS clients and servers MUST implement only (D)TLS 1.2 or later. These requirements ensure mitigation against known attacks on=20 (D)TLS, such as machine-in-the-middle and protocol downgrade. These are general attacks on (D)TLS and not specific to DNS-over-TLS.=E2=80=9D Regards Sara.=20 --Apple-Mail=_4A8C5307-C02B-41F5-8239-D10F65CCF7CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 6 May 2017, at 21:31, Eric Rescorla <ekr@rtfm.com> = wrote:

Eric Rescorla has entered the following ballot position = for
draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss

Many = thanks for the review.

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

S 9 mandates RFC 7250:
=   o  Raw public keys [RFC7250] which reduce the size of = the
     ServerHello, and can be = used by servers that cannot obtain
=      certificates (e.g., DNS servers on private = networks).

This needs to be updated to = indicate that the client MUST NOT
offer 7250 unless it has = a preconfigured SPKI, otherwise
you're going to have = interop problems.

Agreed.

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

TECHNICAL
S 5.
     subsequently connect. =  The rationale for this is that requiring
=      Strict Privacy for such meta queries would = introduce significant
=      deployment obstacles.  This profile = provides strong privacy
=      guarantees to the client.  This = Profile is discussed in detail in
=      Section 6.6.

This point seems unclear. If you do these queries = unprotected, then
you don't have strong privacy = guarantees. I think you mean that
you get them via some = trusted mechanism such as DHCP.

No, = we mean they could be done either via Opportunistic lookups or DHCP (see = table 2.)
The meta queries contain no information about what = DNS lookups the client is doing other than what DNS Privacy server they = are going to use to do their queries. But you are correct that the = =E2=80=98strong privacy guarentees=E2=80=99 apply only to the subsequent = queries to the Privacy server and the text should be updated to clarify = that.  


=      widespread adoption of Strict Privacy. =  It should be employed
when
=      the DNS client might otherwise settle for = cleartext; it provides
     the = maximum protection available.

I don't think = this statement is accurate. It provides the best
protection
that the attacker will allow.

Agreed = - will update. 


Table 1 seems to have N and D paired, so maybe you can = coalesce them?

That specific question was asked on the WG mailing = list and the answer was =E2=80=98no, please keep both=E2=80=99:



S 6.4.
  A DNS client that is configured with both an = authentication domain
  name and a SPKI pinset = for a DNS server SHOULD match on both a valid
=   credential for the authentication domain name and a valid = SPKI
pinset
  (if both are = available) when connecting to that DNS server.  The
=   overall authentication result should only be considered = successful
if
  both = authentication mechanisms are successful.

You= should cover the topic of user-defined trust anchors. Here's the
relevant text from 7469:

=   For example, a UA may disable Pin Validation for Pinned = Hosts whose
  validated certificate chain = terminates at a user-defined trust
  anchor, = rather than a trust anchor built-in to the UA (or underlying
  platform).

We = purposely avoided adding any details on the SPKI mechanisms in this = document because this document simply refers to RFC7585 which then = directly references RFC7469. But if you think this is needed here also = then I=E2=80=99ll add it.


EDITORIAL
Do you want to cite TLS 1.3 at this point?

Early on = we chose not to include a normative reference to the TLS 1.3 draft to = avoid the dependancy on that becoming an RFC but are you suggesting we = do that now or just include an informative reference?

Do you think Section 9 the = right place to talk about TLS 1.3 in general or do you feel there are = specific points to made elsewhere in the text? 


S 3.
  o  Any = server identifier other than domain names, including IP
=      address, organizational name, country of = origin, etc.

addresses, names, for parallel = structure with domain names

Ack.



S= 9.
  There are known attacks on (D)TLS, such = as machine-in-the-middle and
  protocol = downgrade.  These are general attacks on (D)TLS and not
  specific to DNS-over-TLS; please refer to the = (D)TLS RFCs for
  discussion of these security = issues.

This text seems pretty unhelpful. = Given that you are specifying 1.2,
if you also require the = relevant strong algorithms, then there should
not be = downgrade or MITM attacks.

How about moving the justification later in the = section:

=E2=80=9C = Clients and servers MUST adhere to the (D)TLS implementation
   recommendations and security considerations of = [RFC7525] except with
   respect to = (D)TLS version.

  Since encryption of DNS using (D)TLS = is a green-field deployment DNS
  =  clients and servers MUST implement only (D)TLS 1.2 or = later.

  These requirements ensure mitigation against known = attacks on 
  (D)TLS, such as = machine-in-the-middle and
  protocol downgrade. =  These are general attacks on (D)TLS and not
  specific to DNS-over-TLS.=E2=80=9D

Regards

Sara. 
= --Apple-Mail=_4A8C5307-C02B-41F5-8239-D10F65CCF7CD-- From nobody Mon May 8 05:02:41 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99A412944C for ; Mon, 8 May 2017 05:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] autolearn=unavailable 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 zZc5niTTZrzX for ; Mon, 8 May 2017 05:02:33 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E99F129449 for ; Mon, 8 May 2017 05:02:30 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l135so27924544ywb.2 for ; Mon, 08 May 2017 05:02:30 -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=GVRbBLePxwsjxscTuUJzh/0cjuyVYDi3uCElKcb8jBg=; b=NW/3ShZCJ2/kytIqDVToMgx+FX198DVJ8vX2xXZ3iyMDAa22teQu1lMbvWSXigbpWV 7lNSSluChX24rFM3HcyJPl/CwrWQW5D5YH0jwgaRnTb7uJ8LoahKMLTD6tQrWMYFVoA2 CNxGDlGHyaNozOAacJ+5iEQohOm0ekwsV24sG8RvPRuCkMn3r/To8zGaQojeUPCfIlZ6 T40rB576UVDapvt091H3W+jXFfYU19+XhAGrbcDl0HK3mSTD8tDrFxjG/Zev80atjNQi eow2EDbLoQeESKBtvncwfJDstOunWYJxDcY3O9Is8Cn1tQJ5PeTHDD7ySoz3909/o8wG 2FUg== 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=GVRbBLePxwsjxscTuUJzh/0cjuyVYDi3uCElKcb8jBg=; b=CfebRowzym3f++e9Er0dFpdx01x7t080wUeSuVnkYSEjr/ZaEYk1boKA/LlBZkt/Sa TYVcyUkJ3RNUnoeJXyTDJQepjP1eBjh9/wyo4ZflLQwfPSoDjU0RphUfCTRUhnLFg5s5 aPIbcwBO7X1q5U/4bAiSZ5Q8nlnu96cb4HZ5Ql33Z+wRS4wVhEsJSB0sMHKrwFybKjz4 MvNKEjcdccTn5fiEcCUVU20Wr7pIdID2snXRnlbXoEjavIjOcyafcb+ZsbCv/Iz8qe/z 2FKZNNov9lIFbUkZH8GuNr/nje64BfJ+T1biG3kGXvi2nvAVAswOqN6ccYnIaemdanGM bevg== X-Gm-Message-State: AODbwcBA6oFWUX0gyaN8qGg7FXuTOsp9SGTr48qnaPNZU6Hnzy2FxZN3 BDEbEq4wv0eddnaSpf3rb8fDgyY1+w== X-Received: by 10.129.85.83 with SMTP id j80mr11859784ywb.283.1494244949850; Mon, 08 May 2017 05:02:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Mon, 8 May 2017 05:01:49 -0700 (PDT) In-Reply-To: <79402B6C-B8FB-4115-AB12-9943FF585D21@sinodun.com> References: <149410267259.23107.8936430130975036477.idtracker@ietfa.amsl.com> <79402B6C-B8FB-4115-AB12-9943FF585D21@sinodun.com> From: Eric Rescorla Date: Mon, 8 May 2017 05:01:49 -0700 Message-ID: To: Sara Dickinson Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org Content-Type: multipart/alternative; boundary=001a113f3cbe719b18054f020379 Archived-At: Subject: Re: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 12:02:36 -0000 --001a113f3cbe719b18054f020379 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson wrote: > > On 6 May 2017, at 21:31, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss > > > Many thanks for the review. > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > S 9 mandates RFC 7250: > o Raw public keys [RFC7250] which reduce the size of the > ServerHello, and can be used by servers that cannot obtain > certificates (e.g., DNS servers on private networks). > > This needs to be updated to indicate that the client MUST NOT > offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have interop problems. > > > Agreed. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > TECHNICAL > S 5. > subsequently connect. The rationale for this is that requiring > Strict Privacy for such meta queries would introduce significant > deployment obstacles. This profile provides strong privacy > guarantees to the client. This Profile is discussed in detail in > Section 6.6. > > This point seems unclear. If you do these queries unprotected, then > you don't have strong privacy guarantees. I think you mean that > you get them via some trusted mechanism such as DHCP. > > > No, we mean they could be done either via Opportunistic lookups or DHCP > (see table 2.) > The meta queries contain no information about what DNS lookups the client > is doing other than what DNS Privacy server they are going to use to do > their queries. But you are correct that the =E2=80=98strong privacy guare= ntees=E2=80=99 > apply only to the subsequent queries to the Privacy server and the text > should be updated to clarify that. > Well, per my previous comment, I think you need to focus on the entire strategy. I.e., if you determine whether to adopt a Strict policy based on Opportunistic queries, then you are back to the active attack setting. I don't have a problem with your design here, which seems to be about as good as one can do; I'm just trying to make sure the description is accurate... Table 1 seems to have N and D paired, so maybe you can coalesce them? > > > That specific question was asked on the WG mailing list and the answer wa= s > =E2=80=98no, please keep both=E2=80=99: > https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html > OK. Perhaps add some text that theya re paired S 6.4. > A DNS client that is configured with both an authentication domain > name and a SPKI pinset for a DNS server SHOULD match on both a valid > credential for the authentication domain name and a valid SPKI > pinset > (if both are available) when connecting to that DNS server. The > overall authentication result should only be considered successful > if > both authentication mechanisms are successful. > > You should cover the topic of user-defined trust anchors. Here's the > relevant text from 7469: > > For example, a UA may disable Pin Validation for Pinned Hosts whose > validated certificate chain terminates at a user-defined trust > anchor, rather than a trust anchor built-in to the UA (or underlying > platform). > > > We purposely avoided adding any details on the SPKI mechanisms in this > document because this document simply refers to RFC7585 which then direct= ly > references RFC7469. But if you think this is needed here also then I=E2= =80=99ll add > it. > The concern I have is that this guidance seems to implicitly contradict the guidance from 7469. So I think you should either just say that if you have both you treat it like a 7469 pin, or say something like "successful, with the possible exception of certificates which chain to local trust anchors, as described in..." Or, alternately really prohibit this. Also, should -> SHOULD. > > > EDITORIAL > Do you want to cite TLS 1.3 at this point? > > > Early on we chose not to include a normative reference to the TLS 1.3 > draft to avoid the dependancy on that becoming an RFC but are you > suggesting we do that now or just include an informative reference? > I would think at least an informative reference would be useful. Do you think Section 9 the right place to talk about TLS 1.3 in general or > do you feel there are specific points to made elsewhere in the text? > 1.3 has pretty much the same properties here, so I think you might just cite 1.3 and make it informative. I'm not sure what the right actual mechanics are here, but surely such a thing is possible. > S 3. > o Any server identifier other than domain names, including IP > address, organizational name, country of origin, etc. > > addresses, names, for parallel structure with domain names > > > Ack. > > > > S 9. > There are known attacks on (D)TLS, such as machine-in-the-middle and > protocol downgrade. These are general attacks on (D)TLS and not > specific to DNS-over-TLS; please refer to the (D)TLS RFCs for > discussion of these security issues. > > This text seems pretty unhelpful. Given that you are specifying 1.2, > if you also require the relevant strong algorithms, then there should > not be downgrade or MITM attacks. > > > How about moving the justification later in the section: > > =E2=80=9C Clients and servers MUST adhere to the (D)TLS implementation > recommendations and security considerations of [RFC7525] except with > respect to (D)TLS version. > > Since encryption of DNS using (D)TLS is a green-field deployment DNS > clients and servers MUST implement only (D)TLS 1.2 or later. > > These requirements ensure mitigation against known attacks on > (D)TLS, such as machine-in-the-middle and > protocol downgrade. These are general attacks on (D)TLS and not > specific to DNS-over-TLS.=E2=80=9D > My complaint is that this seems kinda FUDdy. If there are things that you think people ought to do other than those in 7525, you ought to say them. -Ekr --001a113f3cbe719b18054f020379 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson <sara@sinodun.com>= ; wrote:

On 6 Ma= y 2017, at 21:31, Eric Rescorla <ekr@rtfm.com> wrote:

Eric Rescorla has entered the fol= lowing ballot position for
draft-ietf-dprive-dtls-and-tls-profiles-= 09: Discuss

Many tha= nks for the review.

--------------------------------------------------= --------------------
DISCUSS:
----------------------------------------------------------------------

S 9 mandates RFC 7250= :
=C2=A0=C2=A0o =C2=A0Raw public keys [RFC7250] which reduce the size o= f the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ServerHello, and can be used by ser= vers that cannot obtain
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0certificates (e.g= ., DNS servers on private networks).

This needs to be updated to ind= icate that the client MUST NOT
offer 7250 unless it has a preconfigured = SPKI, otherwise
you're going to have interop problems.

Agreed.
---------------------------------= -------------------------------------
COMMENT:
-----------------= -----------------------------------------------------

TECH= NICAL
S 5.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0subsequently connect.=C2=A0= The rationale for this is that requiring
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Strict Privacy for such meta queries would introduce significant
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0deployment obstacles.=C2=A0 This profile provide= s strong privacy
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0guarantees to the client= .=C2=A0 This Profile is discussed in detail in
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Section 6.6.

This point seems unclear. If you do these queries= unprotected, then
you don't have strong privacy guarantees. I think= you mean that
you get them via some trusted mechanism such as DHCP.
=

No, we mean they could = be done either via Opportunistic lookups or DHCP (see table 2.)
T= he meta queries contain no information about what DNS lookups the client is= doing other than what DNS Privacy server they are going to use to do their= queries. But you are correct that the =E2=80=98strong privacy guarentees= =E2=80=99 apply only to the subsequent queries to the Privacy server and th= e text should be updated to clarify that. =C2=A0

Well, per my previous comment, I think you need to = focus on the entire strategy.

I.e., if you determi= ne whether to adopt a Strict policy based on Opportunistic queries, then yo= u are back to the active attack setting. I don't have a problem with yo= ur design here, which seems to be about as good as one can do; I'm just= trying to make sure the description is accurate...


Table 1 seems= to have N and D paired, so maybe you can coalesce them?

That specific question was asked on th= e WG mailing list and the answer was =E2=80=98no, please keep both=E2=80=99= :

OK. Perhaps add some text that theya re paired
=C2=A0


S 6.4.
=C2=A0=C2=A0A DNS client that is configu= red with both an authentication domain
=C2=A0=C2=A0name and a SPKI pins= et for a DNS server SHOULD match on both a valid
=C2=A0=C2=A0credential= for the authentication domain name and a valid SPKI
pinset
=C2=A0= =C2=A0(if both are available) when connecting to that DNS server.=C2=A0 The=
=C2=A0=C2=A0overall authentication result should only be considered su= ccessful
if
=C2=A0=C2=A0both authentication mechanisms are successfu= l.

You should cover the topic of user-defined trust anchors. Here= 9;s the
relevant text from 7469:

=C2=A0=C2=A0For example, a UA m= ay disable Pin Validation for Pinned Hosts whose
=C2=A0=C2=A0validated = certificate chain terminates at a user-defined trust
=C2=A0=C2=A0anchor= , rather than a trust anchor built-in to the UA (or underlying
=C2=A0= =C2=A0platform).

We = purposely avoided adding any details on the SPKI mechanisms in this documen= t because this document simply refers to RFC7585 which then directly refere= nces RFC7469. But if you think this is needed here also then I=E2=80=99ll a= dd it.

The concern I have= is that this guidance seems to implicitly contradict the guidance from 746= 9. So I think you should either just say that if you have both you treat it= like a 7469 pin, or say something like "successful, with the possible= exception of certificates which chain to local trust anchors, as described= in..." Or, alternately really prohibit this. Also, should -> SHOUL= D.
=C2=A0

<= div>
EDITORIAL
Do you want to cite TLS 1.3 at this point?

Early on we chose not to include a n= ormative reference to the TLS 1.3 draft to avoid the dependancy on that bec= oming an RFC but are you suggesting we do that now or just include an infor= mative reference?

I would t= hink at least an informative reference would be useful.


Do you think Section 9 the right place to talk about TLS = 1.3 in general or do you feel there are specific points to made elsewhere i= n the text?=C2=A0

1.3 has= pretty much the same properties here, so I think you might just cite 1.3 a= nd make it informative. I'm not sure what the right actual mechanics ar= e here, but surely such a thing is possible.

=C2= =A0
S 3.
=C2=A0= =C2=A0o =C2=A0Any server identifier other than domain names, including IP =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0address, organizational name, country of o= rigin, etc.

addresses, names, for parallel structure with domain nam= es

Ack.



S 9.
=C2=A0= =C2=A0There are known attacks on (D)TLS, such as machine-in-the-middle and<= br> =C2=A0=C2=A0protocol downgrade.=C2=A0 These are general attacks on (D)T= LS and not
=C2=A0=C2=A0specific to DNS-over-TLS; please refer to the (D= )TLS RFCs for
=C2=A0=C2=A0discussion of these security issues.

T= his text seems pretty unhelpful. Given that you are specifying 1.2,
if y= ou also require the relevant strong algorithms, then there should
not be= downgrade or MITM attacks.

How about moving the justification later in the section:

<= /div>
=E2=80=9C Clients and servers MUST adhere to the (D)TLS impl= ementation
=C2=A0 =C2=A0recommendations and security consideratio= ns of [RFC7525] except with
=C2=A0 =C2=A0respect to (D)TLS versio= n.

=C2=A0 Since encryption of DNS using (D)TL= S is a green-field deployment DNS
=C2=A0 =C2=A0clients and server= s MUST implement only (D)TLS 1.2 or later.

= =C2=A0 These requirements ensure mitigation against known attacks on=C2=A0<= /div>
=C2=A0 (D)TLS, such as machine-in-the-middle and=
=C2=A0=C2=A0protocol downgrade.=C2=A0 These are general attacks on (D)T= LS and not
=C2=A0=C2=A0specific to DNS-over-TLS.=E2=80=9D

My complaint is that this seems = kinda FUDdy. If there are things that you think people
ought to d= o other than those in 7525, you ought to say them.

-Ekr

--001a113f3cbe719b18054f020379-- From nobody Mon May 8 18:20:45 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E611D127ABE for ; Mon, 8 May 2017 18:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfyhK5Nraa9l for ; Mon, 8 May 2017 18:20:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 D4DD5126C83 for ; Mon, 8 May 2017 18:20:41 -0700 (PDT) Received: from [192.168.1.18] (unknown [124.189.96.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 97FD022E1F3; Mon, 8 May 2017 21:20:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <8737clqund.fsf@fifthhorseman.net> Date: Tue, 9 May 2017 11:20:30 +1000 Cc: Martin Thomson , Mike Bishop , Patrick McManus , HTTP Working Group , DNS Privacy Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> <8737clqund.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 01:20:44 -0000 Hey DKG, Throwing my .02 in, although it's similar to what you've heard from = others upthread -- I wouldn't do this for h1; it'll be an interop nightmare. H2 gives you = the properties you want and the implementation / testing burden is much = more realistic. For H2, I wouldn't use an ALPN token; define a new frame type or two = that you can send optimistically before SETTINGS sync, stopping them if = you don't get the right SETTING from your peer. Realistically, this is = going to need to be configured into the client anyway, so there's some = amount of pre-arrangement. Cheers, > On 4 May 2017, at 11:26 am, Daniel Kahn Gillmor = wrote: >=20 > On Thu 2017-05-04 11:11:59 +1000, Martin Thomson wrote: >> On 4 May 2017 at 10:43, Daniel Kahn Gillmor = wrote: >>> I address this in the draft section "Why not ALPN?" -- if anyone = thinks >>> the text there could be improved, i'd be happy to hear suggestions = for >>> how to change it. >>=20 >> Mike is suggesting that you define one that is "http + dns" or maybe >> "http or dns", which would mean that you could use either. Then you >> convince existing HTTP clients to use that (a few browsers would do >> the job). Even if they didn't actually DO DNS, you would still be >> able to hide in the mass/mess that they represent. >=20 > hm, it sounds like that won't work for h2, given Patrick's point that = h2 > isn't client-speaks-first. Right? If we tried to do something like > "h2|dns", it seems like it would introduce a potential latency hit for > any h2-specific client that proposed it, because the server couldn't > send its first frame unsolicited. I know you can't speak for Mozilla, > but would you imagine firefox opting into this for normal http/2 > connections? >=20 >> In TLS 1.3, the server choice is hidden, so even where the server >> doesn't pick this choice, it works. In TLS 1.2, you probably want to >> convince a few servers to pick this new thing, but that obviously >> means more work for those servers. >=20 > For http/1.x, the draft is arguing that using an ALPN label is > unnecessary -- so if that's right, what would we gain from a new ALPN > label over using the existing HTTP/1.1 mechanism (i.e., either no ALPN > or the ALPN token "http/1.1")? >=20 > It looks to me like the new ALPN label introduces costs: >=20 > * implementations on both server and client need to specify it >=20 > * client implementations need to verify that it was chosen, and fail = if > not >=20 > * network monitors can see that it was offered and discriminate = against > the offerer at least (TLS 1.3), and in some cases the established > connections (TLS 1.2 and earlier). >=20 > What are the benefits of introducing a new ALPN label for demuxing > HTTP/1.1 from DNS? >=20 > Thanks for the discussion, >=20 > --dkg -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 8 21:29:58 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5A12704B for ; Mon, 8 May 2017 21:29:57 -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, RP_MATCHES_RCVD=-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 9f-HxdpKlLgO for ; Mon, 8 May 2017 21:29:55 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6093E12025C for ; Mon, 8 May 2017 21:29:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 81E9421CD0; Tue, 9 May 2017 07:29:52 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id OMjOooN0vwzs; Tue, 9 May 2017 07:29:52 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3D41D27F; Tue, 9 May 2017 07:29:52 +0300 (EEST) Date: Tue, 9 May 2017 07:29:51 +0300 From: Ilari Liusvaara To: Mark Nottingham Cc: DNS Privacy Working Group , HTTP Working Group Message-ID: <20170509042951.GA8239@LK-Perkele-V2.elisa-laajakaista.fi> References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> <8737clqund.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:29:57 -0000 On Tue, May 09, 2017 at 11:20:30AM +1000, Mark Nottingham wrote: > Hey DKG, > > Throwing my .02 in, although it's similar to what you've heard from > others upthread -- > > I wouldn't do this for h1; it'll be an interop nightmare. H2 gives > you the properties you want and the implementation / testing burden > is much more realistic. > > For H2, I wouldn't use an ALPN token; define a new frame type or two > that you can send optimistically before SETTINGS sync, stopping them > if you don't get the right SETTING from your peer. Realistically, > this is going to need to be configured into the client anyway, so > there's some amount of pre-arrangement. I don't think what you are saying is workable. >From what I can gather, the intention for this thing DKG gave is to be pure TLS-wrapped DNS from the client side. Any SETTINGS or otherwise from the server breaks this. And it can not use any odd ALPN values either. This impiles this thing can't be used with HTTP/2, as it is both- sides-send-first, instead of client-sends-first. Yes, if you try this with random HTTP server, it will choke. The intention is that the client knows via configuration that the HTTP server is capable of DNS demux. The schemes for riding DNS on top of HTTP or HTTP/2 framing structure are totally different thing. Those are obviously more compatible with HTTP/2. -Ilari From nobody Mon May 8 21:32:31 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2172512704B for ; Mon, 8 May 2017 21:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdXgyRB27ET4 for ; Mon, 8 May 2017 21:32:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 61987120227 for ; Mon, 8 May 2017 21:32:27 -0700 (PDT) Received: from [192.168.1.18] (unknown [124.189.96.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6A3C622E1F3; Tue, 9 May 2017 00:32:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <20170509042951.GA8239@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 9 May 2017 14:32:17 +1000 Cc: DNS Privacy Working Group , HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <87tw51remp.fsf@fifthhorseman.net> <87lgqdr0fr.fsf@fifthhorseman.net> <87bmr9qwn7.fsf@fifthhorseman.net> <8737clqund.fsf@fifthhorseman.net> <20170509042951.GA8239@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02] X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:32:30 -0000 > On 9 May 2017, at 2:29 pm, Ilari Liusvaara = wrote: >=20 > On Tue, May 09, 2017 at 11:20:30AM +1000, Mark Nottingham wrote: >> Hey DKG, >>=20 >> Throwing my .02 in, although it's similar to what you've heard from >> others upthread -- >>=20 >> I wouldn't do this for h1; it'll be an interop nightmare. H2 gives >> you the properties you want and the implementation / testing burden >> is much more realistic. >>=20 >> For H2, I wouldn't use an ALPN token; define a new frame type or two >> that you can send optimistically before SETTINGS sync, stopping them >> if you don't get the right SETTING from your peer. Realistically, >> this is going to need to be configured into the client anyway, so >> there's some amount of pre-arrangement. >=20 > I don't think what you are saying is workable. >=20 > =46rom what I can gather, the intention for this thing DKG gave is to > be pure TLS-wrapped DNS from the client side. Any SETTINGS or = otherwise > from the server breaks this. And it can not use any odd ALPN values > either. >=20 > This impiles this thing can't be used with HTTP/2, as it is both- > sides-send-first, instead of client-sends-first. >=20 > Yes, if you try this with random HTTP server, it will choke. The > intention is that the client knows via configuration that the HTTP > server is capable of DNS demux. >=20 >=20 > The schemes for riding DNS on top of HTTP or HTTP/2 framing structure > are totally different thing. Those are obviously more compatible with > HTTP/2. Sorry if it wasn't clear -- what I was saying was "don't do this (DKG's = proposal); do that (DNS-over-HTTP)". -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 9 15:35:48 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3521A12EB61; Tue, 9 May 2017 15:35:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149436934221.22615.14732188129909428883.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 15:35:42 -0700 Archived-At: Subject: [dns-privacy] Alexey Melnikov's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:35:42 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to ballot YES on this document, but I would like to discuss the following: Sorry for being DownRef police, but RFC 7918 is clearly Normative (because there is a SHOULD level requirement), but it is listed as Informative reference. It would be a DownRef once it is made Normative, unless the procedure in RFC 8067 is used. Is RFC 7918 a suitable DownRef? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am agreeing with Ekr comments. From nobody Tue May 9 15:43:08 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E604512714F; Tue, 9 May 2017 15:43:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149436978593.19294.10256470803161992800.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 15:43:05 -0700 Archived-At: Subject: [dns-privacy] Alexey Melnikov's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:43:06 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (I just updated both my DISCUSS and my comment section.) I would like to ballot YES on this document, but I would like to discuss the following: Sorry for being DownRef police, but RFC 7918 is clearly Normative (because there is a SHOULD level requirement), but it is listed as Informative reference. It would be a DownRef once it is made Normative, unless the procedure from RFC 8067 is used. Is RFC 7918 a suitable DownRef? Is it widely implemented? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am agreeing with Ekr comments. I am also agreeing on first and last Mirja's comment. Section on future DHCP extension is a bit "hand-wavy". Is any work on this planned? From nobody Tue May 9 16:28:10 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7255B124E15; Tue, 9 May 2017 16:28:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149437248346.22508.847522278141179102.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 16:28:03 -0700 Archived-At: Subject: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 23:28:04 -0000 Adam Roach has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The final paragraph of section 6.6 says "The system MUST alert by some means that the DNS is not private during such bootstrap." -- presumably, this means "client" where it says "system" (as opposed to any other part of the infrastructure) -- but I'm having a hard time envisioning how this gets practically implemented, given that the functionality described by this section is going to be implemented in DNS stub resolver libraries, which tend to be pretty far removed from any user interface. Given that this is a MUST-strength requirement, I think it would be very useful to describe what this alerting might look like for (a) interactive applications like a web browser; (b) commandline utilities like curl; and (c) background tasks like software update daemons. This would provide some context for the library implementors to provide the proper hooks to enable this "MUST" to be satisfied. Section 11.1 mentions that it will describe techniques for thwarting DNS traffic analysis, including "monitoring of resolver-to-authoritative traffic". I see that there have been measures added to prevent authoritative servers from determining the identity of the client; but given the phrasing I cite above, I was expecting a description of how to prevent eavesdroppers who can see both incoming and outgoing traffic from the recursive resolver from correlating the encrypted packets I send to that resolver with the plaintext queries it emits for non-cached results. As far as I can tell, there are no described counter-measures against such an attack (aside from hoping that volume of traffic to the resolver is too great to perform such correlation with any real precision), right? If such measures have been defined, I imagine a citation would be warranted. If not, the above phrasing should probably be qualified; e.g., "monitoring of resolver-to-authoritative traffic alone." Nits: draft-ietf-dprive-dnsodtls has been published as RFC 8094 The draft header indicates that this document updates RFC7858, but the abstract doesn't seem to mention this, which it should. From nobody Tue May 9 19:57:07 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4928912EBDA; Tue, 9 May 2017 19:56:58 -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, 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 azBA0KdTpCkw; Tue, 9 May 2017 19:56:55 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 755A912EBB6; Tue, 9 May 2017 19:56:55 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 64so9177607pgb.3; Tue, 09 May 2017 19:56:55 -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:content-transfer-encoding; bh=gu5FcN+1UycLuse5JYHbLdwQNC7rwztpi2rzMib3Le0=; b=AxNWFqKbgjd7KDC95F0d/JbWgL8k3X9joafIA84QvalscOIM/vQv8hhogZmTVv0p42 zjZm88CtoMEA4uXmDWVN8dl4tsNZciYuQN/Jrz5aj2Z7Wmm+vgPTIaasSjZkV/IZONJH gFtPPzhVTAjAuWinQlPeu2kM5z6fYSihcU4o1Am2wbJSxaaebCGmH5VpDSirpxgwdQlt NoHuaPdx/PFRyypoB4wJivdBa1/ZZCSBeO1+ZyPWaGU3StTNuTYFOd5vuHx+K/W82Vz3 l8f/9alS7hPwZsdjI0zLOrJGt3V5qVrhmKw7whtVfybDTRjFqfT7TumnCVNTJsD6CWlK vMaQ== 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=gu5FcN+1UycLuse5JYHbLdwQNC7rwztpi2rzMib3Le0=; b=mK4pF45B6bDaZOnVgUTWmQGzfFiDpg4Q952ANW4jrSWEtI7IoKR0RfPatEgLaSL3e+ Jyh6kSZwipY6I+dBiG3xzpV7LFvz/g66nHLSr4oXozKw1hPMSMcseS9f58jjyEF1/FFj xWWsPDxttcJ+9QWEYIE5u60tqlYALcJHUwj9Re4oOc/z3SwyTlKuoFp8SDJv+IPM3tXn txnStS/XTdkz7LsHC/WINQ8VX/m9WwuRQIYYULICVeH3K6S4rg6lzncb0H4ockAinOu3 dgn/AYtrq4Grz8URh2IVzWKMJjY1m5i2Q5buv7mYyYWNl4MCTtsItKwStCRjt6Sih1s5 lakQ== X-Gm-Message-State: AODbwcDwJlL3KYIG79NlwmzWz2UvSxWUmClo+LpQLPPAD1/8Y7UW7F6c sS7Io97uEYg48pq+f8Y9iAEmpxRryQ== X-Received: by 10.99.62.67 with SMTP id l64mr3755940pga.172.1494385014961; Tue, 09 May 2017 19:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.161.226 with HTTP; Tue, 9 May 2017 19:56:14 -0700 (PDT) In-Reply-To: References: <149410267259.23107.8936430130975036477.idtracker@ietfa.amsl.com> <79402B6C-B8FB-4115-AB12-9943FF585D21@sinodun.com> From: Kathleen Moriarty Date: Tue, 9 May 2017 22:56:14 -0400 Message-ID: To: Eric Rescorla Cc: Sara Dickinson , Tim Wicinski , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, dns-privacy@ietf.org, The IESG , dprive-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 02:56:58 -0000 Hi, Just a couple of comments inline. On Mon, May 8, 2017 at 8:01 AM, Eric Rescorla wrote: > > > On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson wrote: >> >> >> On 6 May 2017, at 21:31, Eric Rescorla wrote: >> >> Eric Rescorla has entered the following ballot position for >> draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss >> >> >> Many thanks for the review. >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> S 9 mandates RFC 7250: >> o Raw public keys [RFC7250] which reduce the size of the >> ServerHello, and can be used by servers that cannot obtain >> certificates (e.g., DNS servers on private networks). >> >> This needs to be updated to indicate that the client MUST NOT >> offer 7250 unless it has a preconfigured SPKI, otherwise >> you're going to have interop problems. >> >> >> Agreed. >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> TECHNICAL >> S 5. >> subsequently connect. The rationale for this is that requiring >> Strict Privacy for such meta queries would introduce significant >> deployment obstacles. This profile provides strong privacy >> guarantees to the client. This Profile is discussed in detail in >> Section 6.6. >> >> This point seems unclear. If you do these queries unprotected, then >> you don't have strong privacy guarantees. I think you mean that >> you get them via some trusted mechanism such as DHCP. >> >> >> No, we mean they could be done either via Opportunistic lookups or DHCP >> (see table 2.) >> The meta queries contain no information about what DNS lookups the clien= t >> is doing other than what DNS Privacy server they are going to use to do >> their queries. But you are correct that the =E2=80=98strong privacy guar= entees=E2=80=99 >> apply only to the subsequent queries to the Privacy server and the text >> should be updated to clarify that. > > > Well, per my previous comment, I think you need to focus on the entire > strategy. > > I.e., if you determine whether to adopt a Strict policy based on > Opportunistic queries, then you are back to the active attack setting. I > don't have a problem with your design here, which seems to be about as go= od > as one can do; I'm just trying to make sure the description is accurate..= . > > >> Table 1 seems to have N and D paired, so maybe you can coalesce them? >> >> >> That specific question was asked on the WG mailing list and the answer w= as >> =E2=80=98no, please keep both=E2=80=99: >> https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html > > > OK. Perhaps add some text that theya re paired > > > >> S 6.4. >> A DNS client that is configured with both an authentication domain >> name and a SPKI pinset for a DNS server SHOULD match on both a valid >> credential for the authentication domain name and a valid SPKI >> pinset >> (if both are available) when connecting to that DNS server. The >> overall authentication result should only be considered successful >> if >> both authentication mechanisms are successful. >> >> You should cover the topic of user-defined trust anchors. Here's the >> relevant text from 7469: >> >> For example, a UA may disable Pin Validation for Pinned Hosts whose >> validated certificate chain terminates at a user-defined trust >> anchor, rather than a trust anchor built-in to the UA (or underlying >> platform). >> >> >> We purposely avoided adding any details on the SPKI mechanisms in this >> document because this document simply refers to RFC7585 which then direc= tly >> references RFC7469. But if you think this is needed here also then I=E2= =80=99ll add >> it. > > > The concern I have is that this guidance seems to implicitly contradict t= he > guidance from 7469. So I think you should either just say that if you hav= e > both you treat it like a 7469 pin, or say something like "successful, wit= h > the possible exception of certificates which chain to local trust anchors= , > as described in..." Or, alternately really prohibit this. Also, should -> > SHOULD. > >> >> >> >> EDITORIAL >> Do you want to cite TLS 1.3 at this point? >> >> >> Early on we chose not to include a normative reference to the TLS 1.3 >> draft to avoid the dependancy on that becoming an RFC but are you sugges= ting >> we do that now or just include an informative reference? > > > I would think at least an informative reference would be useful. > > >> Do you think Section 9 the right place to talk about TLS 1.3 in general = or >> do you feel there are specific points to made elsewhere in the text? > > > 1.3 has pretty much the same properties here, so I think you might just c= ite > 1.3 and make it informative. I'm not sure what the right actual mechanics > are here, but surely such a thing is possible. > The draft already says TLS 1.2 or higher, so you do already allow for TLS 1.3. You could put an informative reference as TLS 1.3 being an option. TLS 1.2 hasn't been deprecated and the guidance with 7525 is there already to prevent known problems. An informative reference shouldn't hold up this draft, but it's up to the WG if they want to include it explicitly IMO. > >> >> S 3. >> o Any server identifier other than domain names, including IP >> address, organizational name, country of origin, etc. >> >> addresses, names, for parallel structure with domain names >> >> >> Ack. >> >> >> >> S 9. >> There are known attacks on (D)TLS, such as machine-in-the-middle and >> protocol downgrade. These are general attacks on (D)TLS and not >> specific to DNS-over-TLS; please refer to the (D)TLS RFCs for >> discussion of these security issues. >> >> This text seems pretty unhelpful. Given that you are specifying 1.2, >> if you also require the relevant strong algorithms, then there should >> not be downgrade or MITM attacks. >> >> >> How about moving the justification later in the section: >> >> =E2=80=9C Clients and servers MUST adhere to the (D)TLS implementation >> recommendations and security considerations of [RFC7525] except with >> respect to (D)TLS version. >> >> Since encryption of DNS using (D)TLS is a green-field deployment DNS >> clients and servers MUST implement only (D)TLS 1.2 or later. >> >> These requirements ensure mitigation against known attacks on >> (D)TLS, such as machine-in-the-middle and >> protocol downgrade. These are general attacks on (D)TLS and not >> specific to DNS-over-TLS.=E2=80=9D > > > My complaint is that this seems kinda FUDdy. If there are things that you > think people > ought to do other than those in 7525, you ought to say them. I agree with EKR. The recommendation to follow 7525 is enough. > > -Ekr > --=20 Best regards, Kathleen From nobody Tue May 9 20:43:26 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB22412E858; Tue, 9 May 2017 20:43:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149438779589.28796.5612447657226364837.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 20:43:15 -0700 Archived-At: Subject: [dns-privacy] Suresh Krishnan's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 03:43:16 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I do have a concern regarding section 7.3 as it is not clear what really is being requested on the DHCP front here. While using an IP address or an FQDN are generally both possible choices while providing configuration options using DHCP, the use of FQDNs for acquiring trusted DNS servers seems problematic. We have spent a great deal of effort writing up some of the potential issues in Section 8 of RFC7227. It would be good if you can take a look and clarify what is required from a potential new DHCP option and how the failure modes are expected to be handled. From nobody Wed May 10 06:09:43 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C9C129442 for ; Wed, 10 May 2017 06:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=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 YhAqwX7hwmQw for ; Wed, 10 May 2017 06:09:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485F4126DFB for ; Wed, 10 May 2017 06:09:38 -0700 (PDT) Received: from [IPv6:2001:67c:1220:8b4:98:467f:3406:4c0a] (unknown [IPv6:2001:67c:1220:8b4:98:467f:3406:4c0a]) by mail.nic.cz (Postfix) with ESMTPSA id 5A7916040C for ; Wed, 10 May 2017 15:09:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1494421776; bh=ZLyjKzsd4zacQjI0JukKlW7AHBvm1LGjLf9DTbQdYhE=; h=To:From:Date; b=Wvli8yJHHcTLrjYpdWnOwGv1recnlO/YR/BUVXyo2nRfkIXTm+QE9va0F2BuBwElb CTvpvRoNoj7Mzwfs2a3YugzdCasvqQ2dpM9cI5HJlqKdJzxdiM8Ap5teexRt0MwugP pmv/eQeAQeScp3L73svcakr03JOM3GMWGBwUXe9w= To: dns-privacy@ietf.org References: <0b31dc15-3e13-ac36-5c09-056ea8f1b2e8@huitema.net> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <51201cb7-5a67-d906-ee9d-ca5da0cd0083@nic.cz> Date: Wed, 10 May 2017 15:09:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: 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: [dns-privacy] Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 13:09:41 -0000 On 11.4.2017 20:39, Mike Bishop wrote: > Looks great – I’m excited to have another concrete application profile > we can look at. > > > > As a side note, I think 4.4 mischaracterizes any recent draft of > HTTP/QUIC. An HTTP server does explicitly need to listen for > client-initiated streams opening; there’s no announcement of this > happening on Stream 3 as you describe. The main effect of choosing to > have no control stream is that there can be no reliable session-level > application context, since data on any stream can be lost via a stream > reset at the wrong time. > > > > 5.2.2 is an example of this issue – how will the SERVFAIL be reliably > delivered if the stream is reset? You probably need to either define > error codes for DNS/QUIC and replace SERVFAIL with those, or reliably > deliver the SERVFAIL (somehow – by never resetting streams?). Let me express support for Mike's comment above. Current text is confusing when it comes to SERVFAIL. Ad 6.4. DNS Message IDs: I'm in favor of the two blocks of proposed text: When sending multiple queries over a QUIC connection, clients MUST NOT reuse the DNS Message ID of an in-flight query on that connection in order to avoid Message ID collisions. Clients MUST match outstanding queries using the Message ID and if the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Reasoning: There are various DNS proxies which change transport protocol between UDP/TCP/TLS/HTTP on fly, without client knowing. We do not know how this landscape will evolve so it is IMHO better to specify the same behavior for message IDs and query matching regardless of transport to avoid problems with tricks we do not see today. The same applies to 6.3. Response Sizes. For now I propose to keep the same limitations for response sizes regardless of transport. Thank you for writting this down! Petr Špaček @ CZ.NIC > *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Christian Huitema > *Sent:* Monday, April 10, 2017 10:23 AM > *To:* quic@ietf.org; dns-privacy@ietf.org > *Subject:* Fwd: Fwd: New Version Notification for > draft-huitema-quic-dnsoquic-00.txt > > > > > > FYI: Just published this draft describing transport of DNS over a > dedicated QUIC connection. > > -- Christian Huitema > > -------- Forwarded Message -------- > > *Subject: * > > > > New Version Notification for draft-huitema-quic-dnsoquic-00.txt > > *Date: * > > > > Mon, 10 Apr 2017 09:45:37 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Melinda Shore , Sara > Dickinson , Christian > Huitema , Allison > Mankin , > Janardhan Iyengar , Jana Iyengar > > > > > A new version of I-D, draft-huitema-quic-dnsoquic-00.txt > > has been successfully submitted by Christian Huitema and posted to the > > IETF repository. > > > > Name: draft-huitema-quic-dnsoquic > > Revision: 00 > > Title: Specification of DNS over QUIC > > Document date: 2017-04-10 > > Group: Individual Submission > > Pages: 18 > > URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-dnsoquic-00.txt > > > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/ > > > Htmlized: https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00 > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00 > > > > > > > Abstract: > > This document describes the use of QUIC to provide transport privacy > > for DNS. The encryption provided by QUIC has similar properties to > > that provided by TLS, while QUIC transport eliminates the head-of- > > line blocking issues inherent with TCP and provides more efficient > > error corrections than UDP. DNS over QUIC has privacy properties > > similar to DNS over TLS specified in RFC7858, and performance similar > > to classic DNS over UDP. > > > > > > > > > > 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. > > > > The IETF Secretariat From nobody Wed May 10 14:48:05 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9997C1292CE; Wed, 10 May 2017 14:48:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149445288162.16739.870078352991642154.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 14:48:01 -0700 Archived-At: Subject: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:48:03 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes", but I do have some comments: Substantive: 5: "Clients using Opportunistic Privacy SHOULD try for the best case..." When might it be reasonable _not_ to try for the best case? (That is, why not MUST)? 5.1: What's a reasonable granularity for the profile selection? The text suggests that decision is on a per-query basis; is that the intent? I assume you don't expect a user to make a decision for each query. 6.5: The statement that a client using OP "MAY" try to authenticate seems inconsistent with the "SHOULD try for the best case" statement in S5. (But seem my comment above about that.) 13.2: [I-D.ietf-dprive-dnsodtls] is referenced using 2119 keywords, so it should be a normative reference. (Note that this would be a downref.) Editorial: 2: "MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- over-DTLS [I-D.ietf-dprive-dnsodtls]." Unless these are new-to-this-draft requirements, please use descriptive (non-2119) language. (Especially in a definition). 5: "Strict Privacy provides the strongest privacy guarantees and therefore SHOULD always be implemented in DNS clients along with Opportunistic Privacy." Does that mean "SHOULD implement both strict and opportunistic privacy" or "If you implement opportunistic you SHOULD also implement strict?" 6.2: Should list item "2" be "ADN+IP", like in the table? 11: Is "SHOULD consider implementing" different than "SHOULD implement"? If so, please consider dropping the 2119 "SHOULD" when talking about what people think about. From nobody Wed May 10 17:57:14 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C654712EAB9; Wed, 10 May 2017 17:57:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149446423280.16644.2667276472402300447.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 17:57:12 -0700 Archived-At: Subject: [dns-privacy] Alissa Cooper's Yes on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 00:57:13 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider the editorial comments in the Gen-ART review: https://datatracker.ietf.org/doc/review-ietf-dprive-dtls-and-tls-profiles-09-genart-telechat-dupont-2017-05-10/ From nobody Thu May 11 04:58:05 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF32B12EBC0; Thu, 11 May 2017 04:58:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149450388297.16608.9587311127145698792.idtracker@ietfa.amsl.com> Date: Thu, 11 May 2017 04:58:02 -0700 Archived-At: Subject: [dns-privacy] Benoit Claise's No Objection on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 11:58:03 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here is Eric Vyncke's OPS DIR review: >From the abstract: This document discusses Usage Profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). This document also specifies new authentication mechanisms. DPRIVE (DNS Private exchange) aims at enhancing DNS privacy by encrypting the DNS traffic (DNSsec only provides authentication/integrity). There are two profiles: strict and opportunistic. The latter allows normal DNS operations as a fallback, which is key for successful deployment. This document in section 6 compares the SIX different authentication mechanisms and gives some guidelines with a lot of SHOULD and MAY and little MUST. Unsure whether it makes the implementers' task easy. Section 8 is more directive and more useful. Section 7.3 is mainly about the legacy DHCP server for the legacy IPv4. No word about IPv6 and no word about RFC 8106 (DNS info for SLAAC). Overall, there are no discussion about the performance (latency, load of clients/servers) of one authentication mechanism compared to the others, no discussion about resilience (i.e. if one server fails, for example in the PKIX cert chains) and I believe that performance and resilience to network error could be useful for the implementer/architect. As a reader, I regret that this document combines two aspects: description of the profiles but also how to extend one TLS authentication method to DTLS... I would have preferred having two documents. But, this is mainly about readability. From nobody Thu May 11 05:01:20 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADCB12EBCD; Thu, 11 May 2017 05:01:18 -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 pSZm90xadB_h; Thu, 11 May 2017 05:01:15 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79577129AD5; Thu, 11 May 2017 04:59:05 -0700 (PDT) Received: from [2a02:8010:6126:0:bc7d:946c:833c:205e] (port=56957) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1d8mkH-000286-IN; Thu, 11 May 2017 12:59:03 +0100 From: Sara Dickinson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6BF5E805-3FD7-4E2E-83EC-627FDA53D94D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 12:58:55 +0100 In-Reply-To: Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org To: Eric Rescorla References: <149410267259.23107.8936430130975036477.idtracker@ietfa.amsl.com> <79402B6C-B8FB-4115-AB12-9943FF585D21@sinodun.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:01:19 -0000 --Apple-Mail=_6BF5E805-3FD7-4E2E-83EC-627FDA53D94D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ekr (and Kathleen), > On 8 May 2017, at 13:01, Eric Rescorla wrote: >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> TECHNICAL >> S 5. >> subsequently connect. The rationale for this is that requiring >> Strict Privacy for such meta queries would introduce significant >> deployment obstacles. This profile provides strong privacy >> guarantees to the client. This Profile is discussed in detail = in >> Section 6.6. >>=20 >> This point seems unclear. If you do these queries unprotected, then >> you don't have strong privacy guarantees. I think you mean that >> you get them via some trusted mechanism such as DHCP. >=20 > No, we mean they could be done either via Opportunistic lookups or = DHCP (see table 2.) > The meta queries contain no information about what DNS lookups the = client is doing other than what DNS Privacy server they are going to use = to do their queries. But you are correct that the =E2=80=98strong = privacy guarentees=E2=80=99 apply only to the subsequent queries to the = Privacy server and the text should be updated to clarify that. =20 >=20 > Well, per my previous comment, I think you need to focus on the entire = strategy. >=20 > I.e., if you determine whether to adopt a Strict policy based on = Opportunistic queries, then you are back to the active attack setting. I = don't have a problem with your design here, which seems to be about as = good as one can do; I'm just trying to make sure the description is = accurate... Oh, I think I see your point now: - Strict without meta queries to an untrusted source (i.e. name and IP = both configured or obtained from a =E2=80=99trusted=E2=80=99 source) = will connect directly to the correct the Privacy server - Strict with meta queries to an untrusted source provides the = opportunity for the attacker to return incorrect answers, directing the = client to a bogus Privacy server which the client will not be able to = authenticate and therefore the client will not proceed to perform = queries.=20 so the two approaches are different in terms of mitigating attacks.=20 Even if the meta queries were secured with DNSSEC (as they were until a = recent version of the draft) this doesn=E2=80=99t help because if the = answers are bogus then again, the client won=E2=80=99t continue.=20 >=20 >> S 6.4. >> A DNS client that is configured with both an authentication domain >> name and a SPKI pinset for a DNS server SHOULD match on both a = valid >> credential for the authentication domain name and a valid SPKI >> pinset >> (if both are available) when connecting to that DNS server. The >> overall authentication result should only be considered successful >> if >> both authentication mechanisms are successful. >>=20 >> You should cover the topic of user-defined trust anchors. Here's the >> relevant text from 7469: >>=20 >> For example, a UA may disable Pin Validation for Pinned Hosts whose >> validated certificate chain terminates at a user-defined trust >> anchor, rather than a trust anchor built-in to the UA (or = underlying >> platform). >=20 > We purposely avoided adding any details on the SPKI mechanisms in this = document because this document simply refers to RFC7585 which then = directly references RFC7469. But if you think this is needed here also = then I=E2=80=99ll add it. >=20 > The concern I have is that this guidance seems to implicitly = contradict the guidance from 7469. So I think you should either just say = that if you have both you treat it like a 7469 pin, or say something = like "successful, with the possible exception of certificates which = chain to local trust anchors, as described in..." Or, alternately really = prohibit this. Also, should -> SHOULD. Got it. I think I would lean towards "if you have both you treat it like = a 7469 pin=E2=80=9D but would like to hear other views on this.=20 >>=20 >> EDITORIAL >> Do you want to cite TLS 1.3 at this point? >=20 > Early on we chose not to include a normative reference to the TLS 1.3 = draft to avoid the dependancy on that becoming an RFC but are you = suggesting we do that now or just include an informative reference? >=20 > I would think at least an informative reference would be useful. >=20 >=20 > Do you think Section 9 the right place to talk about TLS 1.3 in = general or do you feel there are specific points to made elsewhere in = the text?=20 >=20 > 1.3 has pretty much the same properties here, so I think you might = just cite 1.3 and make it informative. I'm not sure what the right = actual mechanics are here, but surely such a thing is possible. An informative reference makes total sense - I=E2=80=99ll add that.=20 >=20 > These requirements ensure mitigation against known attacks on=20 > (D)TLS, such as machine-in-the-middle and > protocol downgrade. These are general attacks on (D)TLS and not > specific to DNS-over-TLS.=E2=80=9D >=20 > My complaint is that this seems kinda FUDdy. OK - I=E2=80=99ll remove.=20 Sara.=20 --Apple-Mail=_6BF5E805-3FD7-4E2E-83EC-627FDA53D94D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Ekr (and Kathleen),

On = 8 May 2017, at 13:01, Eric Rescorla <ekr@rtfm.com> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

TECHNICAL
S 5.
=      subsequently connect.  The rationale = for this is that requiring
=      Strict Privacy for such meta queries would = introduce significant
=      deployment obstacles.  This profile = provides strong privacy
=      guarantees to the client.  This = Profile is discussed in detail in
=      Section 6.6.

This point seems unclear. If you do these queries = unprotected, then
you don't have strong privacy = guarantees. I think you mean that
you get them via some = trusted mechanism such as DHCP.

No, we mean they could be done = either via Opportunistic lookups or DHCP (see table 2.)
The meta queries contain no information about what DNS = lookups the client is doing other than what DNS Privacy server they are = going to use to do their queries. But you are correct that the =E2=80=98st= rong privacy guarentees=E2=80=99 apply only to the subsequent queries to = the Privacy server and the text should be updated to clarify that. =  

Well, per my previous comment, I think = you need to focus on the entire strategy.

I.e., if you determine whether to adopt = a Strict policy based on Opportunistic queries, then you are back to the = active attack setting. I don't have a problem with your design here, = which seems to be about as good as one can do; I'm just trying to make = sure the description is = accurate...

Oh, I think I see your point now:

- Strict without meta queries to an untrusted = source (i.e. name and IP both configured or obtained from a = =E2=80=99trusted=E2=80=99 source) will connect directly to the correct = the Privacy server
- Strict with meta queries to an untrusted = source provides the opportunity for the attacker to return incorrect = answers, directing the client to a bogus Privacy server which the client = will not be able to authenticate and therefore the client will not = proceed to perform queries. 

so = the two approaches are different in terms of mitigating = attacks. 

Even if the meta = queries were secured with DNSSEC (as they were until a recent version of = the draft) this doesn=E2=80=99t help because if the answers are bogus = then again, the client won=E2=80=99t continue. 


S 6.4.
=   A DNS client that is configured with both an authentication = domain
  name and a SPKI pinset for a DNS = server SHOULD match on both a valid
=   credential for the authentication domain name and a valid = SPKI
pinset
  (if both are = available) when connecting to that DNS server.  The
=   overall authentication result should only be considered = successful
if
  both = authentication mechanisms are successful.

You= should cover the topic of user-defined trust anchors. Here's the
relevant text from 7469:

=   For example, a UA may disable Pin Validation for Pinned = Hosts whose
  validated certificate chain = terminates at a user-defined trust
  anchor, = rather than a trust anchor built-in to the UA (or underlying
  platform).

We purposely avoided adding any = details on the SPKI mechanisms in this document because this document = simply refers to RFC7585 which then directly references RFC7469. But if = you think this is needed here also then I=E2=80=99ll add = it.

The concern I have is that this = guidance seems to implicitly contradict the guidance from 7469. So I = think you should either just say that if you have both you treat it like = a 7469 pin, or say something like "successful, with the possible = exception of certificates which chain to local trust anchors, as = described in..." Or, alternately really prohibit this. Also, should = -> SHOULD.

Got it. I think I would lean towards "if you have = both you treat it like a 7469 pin=E2=80=9D but would like to hear other = views on this. 


EDITORIAL
Do you want to cite = TLS 1.3 at this point?

Early on we chose not to include = a normative reference to the TLS 1.3 draft to avoid the dependancy on = that becoming an RFC but are you suggesting we do that now or just = include an informative reference?

I would think at least an informative = reference would be useful.


Do you think Section 9 the = right place to talk about TLS 1.3 in general or do you feel there are = specific points to made elsewhere in the = text? 

1.3 has pretty much the same properties = here, so I think you might just cite 1.3 and make it informative. I'm = not sure what the right actual mechanics are here, but surely such a = thing is possible.

An informative reference makes total sense - = I=E2=80=99ll add that. 


  These = requirements ensure mitigation against known attacks on 
  (D)TLS, such as machine-in-the-middle = and
  protocol downgrade.  These are = general attacks on (D)TLS and not
  specific to = DNS-over-TLS.=E2=80=9D

My complaint is that this seems kinda = FUDdy.

OK - I=E2=80=99ll = remove. 

Sara. 

= --Apple-Mail=_6BF5E805-3FD7-4E2E-83EC-627FDA53D94D-- From nobody Thu May 11 05:06:50 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8FA12EC25; Thu, 11 May 2017 05:06:42 -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 PLiEHmrFsDK0; Thu, 11 May 2017 05:06:40 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4869812EC49; Thu, 11 May 2017 05:04:13 -0700 (PDT) Received: from [2a02:8010:6126:0:bc7d:946c:833c:205e] (port=57039) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1d8mpG-0002kW-Hb; Thu, 11 May 2017 13:04:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sara Dickinson In-Reply-To: <149436978593.19294.10256470803161992800.idtracker@ietfa.amsl.com> Date: Thu, 11 May 2017 13:04:08 +0100 Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <181B9399-EB5C-43CC-B21C-4A6CE77391DF@sinodun.com> References: <149436978593.19294.10256470803161992800.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [dns-privacy] Alexey Melnikov's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:06:42 -0000 > On 9 May 2017, at 23:43, Alexey Melnikov = wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > (I just updated both my DISCUSS and my comment section.) >=20 > I would like to ballot YES on this document, but I would like to = discuss > the following: >=20 > Sorry for being DownRef police, but RFC 7918 is clearly Normative > (because there is a SHOULD level requirement), but it is listed as > Informative reference. I think that is a hangover from when it was referenced as a I-D > It would be a DownRef once it is made Normative, > unless the procedure from RFC 8067 is used. Is RFC 7918 a suitable > DownRef? Is it widely implemented? I just checked the early versions of the document and they actually = included a note at the end of section 12 which has since been removed: =E2=80=9C [NOTE: The references to (works in progress) should be = upgraded to MUST's if those references become RFC's prior to publication of this document.] At the time both RFC7918 and RFC7924 were still I-Ds. With that in mind: - Since RFC7918 is only Informational would it make more sense to use = MAY and leave it as an informative reference.=20 - But change the recommendation regarding RFC7924 to be a MUST and make = that Normative (it is currently only informative). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I am agreeing with Ekr comments. OK, noted.=20 > I am also agreeing on first and last > Mirja's comment. I haven=E2=80=99t seen a review from Mirja - was there one I missed? > Section on future DHCP extension is a bit "hand-wavy". Is any work on > this planned? There was some debate about including this at all given that to my = knowledge there is no current work on this, but IIRC in the end it was = felt that something should be said on it (however hand-wavy). I see = Suresh raised this point too so I will look at the document he = referenced and respond separately on that.=20 Regards Sara.=20= From nobody Thu May 11 05:12:46 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1125012EC5B; Thu, 11 May 2017 05:12:44 -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 Kf88lvw0spQT; Thu, 11 May 2017 05:12:41 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B368A12EC69; Thu, 11 May 2017 05:10:11 -0700 (PDT) Received: from [2a02:8010:6126:0:bc7d:946c:833c:205e] (port=57071) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1d8mv1-0003f0-Ob; Thu, 11 May 2017 13:10:08 +0100 From: Sara Dickinson Message-Id: <6C08BAA0-7801-4388-885D-9A3E6A6751D8@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_722CAE1B-A13D-4F49-BA9B-B7D425A635B6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 13:10:04 +0100 In-Reply-To: <149437248346.22508.847522278141179102.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org To: Adam Roach References: <149437248346.22508.847522278141179102.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:12:44 -0000 --Apple-Mail=_722CAE1B-A13D-4F49-BA9B-B7D425A635B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 May 2017, at 00:28, Adam Roach wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The final paragraph of section 6.6 says "The system MUST alert by some > means that the DNS is not private during such bootstrap." -- = presumably, > this means "client" where it says "system" (as opposed to any other = part > of the infrastructure) -- but I'm having a hard time envisioning how = this > gets practically implemented, given that the functionality described = by > this section is going to be implemented in DNS stub resolver = libraries, > which tend to be pretty far removed from any user interface. Given = that > this is a MUST-strength requirement, I think it would be very useful = to > describe what this alerting might look like for (a) interactive > applications like a web browser; (b) commandline utilities like curl; = and > (c) background tasks like software update daemons. This would provide > some context for the library implementors to provide the proper hooks = to > enable this "MUST" to be satisfied. This paragraph was actually lifted almost directly from section 4.2 of = RFC7858, which says "The user MUST be alerted whenever possible that the DNS is not private = during such bootstrap.=E2=80=9D=20 In the working group there was push back against attempting to specify = any further level of detail with the feeling that that was out of scope = for this draft to attempt UI design. However if there are now specific = ideas on how to do this then we should consider including them.=20 >=20 > Section 11.1 mentions that it will describe techniques for thwarting = DNS > traffic analysis, including "monitoring of resolver-to-authoritative > traffic". I see that there have been measures added to prevent > authoritative servers from determining the identity of the client; but > given the phrasing I cite above, I was expecting a description of how = to > prevent eavesdroppers who can see both incoming and outgoing traffic = from > the recursive resolver from correlating the encrypted packets I send = to > that resolver with the plaintext queries it emits for non-cached = results. > As far as I can tell, there are no described counter-measures against > such an attack (aside from hoping that volume of traffic to the = resolver > is too great to perform such correlation with any real precision), = right? The EDNS0 Padding option (RFC7830) described in the first bullet point = here is the only counter measure available to defeat monitoring traffic = either side of the recursive by hiding the encrypted message size.=20 Actually there has been further work on padding recently in = https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ = and = also research by dkg = (https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/ = ) = which is planned to be incorporated into the padding policy draft.=20 So it certainly seems correct to add a reference to the padding policy = draft here.=20 >=20 > Nits: > draft-ietf-dprive-dnsodtls has been published as RFC 8094 Yup - will update.=20 > The draft header indicates that this document updates RFC7858, but the > abstract doesn't seem to mention this, which it should. It should - I will add that.=20 Sara.=20 --Apple-Mail=_722CAE1B-A13D-4F49-BA9B-B7D425A635B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 May 2017, at 00:28, Adam Roach <adam@nostrum.com> = wrote:
---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

The final paragraph of section 6.6 = says "The system MUST alert by some
means that the DNS is = not private during such bootstrap." -- presumably,
this = means "client" where it says "system" (as opposed to any other part
of the infrastructure) -- but I'm having a hard time = envisioning how this
gets practically implemented, given = that the functionality described by
this section is going = to be implemented in DNS stub resolver libraries,
which = tend to be pretty far removed from any user interface. Given that
this is a MUST-strength requirement, I think it would be very = useful to
describe what this alerting might look like for = (a) interactive
applications like a web browser; (b) = commandline utilities like curl; and
(c) background tasks = like software update daemons. This would provide
some = context for the library implementors to provide the proper hooks to
enable this "MUST" to be satisfied.

This = paragraph was actually lifted almost directly from section 4.2 of = RFC7858, which says
"The user MUST be alerted whenever = possible that the DNS is not private during such = bootstrap.=E2=80=9D 

In the = working group there was push back against attempting to specify any = further level of detail with the feeling that that was out of scope for = this draft to attempt UI design. However if there are now specific ideas = on how to do this then we should consider including them. 


Section 11.1 mentions that it will describe = techniques for thwarting DNS
traffic analysis, including = "monitoring of resolver-to-authoritative
traffic". I see = that there have been measures added to prevent
authoritative= servers from determining the identity of the client; but
given the phrasing I cite above, I was expecting a = description of how to
prevent eavesdroppers who can see = both incoming and outgoing traffic from
the recursive = resolver from correlating the encrypted packets I send to
that resolver with the plaintext queries it emits for = non-cached results.
As far as I can tell, there are no = described counter-measures against
such an attack (aside = from hoping that volume of traffic to the resolver
is too = great to perform such correlation with any real precision), right?

The = EDNS0 Padding option (RFC7830) described in the first bullet point here = is the only counter measure available to defeat monitoring traffic = either side of the recursive by hiding the encrypted message = size. 

Actually there has been = further work on padding recently in https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-poli= cy/ and also research by dkg (https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-poli= cy/) which is planned to be incorporated into the padding policy = draft. 

So it certainly seems = correct to add a reference to the padding policy draft = here. 


Nits:
draft-ietf-dprive-dnsodtls has been published as RFC 8094

Yup - will = update. 

The draft header indicates = that this document updates RFC7858, but the
abstract = doesn't seem to mention this, which it should.

It should = - I will add that. 

Sara. 

= --Apple-Mail=_722CAE1B-A13D-4F49-BA9B-B7D425A635B6-- From nobody Thu May 11 05:15:33 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DC112EB8C; Thu, 11 May 2017 05:15:25 -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 ik_2zvYdFYL4; Thu, 11 May 2017 05:15:23 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC4512EBB3; Thu, 11 May 2017 05:12:44 -0700 (PDT) Received: from [2a02:8010:6126:0:bc7d:946c:833c:205e] (port=57075) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1d8mxV-0004Gq-Qh; Thu, 11 May 2017 13:12:42 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sara Dickinson In-Reply-To: <149445288162.16739.870078352991642154.idtracker@ietfa.amsl.com> Date: Thu, 11 May 2017 13:12:37 +0100 Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1EFFE62A-A7A1-4A7E-B19C-88A400F0618D@sinodun.com> References: <149445288162.16739.870078352991642154.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:15:26 -0000 > On 10 May 2017, at 22:48, Ben Campbell wrote: >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm balloting "yes", but I do have some comments: >=20 > Substantive: >=20 > 5: "Clients using Opportunistic Privacy SHOULD try for the best > case..." > When might it be reasonable _not_ to try for the best case? (That is, = why > not MUST)?=20 If latency is a greater concern than privacy. For example if a client = has 5 Privacy servers configured a MUST would require it to attempt to = obtain an authenticated, encrypted connection to all 5 before falling = back to using an unauthenticated, encrypted connection to the first one. = There is some text on this in Appendix A. >=20 > 5.1: What's a reasonable granularity for the profile selection? The = text > suggests that decision is on a per-query basis; is that the intent? I > assume you don't expect a user to make a decision for each query. No, it is expected that the client sets the desired Profile and uses it = for all queries until that setting is changed. The intent of this text = was to clarify that the granularity should not be less than query level. = Maybe it would help to add some text =E2=80=9CIt is anticipated that = clients will use a particular Usage Profile for all queries until an = operational issue or policy update dictates a change in the profile = used=E2=80=9D? >=20 > 6.5: The statement that a client using OP "MAY" try to authenticate = seems > inconsistent with the "SHOULD try for the best case" statement in S5. > (But seem my comment above about that.) You=E2=80=99re right it does seem inconsistent. It seems better to = switch the MAY here to SHOULD? >=20 > 13.2: [I-D.ietf-dprive-dnsodtls] is referenced using 2119 keywords, so = it > should be a normative reference. (Note that this would be a downref.) It was caught in another review that this document is now an RFC. >=20 > Editorial: >=20 > 2: "MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- > over-DTLS [I-D.ietf-dprive-dnsodtls]." > Unless these are new-to-this-draft requirements, please use = descriptive > (non-2119) language. (Especially in a definition). The definition of a Privacy-enabling DNS Server is new to this draft = which is why it seemed correct to use those terms. Do you think it would = be better to move that description/definition to the introduction? >=20 > 5: "Strict Privacy provides the strongest privacy guarantees and > therefore SHOULD always be implemented in DNS clients along with > Opportunistic Privacy." >=20 > Does that mean "SHOULD implement both strict and opportunistic = privacy" > or "If you implement opportunistic you SHOULD also implement = strict?=E2=80=9D Good question. The second one. Replace with: =E2=80=9C Strict Privacy provides the strongest privacy guarantees and therefore SHOULD always be implemented in DNS clients that implement Opportunistic Privacy." >=20 > 6.2: Should list item "2" be "ADN+IP", like in the table? The 'Short name=E2=80=99 in used in the listing, the one given in the = last column of the table.=20 >=20 > 11: Is "SHOULD consider implementing" different than "SHOULD = implement=E2=80=9D? No, I don=E2=80=99t think so :-) Propose it is changed to =E2=80=9CSHOULD = implement=E2=80=9D. Regards Sara.=20 From nobody Thu May 11 05:25:53 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448BD129422; Thu, 11 May 2017 05:25:46 -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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=fastmail.fm header.b=TMUnbdeF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QgTtMDy+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFn3262-mEcb; Thu, 11 May 2017 05:25:45 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FE1128C84; Thu, 11 May 2017 05:23:09 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E5CDE20506; Thu, 11 May 2017 08:23:08 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 11 May 2017 08:23:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; 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=fm1; bh=jExv9wpB59cxPaPW3rI4E4G+DY6xw CtJqnhuGtpTcTY=; b=TMUnbdeFHJSu+9SOu+k16IL6rBKNTuP7I1EjAzb9BsTVW Sc6069A6ZnZwonTD73ooTlcfj/6pG3QKWNx9ol/lKWH/bNMII5cREVVH2niNFnc1 zEemH3U9r5SX7IELVLVTdQtuMzy1DAC5M/DIwmh6lHS6wWfyDfPs64jaO5eu1vam CkZU/HL0CJPrn/5Hux91dh6XfuV7g13KpKrgIbwCT9eZeMIqVobjyozN6Q108kNU UltW581GYitx5hCcy2snjWlKeCsNBriUa1dkC+GeDQ6FZ7qn8Ix84WwRjpzioug9 O++y6YG/cQwgOU/H/uy/X7Gc+q9LgZ+0TjUQ2JIkA== 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=fm1; bh=jExv9w pB59cxPaPW3rI4E4G+DY6xwCtJqnhuGtpTcTY=; b=QgTtMDy+c5jg+UriFYCUWV NMD9iZzna2XjwUcvLe9TkECWYZAwpAQPjf9pQj+8fdI6EXeqCOPzGSrCOwWfnGch R1P13jI11AnJkdQkaqXZkIdCqah6YCqMZehnw77rpviThTgqGxdLi/s976JAliSa KmkrVhjeIv3xHkkTNsEhXnYRCPcP0jOxG9cOIS6mbp8PwE71DMy9IsivyS/d2Bf4 Wbyn1skdYhTPBXiURyhmwSh3HaOEn9qt/rB2tGLEcK4mUu/XNuCUGNDNU+0dHSIO SibWBB67iY7TOqeiFAmzLbLqEXRB72EqRe49t0Uc96Y8ED+NoHKOICvHvwqrStGA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C36339E25D; Thu, 11 May 2017 08:23:08 -0400 (EDT) Message-Id: <1494505388.20117.973209360.3E6B4BB1@webmail.messagingengine.com> From: Alexey Melnikov To: Sara Dickinson Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1 Date: Thu, 11 May 2017 13:23:08 +0100 References: <149436978593.19294.10256470803161992800.idtracker@ietfa.amsl.com> <181B9399-EB5C-43CC-B21C-4A6CE77391DF@sinodun.com> In-Reply-To: <181B9399-EB5C-43CC-B21C-4A6CE77391DF@sinodun.com> Archived-At: Subject: Re: [dns-privacy] Alexey Melnikov's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 12:25:47 -0000 Hi Sara, On Thu, May 11, 2017, at 01:04 PM, Sara Dickinson wrote: >=20 > > On 9 May 2017, at 23:43, Alexey Melnikov wrote: >=20 > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > >=20 > > (I just updated both my DISCUSS and my comment section.) > >=20 > > I would like to ballot YES on this document, but I would like to discuss > > the following: > >=20 > > Sorry for being DownRef police, but RFC 7918 is clearly Normative > > (because there is a SHOULD level requirement), but it is listed as > > Informative reference. >=20 > I think that is a hangover from when it was referenced as a I-D >=20 > > It would be a DownRef once it is made Normative, > > unless the procedure from RFC 8067 is used. Is RFC 7918 a suitable > > DownRef? Is it widely implemented? >=20 > I just checked the early versions of the document and they actually > included a note at the end of section 12 which has since been removed: >=20 > =E2=80=9C [NOTE: The references to (works in progress) should be upgraded= to > MUST's if those references become RFC's prior to publication of this > document.] >=20 > At the time both RFC7918 and RFC7924 were still I-Ds. With that in mind: Ok. This makes some sense. > - Since RFC7918 is only Informational would it make more sense to use MAY > and leave it as an informative reference.=20 No. Firstly, a MAY level requirement is still Normative, as it is required to implement. Secondly, whether a reference is normative or not has nothing to do with whether the document being referenced is Informational or any other kind. > - But change the recommendation regarding RFC7924 to be a MUST and make > that Normative (it is currently only informative). I missed that. Please also make it Normative. (I have no opinion on whether it should stay as SHOULD or become a MUST.) Thank you, Alexey From nobody Thu May 11 07:12:02 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0D7131490; Thu, 11 May 2017 07:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 kaVCnnwLESqp; Thu, 11 May 2017 07:11:35 -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 0DA7512EC7F; Thu, 11 May 2017 07:05:36 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4BE5WP1028011 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 May 2017 09:05:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <1EFFE62A-A7A1-4A7E-B19C-88A400F0618D@sinodun.com> Date: Thu, 11 May 2017 09:05:34 -0500 Cc: The IESG , draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, dns-privacy@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <51A0FD46-9EE8-480E-9848-2EE09E3D5C2E@nostrum.com> References: <149445288162.16739.870078352991642154.idtracker@ietfa.amsl.com> <1EFFE62A-A7A1-4A7E-B19C-88A400F0618D@sinodun.com> To: Sara Dickinson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:11:43 -0000 > On May 11, 2017, at 7:12 AM, Sara Dickinson wrote: >=20 >=20 >> On 10 May 2017, at 22:48, Ben Campbell wrote: >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I'm balloting "yes", but I do have some comments: >>=20 >> Substantive: >>=20 >> 5: "Clients using Opportunistic Privacy SHOULD try for the best >> case..." >> When might it be reasonable _not_ to try for the best case? (That is, = why >> not MUST)?=20 >=20 > If latency is a greater concern than privacy. For example if a client = has 5 Privacy servers configured a MUST would require it to attempt to = obtain an authenticated, encrypted connection to all 5 before falling = back to using an unauthenticated, encrypted connection to the first one. = There is some text on this in Appendix A. Thanks, that helps. A few words about that near the SHOULD would be = helpful. >=20 >>=20 >> 5.1: What's a reasonable granularity for the profile selection? The = text >> suggests that decision is on a per-query basis; is that the intent? I >> assume you don't expect a user to make a decision for each query. >=20 > No, it is expected that the client sets the desired Profile and uses = it for all queries until that setting is changed. The intent of this = text was to clarify that the granularity should not be less than query = level. Maybe it would help to add some text =E2=80=9CIt is anticipated = that clients will use a particular Usage Profile for all queries until = an operational issue or policy update dictates a change in the profile = used=E2=80=9D? I think that would help. >=20 >>=20 >> 6.5: The statement that a client using OP "MAY" try to authenticate = seems >> inconsistent with the "SHOULD try for the best case" statement in S5. >> (But seem my comment above about that.) >=20 > You=E2=80=99re right it does seem inconsistent. It seems better to = switch the MAY here to SHOULD? That seems reasonable to me. >=20 >>=20 >> 13.2: [I-D.ietf-dprive-dnsodtls] is referenced using 2119 keywords, = so it >> should be a normative reference. (Note that this would be a downref.) >=20 > It was caught in another review that this document is now an RFC. I=E2=80=99m not sure that changes my comment. It still needs to be a = normative reference, and I assume the RFC is still experimental? >=20 >>=20 >> Editorial: >>=20 >> 2: "MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- >> over-DTLS [I-D.ietf-dprive-dnsodtls]." >> Unless these are new-to-this-draft requirements, please use = descriptive >> (non-2119) language. (Especially in a definition). >=20 > The definition of a Privacy-enabling DNS Server is new to this draft = which is why it seemed correct to use those terms. Do you think it would = be better to move that description/definition to the introduction? I would suggest leaving it where it is, but making a change along the = following lines =E2=80=9CA DNS server that implements DNS-over-TLS and = may optionally implement DNS-over-DTLS.=E2=80=9D, and state the = normative bits elsewhere.=20 >=20 >>=20 >> 5: "Strict Privacy provides the strongest privacy guarantees and >> therefore SHOULD always be implemented in DNS clients along with >> Opportunistic Privacy." >>=20 >> Does that mean "SHOULD implement both strict and opportunistic = privacy" >> or "If you implement opportunistic you SHOULD also implement = strict?=E2=80=9D >=20 > Good question. The second one. Replace with: >=20 > =E2=80=9C Strict Privacy provides the strongest privacy guarantees and > therefore SHOULD always be implemented in DNS clients that implement > Opportunistic Privacy.=E2=80=9D Looks good to me. >=20 >>=20 >> 6.2: Should list item "2" be "ADN+IP", like in the table? >=20 > The 'Short name=E2=80=99 in used in the listing, the one given in the = last column of the table.=20 >=20 Okay. >>=20 >> 11: Is "SHOULD consider implementing" different than "SHOULD = implement=E2=80=9D? >=20 > No, I don=E2=80=99t think so :-) Propose it is changed to =E2=80=9CSHOUL= D implement=E2=80=9D. Looks good to me. Thanks! Ben.= From nobody Thu May 11 07:34:28 2017 Return-Path: X-Original-To: dns-privacy@ietf.org Delivered-To: dns-privacy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED31C13145F; Thu, 11 May 2017 07:34:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski , dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149451326696.16620.10081016271318475701.idtracker@ietfa.amsl.com> Date: Thu, 11 May 2017 07:34:26 -0700 Archived-At: Subject: [dns-privacy] Alexey Melnikov's Yes on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT) X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:34:27 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dprive-dtls-and-tls-profiles-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please make RFC 7918 and RFC 7924 Normative references, as they are mentioned in SHOULD level requirements. I am agreeing with Ekr comments. I am also agreeing on first and last Mirja's comment. Section on future DHCP extension is a bit "hand-wavy". Is any work on this planned? I see that Suresh raised a DISCUSS on this point, so I am happy for him to hold it. From nobody Thu May 18 05:17:46 2017 Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED57B12E85B for ; Thu, 18 May 2017 05:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.343 X-Spam-Level: ** X-Spam-Status: No, score=2.343 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543] 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 c5cx_kXrySCb for ; Thu, 18 May 2017 05:17:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id CA9A812EA7C for ; Thu, 18 May 2017 05:12:52 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.127.159.5]) by che.mayfirst.org (Postfix) with ESMTPSA id E5504F999; Thu, 18 May 2017 08:12:52 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2E09720A10; Wed, 17 May 2017 22:57:17 -0400 (EDT) From: Daniel Kahn Gillmor To: DNS Privacy Working Group , HTTP Working Group In-Reply-To: <20170504101604.GA31988@LK-Perkele-V2.elisa-laajakaista.fi> References: <87tw51remp.fsf@fifthhorseman.net> <87inlhqz4n.fsf@fifthhorseman.net> <20170504101604.GA31988@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 17 May 2017 22:57:17 -0400 Message-ID: <877f1ec1o2.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener X-BeenThere: dns-privacy@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 12:17:45 -0000 Thanks to everyone for their useful feedback and commentary. I've just uploaded draft-dkg-dprive-demux-dns-http-03, which attempts to include the insights that people have shared here. Most significantly, it drastically tightens the scope of the draft by focusing on HTTP/1.x only and explicitly excluding HTTP/2 and all future versions of HTTP. As such, it can be seen as a stopgap measure until one of the DNS-over-HTTP/2 drafts reaches consensus (and running code). I'm interested in seeing that happen, and will work on it, but i've got to come up to speed on h2 and its implementations myself. And in the meantime, i think can be useful to document what is working today. I welcome further feedback on the draft! --dkg