From nobody Sat Sep 26 05:00:20 2020 Return-Path: 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 4CFAE3A0597 for ; Sat, 26 Sep 2020 05:00:18 -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=ham 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 Gn5TEjwVsDmR for ; Sat, 26 Sep 2020 05:00:16 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 056963A044A for ; Sat, 26 Sep 2020 05:00:15 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id k18so4043929ybh.1 for ; Sat, 26 Sep 2020 05:00:15 -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=2mpmRQHg8ru03b4qa9XzacD4+nv/qqZi55RSrMmATL4=; b=U0n8zOw+lalgK2ZNGua13Oy+4CHA1ZYW9A9PmGtsDFdugmRVpXYNjfsw8IPEtqbvdD Az1iddQdpRUKLin/ap/VgGj0zgSm1MKIHfb7dPsUB1e4lVfcYLBS2J9hm9Ehdt9/vxnD 4Tj5AH+MLPJ+/oWaVE6gUkYU7X5QRN5PTfiYdoWcxt2OAnH2nbdO44zhhMP78Xh/+6il 2qC5DxmvT3HLqOtEoj3WTz5JJDMej//aYHL/zVbArC6XlnYdKwpkOFmLSOTLOkiPMGjo Qlch25PdsMwzGztGYwhvf+w28/k/BZ7x1zFP7x9N3iqUE8Stpnw0FB7nvqUdh9EWrynP kuBQ== 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=2mpmRQHg8ru03b4qa9XzacD4+nv/qqZi55RSrMmATL4=; b=sOU6dRRd+l8wKfFOqJmsh2S2I4+QODQIh7zjjyQdpg+SgMxI71+PH5SZ56Fj0fQqQD 9Tx9oXbDXV4disWRoQC6Y8HhnmxGywkRKc5qEUQ1u5dbCG0K2dYtZoTK/YyL+WcOhEM1 pS3YpCyTZzBYmpqhh0prRXIMgGXawiSL27aRCBLFMqBE3Ww/ipRw+x7w3E+YB6EXX2Zc CfGMDd8zeA+G5uGBrZKxMe9u6EGVjDxgI1eGg20t8nx924Z+cpIWvfNIa5ohKe1QpADh VSv4GuTrfkyzc5PONHNLP6U1e34EU3rE2VKzf9CZirOVWD/k3gOQsRqmHvGM+FjNgS9v 0z0A== X-Gm-Message-State: AOAM531wdrPQNfRikLQw4nuzrIj6jCXPumyIrIqOcGn3yPL/4T2HUPIZ A9NS1Aur4SmA4f4uat/XIOI185FKhZBjmqz/r16xxw== X-Google-Smtp-Source: ABdhPJxLPtcVW696DPhWFdP0eIP6nESyTWLXtBCcmcN/C6/GeIcxueUUkzyE7Zg7/Vzth1MnupQXB8NwKYmWBf7b4Yg= X-Received: by 2002:a25:384e:: with SMTP id f75mr4696836yba.389.1601121614711; Sat, 26 Sep 2020 05:00:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Sat, 26 Sep 2020 08:00:03 -0400 Message-ID: To: Tommy Pauly Cc: Jana Iyengar , David Schinazi , dnsop WG , QUIC WG Content-Type: multipart/alternative; boundary="00000000000016dab905b0362df2" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 12:00:18 -0000 --00000000000016dab905b0362df2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 25, 2020 at 10:09 PM Tommy Pauly wrote: > Hi Jana, > > Currently, HTTP/3 support in Safari needs to be enabled by the user (unde= r > 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 o= f > 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. Thanks, Ian > > Thanks, > Tommy > > On Sep 25, 2020, at 6:08 PM, Jana Iyengar wrote: > > =EF=BB=BF > 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 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/NSURLSessi= on >> for URL schemes =E2=80=9Chttp://=E2=80=9C and =E2=80=9Chttps://=E2=80=9C= , or TCP port 80 or port 443. >> >> Thanks, >> Tommy >> >> On Sep 25, 2020, at 1:12 PM, David Schinazi >> wrote: >> >> Hi Tommy, >> >> Thanks for the announcement! It's really exciting to see this deployed i= n >> 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 contex= t >> of >> a Network.framework connection to port 443) >> >> David >> >> On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly > 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-implementati= ons.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 th= e >>> 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=E2=80=99d encourage other server deplo= yments 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 >> >> >> --00000000000016dab905b0362df2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Sep 25, 2020 at 10:09 PM Tommy Pa= uly <tpauly=3D40apple.com@= dmarc.ietf.org> wrote:
Hi Jana,

Curr= ently, HTTP/3 support in Safari needs to be enabled by the user (under Expe= rimental Features). When it is enabled, the ALPN hint in the HTTPS record c= auses the stack to race QUIC first (assuming we have no history of QUIC fai= lures), even when no previous connections had been made to the host.=C2=A0<= /div>

What if there is a history of Q= UIC failures and what constitutes a failure?=C2=A0 And is the history per-h= ost, per-user or some combination thereof?

I'm= curious=C2=A0how this logic compares to Chrome's current logic.
<= div>
Thanks, Ian
=C2=A0

Thanks,
Tommy

On Sep 2= 5, 2020, at 6:08 PM, Jana Iyengar <jri.ietf@gmail.com> wrote:

=EF=BB=BF
Th= anks 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=3D40apple.com@dmarc.ietf.org> wrote:
Hi David,

S= orry for the lack of clarity! The HTTPS query will be made alongside A/AAAA= queries for all connections that use Network.framework/NSURLSession for UR= L schemes =E2=80=9Chttp://=E2=80=9C and =E2=80=9Chttps://=E2=80=9C, or TCP = port 80 or port 443.

Thanks,
Tommy

On Sep 25, 2020, at 1:12 PM, David Sc= hinazi <ds= chinazi.ietf@gmail.com> wrote:

Hi Tom= my,

Thanks for the announcement! It's really excitin= g 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=C2=A0single time you perform A/AAAA queries? (in the con= text of
a Network.framework connection to port 443)
David

On Fri, Sep 25, 2020 at 12:59 PM Tommy Pauly <tpa= uly=3D40app= le.com@dmarc.ietf.org> wrote:
Hello DNSOP & QUIC,

I want= ed to provide an update that the production version of iOS 14, which shippe= d 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:=C2=A0https://github.com/MikeBishop/dns-alt-svc/blob/master/svc= b-implementations.md

For those with HTTP/3 QUI= C 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 pri= or to receiving an Alt-Svc indication. As previously noted on the DNSOP lis= t, Cloudflare is already supporting publishing these records, and we=E2=80= =99d 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
http= s://www.ietf.org/mailman/listinfo/dnsop
--00000000000016dab905b0362df2--