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

Tommy Pauly <tpauly@apple.com> Wed, 07 October 2020 15:31 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 9DCF63A0A6E for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 08:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.3
X-Spam-Level:
X-Spam-Status: No, score=-3.3 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_H2=-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 EXaGfWU0ZVtl for <dns-privacy@ietfa.amsl.com>; Wed, 7 Oct 2020 08:31:32 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 02A5B3A0A5E for <dns-privacy@ietf.org>; Wed, 7 Oct 2020 08:31:31 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.43/8.16.0.42) with SMTP id 097FJvmF057494; Wed, 7 Oct 2020 08:31:30 -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=AIV+9xA/regH/MCb8HmWm5QVEIv1JkrHA9XWwAEgm64=; b=Ion1GreKxG7M9FXv1oVn947Ajcra2U3xrR2gBzfpf025qys6Ljq/ne174wy6J/2BwKmE OjOKQkYZEMC81o6vyhvK1R8gdlJC0pYbqr+0kA48vzrwcieovYoxZJujWvAINZ1+lf21 TN+4UgEl60wDfi8jjI3kTsBl4YwGiVjao/b97oVEivk4ntuh2LdvYiCxPSnAga3lmC1r j9ZSpwLaZhJcwW8ZXSkZDIqg06bS20ZDD9b4EzkWTzQveRfKXS22FoeL5osyoKTW0Ff0 KgOp5Zpj915A2thrxDcYaFrPffA8Jq7SVYEuHAatuwLXnigbbOMGYcPKx5WlmlmvuZ9B Jw==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp01.apple.com with ESMTP id 33xr80y52n-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 07 Oct 2020 08:31:30 -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-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QHU00G5W8GH9U40@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 07 Oct 2020 08:31:29 -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 <0QHU00A007N92G00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 07 Oct 2020 08:31:29 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 5f626032598cf14d26a7087b358c5838
X-Va-E-CD: 705702691aedd6670e3687c80c9df5ea
X-Va-R-CD: f7af8795141d8e3099f1341536676977
X-Va-CD: 0
X-Va-ID: cb56d601-e643-4c7b-8aa8-b739a7016ba6
X-V-A:
X-V-T-CD: 5f626032598cf14d26a7087b358c5838
X-V-E-CD: 705702691aedd6670e3687c80c9df5ea
X-V-R-CD: f7af8795141d8e3099f1341536676977
X-V-CD: 0
X-V-ID: ebd900c1-b7da-4358-85d4-69d595502b47
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-07_09:2020-10-06, 2020-10-07 signatures=0
Received: from localhost.localdomain (unknown [17.234.7.156]) 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 <0QHU00NNW8GGLA00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 07 Oct 2020 08:31:29 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <F0B35F84-E3F8-44B2-9A06-FDF2C725229E@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_F0A17BF3-1FBC-403A-AFFE-CD03F378BCFB"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\))
Date: Wed, 07 Oct 2020 08:31:27 -0700
In-reply-to: <MN2PR11MB476044BA6BD5D47C8088D434D80A0@MN2PR11MB4760.namprd11.prod.outlook.com>
Cc: James <james.ietf@gmail.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
To: "Vinny Parla (vparla)" <vparla=40cisco.com@dmarc.ietf.org>
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>
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-07_09:2020-10-06, 2020-10-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/jSnQLt_3vIvA2TzBVzr2ZbMr_DE>
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 15:31:34 -0000

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 <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>