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

Murtaza Aliakbar <murtaza@live.in> Thu, 17 December 2020 22:38 UTC

Return-Path: <murtu42@gmail.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 EE54D3A044E for <dns-privacy@ietfa.amsl.com>; Thu, 17 Dec 2020 14:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.145
X-Spam-Level:
X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57AnvsSkrDPK for <dns-privacy@ietfa.amsl.com>; Thu, 17 Dec 2020 14:38:28 -0800 (PST)
Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (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 96EA73A03FC for <dns-privacy@ietf.org>; Thu, 17 Dec 2020 14:38:28 -0800 (PST)
Received: by mail-qt1-f182.google.com with SMTP id z3so32152qtw.9 for <dns-privacy@ietf.org>; Thu, 17 Dec 2020 14:38:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HevrnosevFPG3sg7wqvBBuD6CN+rPcBX45FKPzMoBiQ=; b=DJy9PlQJrYpMpuzJvRA6/VsLnScXcNzBDHq/p5P98Y03HuKRjUc0K4/ru3i2kYktKP ehUqbD0r1ujFkliAWNZ0yfeidG7CBGLIFRuOu8Pi64rEtwco5H9XOL8XZS4r0IshYUmO Q9OacbqUCKimSt03SAK0S48RPKPXhdodArn7dJFEHWzlkAalQgWy2NlTvI87QWRQPZ2h RKxdCEKjBi8sb7cuyRtxyEZfeivndCJp86nwSoTmkFsUnpJktBB9Yvu3AM0DtfGImM35 92CKQBHJfWT4C+XbpciQgU/Rm38vUG3+uc1/3Lfnv9V47hin9msMIDPPdwaVrWgnbzFk KaTA==
X-Gm-Message-State: AOAM5316+q2fWbLxozJjaSOD82XHsaRd7WRx6MttDqDMGaMS+9rsbpGb lhIOpOv69MS1+M0WCgdEvOg/sdNLmqF45hDukLo=
X-Google-Smtp-Source: ABdhPJyBl1qYQzlKiajgNTT6enKCkenNrXBKqg3RkG8Gi/xssKwuYJ+xI/0cHDRhK4jOReHDqbg0hofZB9vIURFrSO4=
X-Received: by 2002:aed:3051:: with SMTP id 75mr1142681qte.64.1608244707340; Thu, 17 Dec 2020 14:38:27 -0800 (PST)
MIME-Version: 1.0
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> <cfbaf15f-d3f7-99e6-b609-d07dafbb84f5@huitema.net> <CACJ6M17iU0mRfRT6VNWyHo+FWqp7uST7DittfDZG0RuKq1==ow@mail.gmail.com> <MN2PR11MB4760361A9ACF968F1AE6364AD8C40@MN2PR11MB4760.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4760361A9ACF968F1AE6364AD8C40@MN2PR11MB4760.namprd11.prod.outlook.com>
From: Murtaza Aliakbar <murtaza@live.in>
Date: Fri, 18 Dec 2020 04:08:16 +0530
Message-ID: <CABNj-GS_62w2+JDcOi682=8K6A=tx+s+Y479GZ6GOh1fDrPYdA@mail.gmail.com>
To: "Vinny Parla (vparla)" <vparla=40cisco.com@dmarc.ietf.org>
Cc: dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007e390d05b6b0a6a8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/M7pCuhezYv0RkMsmDiBjtrvUBqo>
X-Mailman-Approved-At: Mon, 21 Dec 2020 06:18:26 -0800
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: Thu, 17 Dec 2020 22:38:31 -0000

We at RethinkDNS deployed DNS over HTTP3 (not DoQ though) in August. Didn't
know there was a race going on :)

Sent from my Nexus

On Fri, Dec 18, 2020, 2:03 AM Vinny Parla (vparla) <vparla=
40cisco.com@dmarc.ietf.org> wrote:

> Just reviving this thread with the recent news to see what folks think in
> terms of content and dns multiplexing.
>
> Ad-blocker AdGuard deploys world's first DNS-over-QUIC resolver | ZDNet
> <https://www.zdnet.com/article/ad-blocker-adguard-deploys-worlds-first-dns-over-quic-resolver/>
>
>
>
> *From:* Chris Box (BT) <chris.box.ietf@gmail.com>
> *Sent:* Wednesday, October 7, 2020 1:05 PM
> *To:* Vinny Parla (vparla) <vparla@cisco.com>
> *Cc:* dns-privacy@ietf.org
> *Subject:* Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
>
>
>
> Vinny,
>
>
>
> Christian makes a number of good points. I will just add that your
> original question assumes that the client wishes to send most or all of its
> DNS queries directly to the content provider it is talking to. The ADD
> working group is founded on the concept of needing to discover recursive
> resolvers, and very often these are not the same endpoints that the web
> content is served from. This implies that reuse of an existing HTTP/3
> connection that was established for retrieving web content, will not be the
> end goal for DNS queries. Sometimes it'll happen, yes, but certainly not
> all the time. It is far more likely that DNS will continue to be an
> independent layer, served by its own set of servers that has only *some*
> overlap with the set that serves web content.
>
>
>
> Chris
>
>
>
>
>
>
>
> On Wed, 7 Oct 2020 at 17:25, Christian Huitema <huitema@huitema.net>
> wrote:
>
> 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> 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>
> *Sent:* Wednesday, October 7, 2020 9:23 AM
> *To:* James <james.ietf@gmail.com>
> *Cc:* Vinny Parla (vparla) <vparla@cisco.com>om>; 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> 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> 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
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> _______________________________________________
> dns-privacy mailing list
> 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
>
> _______________________________________________
> dns-privacy mailing list
> 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
>