Re: [DNSOP] DNS HTTPS/SVCB record type support in iOS 14

Tommy Pauly <tpauly@apple.com> Sat, 26 September 2020 16:02 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56573A0940; Sat, 26 Sep 2020 09:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.794
X-Spam-Level:
X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 7_Np4q0C4BQu; Sat, 26 Sep 2020 09:02:37 -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 466063A093D; Sat, 26 Sep 2020 09:02:37 -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 08QG1E1p003860; Sat, 26 Sep 2020 09:02:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=elzFUBYeXG3PlCrEOwWzQ7YPP/4uvYlPM/gsv45J+04=; b=LnTVQXXCGAA/V5Ze/EzHpqPEnUxGr6MXUwdpEVEoKMLk+S3KUtnQe9Oli4Q8b0cSMwgZ XlgKDOyIHvvDWzcx8tl44pB3ojQlnzAFPp8vJQo+cQF+C9GFTTP3omiNu/xZGYzkivfp W+i5g/LH34E/EUrLmDnHWLAztX7AnM0LLRAxB5AfaEyrAZBeYnlkUiFMEP0pppYp8UNd yUyJ09T1CScfEnuMOZd44j4/6JfRkMtd395ssOvf+q/cUleIIoQIY3RBTq/px3An3xYu PXB6HmhK0cRz2bt4amZ3ygIRqgCAkiERojSher2lDC9HLCF5V0RBrEcdMw1ZeOm81fOP qA==
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 33t4jwbem9-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 26 Sep 2020 09:02:35 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) 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 <0QH90004JWK4WW20@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sat, 26 Sep 2020 09:02:28 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QH900U00WG5W800@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 26 Sep 2020 09:02:28 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 8154b23b3511e33f7d3c4e1c60118686
X-Va-E-CD: e876165c9a9a1c02d6ae715e100a7f1a
X-Va-R-CD: a244d06e8d95a99d70ca2b44f71fbcff
X-Va-CD: 0
X-Va-ID: c86f53e8-b75a-4122-9486-9d986983fbe5
X-V-A:
X-V-T-CD: 8154b23b3511e33f7d3c4e1c60118686
X-V-E-CD: e876165c9a9a1c02d6ae715e100a7f1a
X-V-R-CD: a244d06e8d95a99d70ca2b44f71fbcff
X-V-CD: 0
X-V-ID: 21bbc66a-cb05-4981-99e6-090317add653
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-26_14:2020-09-24, 2020-09-26 signatures=0
Received: from localhost.localdomain (unknown [10.104.36.47]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QH900P89WK2FF00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 26 Sep 2020 09:02:26 -0700 (PDT)
Content-type: multipart/alternative; boundary=Apple-Mail-9099655E-C405-4A33-8D75-BCFA8A1621B6
Content-transfer-encoding: 7bit
From: Tommy Pauly <tpauly@apple.com>
MIME-version: 1.0 (1.0)
Date: Sat, 26 Sep 2020 09:02:25 -0700
Message-id: <4324E079-7EC6-40DB-81D2-6E4099D2D1CC@apple.com>
References: <CAKcm_gMB74fpV2SGSRTjNMV1jvnSD+rH=EZXZLnPbWcVpp=Dng@mail.gmail.com>
Cc: Jana Iyengar <jri.ietf@gmail.com>, David Schinazi <dschinazi.ietf@gmail.com>, dnsop WG <dnsop@ietf.org>, QUIC WG <quic@ietf.org>
In-reply-to: <CAKcm_gMB74fpV2SGSRTjNMV1jvnSD+rH=EZXZLnPbWcVpp=Dng@mail.gmail.com>
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (18A373)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-26_14:2020-09-24, 2020-09-26 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bRMDtwRRVWL4wgNy9WOe2DR8L3E>
Subject: Re: [DNSOP] DNS HTTPS/SVCB record type support in iOS 14
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Sep 2020 16:02:39 -0000


> On Sep 26, 2020, at 5:01 AM, Ian Swett <ianswett=40google.com@dmarc.ietf.org> wrote:
> 
> 
> 
>> On Fri, Sep 25, 2020 at 10:09 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>> Hi Jana,
>> 
>> Currently, HTTP/3 support in Safari needs to be enabled by the user (under Experimental Features). When it is enabled, the ALPN hint in the HTTPS record causes the stack to race QUIC first (assuming we have no history of QUIC failures), even when no previous connections had been made to the host. 
> 
> What if there is a history of QUIC failures and what constitutes a failure?  And is the history per-host, per-user or some combination thereof?
> 
> I'm curious how this logic compares to Chrome's current logic.

We store a history of success/failure/losing the race on a per-host basis. This is based on our logic for racing IPv6 and IPv4 for happy eyeballs. If we have no successful QUIC connections within a certain period of time, but have a number of failures or lost races above a threshold (~10), we’ll race with TCP first. If a failure is detected at the H3 layer (not in the race or in the QUIC handshake), we have a lower threshold before swapping the race order. 

Thanks,
Tommy 

> 
> Thanks, Ian
>  
>> 
>> Thanks,
>> Tommy
>> 
>>>> On Sep 25, 2020, at 6:08 PM, Jana Iyengar <jri.ietf@gmail.com> wrote:
>>>> 
>>> 
>>> Thanks for sharing this, Tommy -- this is exciting indeed.
>>> Can you share if Safari uses this information for deciding when to race a QUIC connection?
>>> 
>>> - jana
>>> 
>>>> On Fri, Sep 25, 2020 at 1:19 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>>>> Hi David,
>>>> 
>>>> Sorry for the lack of clarity! The HTTPS query will be made alongside A/AAAA queries for all connections that use Network.framework/NSURLSession for URL schemes “http://“ and “https://“, or TCP port 80 or port 443.
>>>> 
>>>> Thanks,
>>>> Tommy
>>>> 
>>>>> On Sep 25, 2020, at 1:12 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
>>>>> 
>>>>> Hi Tommy,
>>>>> 
>>>>> Thanks for the announcement! It's really exciting to see this deployed in the wild.
>>>>> Clarification question: your email mentioned support for the HTTPS DNS query,
>>>>> but it didn't mention when iOS makes those queries. For example, do you query
>>>>> this record every single time you perform A/AAAA queries? (in the context of
>>>>> a Network.framework connection to port 443)
>>>>> 
>>>>> David
>>>>> 
>>>>> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>>>>>> Hello DNSOP & QUIC,
>>>>>> 
>>>>>> I wanted to provide an update that the production version of iOS 14, which shipped last week, includes support for sending HTTPS (SVCB) DNS queries (RR type 65) for applications using our system networking APIs.
>>>>>> 
>>>>>> The implementation status has been updated here: https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
>>>>>> 
>>>>>> For those with HTTP/3 QUIC deployments, this means that (when HTTP/3 experimental support is enabled) iOS will use the ALPN indication in the HTTPS record to enable HTTP/3 prior to receiving an Alt-Svc indication. As previously noted on the DNSOP list, Cloudflare is already supporting publishing these records, and we’d encourage other server deployments that support QUIC to do the same.
>>>>>> 
>>>>>> To note, this behavior is the same in the betas of macOS 11.
>>>>>> 
>>>>>> Best,
>>>>>> Tommy
>>>>> _______________________________________________
>>>>> DNSOP mailing list
>>>>> DNSOP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>