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

Christian Huitema <huitema@huitema.net> Wed, 07 October 2020 16:25 UTC

Return-Path: <huitema@huitema.net>
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 418EE3A0ADA for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 09:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level:
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aErt5pCxuAJQ for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 09:25:00 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA78A3A0ACC for <dns-privacy@ietf.org>; Wed, 7 Oct 2020 09:24:59 -0700 (PDT)
Received: from xse466.mail2web.com ([66.113.197.212] helo=xse.mail2web.com) by mx171.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kQCFG-000KGv-Ot for dns-privacy@ietf.org; Wed, 07 Oct 2020 18:24:54 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4C602Y6lTjz4FSY for <dns-privacy@ietf.org>; Wed, 7 Oct 2020 09:21:25 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kQCBx-0001Ro-Pv for dns-privacy@ietf.org; Wed, 07 Oct 2020 09:21:25 -0700
Received: (qmail 13865 invoked from network); 7 Oct 2020 16:21:25 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.139]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <james.ietf@gmail.com>; 7 Oct 2020 16:21:25 -0000
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, "Vinny Parla (vparla)" <vparla=40cisco.com@dmarc.ietf.org>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>, James <james.ietf@gmail.com>
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> <F0B35F84-E3F8-44B2-9A06-FDF2C725229E@apple.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <cfbaf15f-d3f7-99e6-b609-d07dafbb84f5@huitema.net>
Date: Wed, 7 Oct 2020 09:21:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <F0B35F84-E3F8-44B2-9A06-FDF2C725229E@apple.com>
Content-Type: multipart/alternative; boundary="------------6E1CB86EDA743024CF16CFF8"
Content-Language: en-US
X-Originating-IP: 66.113.197.212
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVJwSfHR/B1Dkw ojKP1TcIN0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwPzgJ2Ucltmld9WkfaJBY9Xt FNSzkMWnDricnMrpFJqVSKx2B0t98dSozdaEfW7yQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEOJcngm7dP1+Wt3AZM6dWpe42Vki7412dpbhrD2d47zYVVSdp lb6JAjtr1Y6X6/3l9/kVsZY09AACYKLhz64OURX7oqIvmakKXcEre1TXJK87UusOPd3rYq8a3sTe TENWRAwX31WVY5lWjWxuGSRuxUBpWL6Jpiq+19aGAPT3alfquKa7TMclDR1ItIoLM3GGu26svGUu tW6twupTSrWQBKLqGvUU4QaGCh0e5PQXeR9LGMr8SlAfzs759ewgAN/rPw+s05eJgPEUif0vbg0t ZM9jtS6Zuw56NzJ4HoAbKeEtjEbRrFHvESnMqzLGulVotOWjR7vVQidrBSxUUU6VX/vg7iEFLP+S SY+Av5+AiC7wP3XSsbOh+heeqipmXQim/UDP/tafarMZsm7T2PJJI66/fmD/cDmldne+UZ6uCACD i1jwT58ciSMJFr3BrJRHtY/s/Uvv+FwuDLtpbo7237gbhIjFDhSjHjVkMDx/0PtgzpOKSmxt687c vHBXDigV45Sz8N+zHgMEHc5b8iQPFrs02hkni945serl5nRV5ZFsV7Qbdglc/555u0EO04swV6P3 lS3oElcJpcQm1Km0ayG7X+t1TW39Ja77LGPpOwCUooiGwt/Lp2rwHpWEXc4SbXyqbVcApZjFxLn8 nAlZYfOi6HTmY+/cXUo8ym6keVx5NKotYZMP4QxilpD1WJVxdwYWcRoGRTsLxqa8TRmmuv9qwM7R XpJS8RjTdyh2j5DIweuSooT6tSPU1x5zpUpIPziDkWQ5faPk5nJXHz00MDRj9D8HLKHAKpPGP8EP nuB53cHIFHavQpo3FUDrLYIQ
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/l0i52yNOq7BH4w_D4pq4XTltM-w>
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: Wed, 07 Oct 2020 16:25:02 -0000

There is indeed some extra per request overhead for Doh over HTTP3
versus Dns over QUIC, but I don't think that is the deciding factor. I
think that the two other decision factors are for the client the privacy
risks linked to cookies and other forms of HTTP tracking, and for the
server the additional attack surface caused by adding an HTTP server
stack to the DNS service. These factors may play out differently in the
stub to recursive scenario and in the recursive to authoritative scenario.

In HTTP-3, each DNS request would be carried by as a POST command, which
requires a Header Frame to carry the HTTP header parameters and a Data
Frame that carries the actual data. Each reply also requires a Header
Frame and a Data Frame. In the fairly minimal implementation of HTTP-3
in Picoquic, the HTTP header carries the name of the Request URL, the
name of the Http Server, and the content type. The Data Frame header
carries the content length. The typical overhead for a request would be
16 to 32 bytes, depending on the length of server name and URL; the
overhead per response will be 21 bytes. A full implementation of HTTP-3
would use header compression to reduce the size of the query overhead,
but might use an additional set of HTTP header elements, including
cookies, so the Header Frames might be larger in both directions, with a
range of header size from a few dozen to a few hundred bytes.

Running over HTTP brings to the DNS the privacy issues of HTTP. Cookies
and other headers are used to manage content and caches, but also
identify the users and enable a variety of surveillance scenarios. If a
DoH query is multiplexed inside a regular HTTP session, the query will
be associated with all the user information gathered in the session,
which creates an important privacy exposure. This is definitely a
greater exposure than a regular DNS query, in which the main identifying
information is an IP address.

On the server side, running over HTTP implies running on top of an HTTP
server engine. This brings in a lot of code, some of it complex. It
might be well tested and well maintained code, typically much better
tested and maintained than if a server operator attempted to develop a
specialized implementation of HTTP, but this is still a very large
additional attack surface. Moreover, the HTTP code only remains "well
maintained" if the operators regularly apply updates, which adds an
operational constraint.

I think that the exposure and overhead issues imply that solutions like
DoT or DoQ should be preferred to DoH in recursive to authoritative
scenarios. They should also be preferred when the stub resolver is part
of the operating system, because operating system resolvers would
normally not mix their queries with existing HTTP sessions, and thus
don't get any advantage from "integrating to the web" -- unless of
course firewall traversal is a big issue.

-- Christian Huitema


On 10/7/2020 8:31 AM, Tommy Pauly wrote:
> DoH is designed to be multiplexed with other HTTP requests. This is
> already possible with HTTP/2, and HTTP/3 carries on that ability. In
> order to take advantage of multiplexing, even with QUIC, you need some
> application-layer awareness of the content of the streams, which is
> why this is more practical with DoH than DoQ.
>
> I’m not sure how prevalent the multiplexing is today. For example, in
> our system implementation on iOS/macOS, DoH connections are made by
> the system DNS daemon and thus are not easy to multiplex with
> requests. However, that’s just one model, and there are certainly
> cases where the application would know it could multiplex a priori
> (and thus do DoH in the application), or could recognize that DNS
> results point to the same address as the DoH server, and start
> multiplexing after the fact.
>
> Thanks,
> Tommy
>
>> On Oct 7, 2020, at 7:39 AM, Vinny Parla (vparla)
>> <vparla=40cisco.com@dmarc.ietf.org
>> <mailto:vparla=40cisco.com@dmarc.ietf.org>> wrote:
>>
>> 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
>>      
>>     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
>>
>>     _______________________________________________
>>     dns-privacy mailing list
>>     dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy