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

Eric Orth <ericorth@google.com> Thu, 08 October 2020 15:59 UTC

Return-Path: <ericorth@google.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 B92643A0E4B for <dns-privacy@ietfa.amsl.com>; Thu, 8 Oct 2020 08:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prqocrx8KMRn for <dns-privacy@ietfa.amsl.com>; Thu, 8 Oct 2020 08:59:49 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 591D13A0E44 for <dns-privacy@ietf.org>; Thu, 8 Oct 2020 08:59:49 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id t9so7187355wrq.11 for <dns-privacy@ietf.org>; Thu, 08 Oct 2020 08:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0HeQHlwaMWMIyfCH3oNlN0wLraCr8CYKXxCh95lJMq0=; b=Y53Sf/7Cd0asfZXG+VoT0ca/9X7ihtKiyudbGIdzkv3Yf+YXdV7KBu07x5xiQHH76D Jb7buPUwRW58fuY4ePocJy8atxBvldBJA8P0VCkdaD9mxLYiXCqBuKjCwq8RILeNXNY+ jJ4SYQv2ayXh1iZC6uJ+RdU/xgqfovCXVZzUiF+GcFSZv7hgTCoZmtIzOIdXmtNO1b7A SEjbAopqqFwbVsKxKxgIusJHHMJdJIqduJMCcap2lUvSG4X+kP5riIJFeVsK5U9Y4GTt 44C23cu4c6jIiwcmN0OevVOVb83NqNWh3kecNdPn73QmU5UZKNgy5qBieswfNFiWRUHK ixSQ==
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=0HeQHlwaMWMIyfCH3oNlN0wLraCr8CYKXxCh95lJMq0=; b=kTeqtIQb8gnIn/8UoBjSVSEXvUclkbEJmVWAXKP6P5b4ytfDW5Zs8g7o6SySNF+Nl2 6hhhc3LAHdgZIssrEbfKnvVrPVYsZc6AC7ycnknEtm3/V9Zp+y5hlojB4vxhLMxSYkCX 0VXO3hCmjFNBGajZTKYe2yL6vCXUGiPF4y0w1hnDz4Kg4Lf8h5RbxjDodzKHI+N71cZD XmB5yw++Cg+MVdcZ64aU2bOTvIjHUOMfGeimniZA2vTcaRfPNWltF0Gx++j+/HwamePM o4lbEXCPXSs1TJV5ZmwU+YrwRngRfeM9+r2fsO32KQxO9pf1tElKg2Ku50kP9o8wt4om jzfw==
X-Gm-Message-State: AOAM532ZmvKOruthgq1H0OTHlU9MzlIWO9xormiX9b6XmXXJ/9f+H+ZN 2RCn6fzDdtde2FIFc6NJNLr2AXxVaD78IMTfHdrlkw==
X-Google-Smtp-Source: ABdhPJzxd0XPUQ+o3P5ytAZ6/chHbM8DLOn4cKlc6NWjwasEZ74EAY3Xld+wkjAW2N4yc944pkbWQkoo6BxSup7SY/c=
X-Received: by 2002:a05:6000:1633:: with SMTP id v19mr7810561wrb.147.1602172787433; Thu, 08 Oct 2020 08:59:47 -0700 (PDT)
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> <LO2P265MB0573F65FD0DC18B528FD3282C20B0@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <MN2PR11MB47604811528E52E2ED48E41AD80B0@MN2PR11MB4760.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB47604811528E52E2ED48E41AD80B0@MN2PR11MB4760.namprd11.prod.outlook.com>
From: Eric Orth <ericorth@google.com>
Date: Thu, 8 Oct 2020 11:59:35 -0400
Message-ID: <CAMOjQcEnhjh_VzQeTFRk6mAF9c8P_i9NMO8S3oMZBv4f81RHew@mail.gmail.com>
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" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dd821f05b12aebe8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/RbdD7hEIOTOteHQ8ZfBjj9FcZuM>
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, 08 Oct 2020 15:59:53 -0000

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> 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>
> *Sent:* Thursday, October 8, 2020 4:33 AM
> *To:* Vinny Parla (vparla) <vparla@cisco.com>om>; Tommy Pauly <tpauly=
> 40apple.com@dmarc.ietf.org>gt;; James <james.ietf@gmail.com>
> *Cc:* 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>
> *Sent:* 07 October 2020 15:40
> *To:* Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>rg>; James <
> james.ietf@gmail.com>
> *Cc:* 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>
> *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
>