Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Tommy Pauly <tpauly@apple.com> Fri, 09 October 2020 22:33 UTC

Return-Path: <tpauly@apple.com>
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 782223A0EC0 for <dns-privacy@ietfa.amsl.com>; Fri, 9 Oct 2020 15:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level:
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 5DUwnN1p7i0w for <dns-privacy@ietfa.amsl.com>; Fri, 9 Oct 2020 15:33:03 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 23B6A3A0EC3 for <dns-privacy@ietf.org>; Fri, 9 Oct 2020 15:33:03 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 099MSEL6042798; Fri, 9 Oct 2020 15:32:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=ddjO3/XnogpHcQMRJtJWQl12FsQFV5r6kVvEmiqFp3U=; b=DTIqtEU74ouhQOhzKL54Xwj4//XCq45MyJKKaD5fd+dgUGkiLqhOOCTTqVF6GY+tcZpe 6i2E9b6Tb27hBbO4IHHuraRKIT+Rl0p48jkTzLQqjYmNltIVtcwS9BahDdVrdYoi4aIa dqJwQVvCFJ/00qqqxphshFZ+m/+BJkhwMPXgIu1MifA1gPQ/9zoxzELV0n2QSSSpndp/ DlAP5V6PWR5GLthNp0c80kVpy0B6ctEYN3W2x4gMNLKQtD9SzRVPF0Fkcvg+z2EjLmOs VYbOjSCEF0TVV7lX+F36SFVWxuWH/ZpMzBpq1qDzLK8RPyElWH0GJNFRhdRvedxNtCzV 0w==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3429n08rs1-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 09 Oct 2020 15:32:57 -0700
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QHY0015MHAXEGF0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Fri, 09 Oct 2020 15:32:57 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QHY00V00H9W4F00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 09 Oct 2020 15:32:57 -0700 (PDT)
X-Va-A:
X-Va-T-CD: ad184c3815094ce8e051fb224dae675d
X-Va-E-CD: 705702691aedd6670e3687c80c9df5ea
X-Va-R-CD: f7af8795141d8e3099f1341536676977
X-Va-CD: 0
X-Va-ID: 11c6848e-7032-45c2-b347-738d4684c47e
X-V-A:
X-V-T-CD: ad184c3815094ce8e051fb224dae675d
X-V-E-CD: 705702691aedd6670e3687c80c9df5ea
X-V-R-CD: f7af8795141d8e3099f1341536676977
X-V-CD: 0
X-V-ID: 93b2df51-84aa-4e9c-be5f-d609974d7265
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-09_14:2020-10-09, 2020-10-09 signatures=0
Received: from localhost.localdomain (unknown [17.232.183.131]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QHY00FAVHAILY00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 09 Oct 2020 15:32:43 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <4F75DF4C-63D7-4101-A5C5-4057B34EAB23@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_1EDF49EA-2D13-4A2F-A2F4-3C02FA1D989A"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\))
Date: Fri, 09 Oct 2020 15:32:42 -0700
In-reply-to: <CWXP265MB056674BB1E637A04AE2E8860C2080@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM>
Cc: Eric Orth <ericorth@google.com>, "Vinny Parla (vparla)" <vparla=40cisco.com@dmarc.ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, James <james.ietf@gmail.com>
To: Andrew Campling <andrew.campling@419.consulting>
References: <MN2PR11MB47604813E0DC2DDA0E297A36D80C0@MN2PR11MB4760.namprd11.prod.outlook.com> <CAO+dDxn1J2bOz1b8iPKbUnYLTFhSLJRhx9Od5hAHpP3TSkp7yQ@mail.gmail.com> <C276A52C-DCBA-4920-95E1-FAF2D3881D0B@apple.com> <MN2PR11MB476044BA6BD5D47C8088D434D80A0@MN2PR11MB4760.namprd11.prod.outlook.com> <LO2P265MB0573F65FD0DC18B528FD3282C20B0@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <MN2PR11MB47604811528E52E2ED48E41AD80B0@MN2PR11MB4760.namprd11.prod.outlook.com> <CAMOjQcEnhjh_VzQeTFRk6mAF9c8P_i9NMO8S3oMZBv4f81RHew@mail.gmail.com> <CWXP265MB056674BB1E637A04AE2E8860C2080@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM>
X-Mailer: Apple Mail (2.3654.0.3.2.26)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-09_14:2020-10-09, 2020-10-09 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/NvQVMkfT0psvvSdY1c1ByB1FmGg>
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2020 22:33:06 -0000

Hi Andrew,

At least the cookie aspect of this isn’t just a “best practice” of one implementer, but something indeed built into the protocol spec (https://tools.ietf.org/html/rfc8484 <https://tools.ietf.org/html/rfc8484>):

   Determining whether or not a DoH implementation requires HTTP cookie
   [RFC6265 <https://tools.ietf.org/html/rfc6265>] support is particularly important because HTTP cookies are
   the primary state tracking mechanism in HTTP.  HTTP cookies SHOULD
   NOT be accepted by DOH clients unless they are explicitly required by
   a use case.

I think it is incorrect to characterize that DoH has a flawed design by basing itself on a protocol that allows cookies, or allows multiplexing. These are certainly tools provided by HTTP, but it is up to use them or not as appropriate. “Bad” implementations can put information in just about any protocol that could be used for tracking users.

DoH has many benefits to the user for privacy and performance, and I consider it to be entirely in the spirit of RFC 8890.

Thanks,
Tommy

> On Oct 9, 2020, at 1:04 AM, Andrew Campling <andrew.campling@419.consulting> wrote:
> 
> This seems like a great example of best practice.  I wonder though whether it highlights a weakness in the protocol design if it is necessary to rely on goodwill by developers in order to protect the privacy of end users?  Perhaps future developments would take a different path, guided by the policy recently set out by the IAB in RFC8890. 
>  
> Andrew
>  
> From: Eric Orth <ericorth@google.com> 
> Sent: 08 October 2020 17:00
> To: Vinny Parla (vparla) <vparla=40cisco.com@dmarc.ietf.org>
> Cc: Andrew Campling <andrew.campling@419.consulting>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; James <james.ietf@gmail.com>; dns-privacy@ietf.org
> Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>  
> For Chrome, we're currently taking some steps to ensure connection separation between DoH requests and normal content requests.  More specifically, we currently disallow DoH requests from sharing a connection with any requests that are not also blocked from sending or receiving cookies (as are the DoH requests), and we're considering further completely blocking DoH requests from sharing connections with non-DoH.  Primary motivation is privacy.  If DNS is multiplexed up with cookie-containing (or otherwise user-identifying) requests, makes it too easy for even an attempting-to-be-anonymous DNS service to accidentally log requests correlated up with user identity.
>  
> Plans may change in the future as we discover more usecases and if these scenarios become more relevant with some of the ADD proposals around domains designating preferred resolvers, but at least for now, I would anticipate Chrome DNS requests always staying at least somewhat separated from Chrome content requests.
>  
> On Thu, Oct 8, 2020 at 11:13 AM Vinny Parla (vparla) <vparla=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> wrote:
> Hi Andrew,
>  
> I agree with your view and am not in favor of aggregating Content and DNS together, although I can see arguments for doing this.
> I am just wondering if Browser implementors have plans to do this in the future as I need to deal with both OS DNS and Browser (app) DNS scenarios.
>  
> From Tommy’s response I am hopeful the OS implementors won’t do this in the future and will keep DNS an independent mechanism.
>  
> -Vinny
>  
> From: Andrew Campling <andrew.campling@419.consulting <mailto:andrew.campling@419.consulting>> 
> Sent: Thursday, October 8, 2020 4:33 AM
> To: Vinny Parla (vparla) <vparla@cisco.com <mailto:vparla@cisco.com>>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>>; James <james.ietf@gmail.com <mailto:james.ietf@gmail.com>>
> Cc: dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> Subject: RE: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>  
> Important though browsers are for some, DNS is an Internet protocol and needs to work for a wide range of devices and clients.  Mandating its absorption into a multiplexed stream via HTTP/3 seems unnecessary, irrespective of the potential performance gains and other possible benefits for web clients.   
>  
> Andrew
>  
> From: Vinny Parla (vparla) <vparla@cisco.com <mailto:vparla@cisco.com>> 
> Sent: 07 October 2020 15:40
> To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org <mailto:tpauly=40apple.com@dmarc.ietf.org>>; James <james.ietf@gmail.com <mailto:james.ietf@gmail.com>>
> Cc: dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>  
> Hi,
>  
> What I am driving at in my original question is do we envision mixing Content and DNS together in a multiplexed session or will DNS continue to be an entirely independent channel (whether over HTTP/2 /3 Do53 DoQ DoH).
>  
> -Vinny
>  
> From: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org <mailto:tpauly=40apple.com@dmarc.ietf.org>> 
> Sent: Wednesday, October 7, 2020 9:23 AM
> To: James <james.ietf@gmail.com <mailto:james.ietf@gmail.com>>
> Cc: Vinny Parla (vparla) <vparla@cisco.com <mailto:vparla@cisco.com>>; dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>  
> Can you cite this claim about DNS over HTTP/3? The per-query cost once an HTTP/3 connection is established should be minimal. If you’re taking into account all setup overhead for an HTTPS connection as a “per query” cost, that’s not representative of how DoH is reasonably used (and would be a issue with existing DoH).
>  
> Thanks,
> Tommy
>  
> 
> On Oct 6, 2020, at 2:03 PM, James <james.ietf@gmail.com <mailto:james.ietf@gmail.com>> wrote:
>  
> My most recent observations of discussions around DNS over QUIC and HTTP/3 was that some folks had attempted DNS over HTTP/3, however the overheads (~14KiB for a query at worst-case) made it impractical and infeasible. With regards to DNS over QUIC, the current dprive working group adopted draft [1] is focusing on stub to recursive, but not necessarily as a multiplex with an existing QUIC connection.
>  
> - J
>  
> 1: https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00 <https://tools.ietf.org/html/draft-ietf-dprive-dnsoquic-00>
>  
> On Mon, 5 Oct 2020 at 17:31, Vinny Parla (vparla) <vparla=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> wrote:
> Hi,
>  
> It was suggested that I ask this question on the 3 lists:
>  
> Now that QUIC & HTTP/3 is imminent…
>  
> I would like to know what the opinion is of the community on the long term view of DNS.  
> Would DNS remain an independent channel or would it be subsumed in a multiplexed stream via HTTP/3 in some future version?
>  
> For example, would a browser perform DNS queries over a QUIC multiplexed session?
>  (e.g. similar to how today an http proxy can perform DNS queries on behalf of the client using that proxy) 
>  
> Would love to hear from implementors what their long term view is of this in particular.
>  
> Thanks,
>  
> -Vinny
>  
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
>  
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>_______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>