Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0EB3A0D9C for ; Fri, 26 Jun 2020 23:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PMbHSZYo2IiY for ; Fri, 26 Jun 2020 23:10:41 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 282C93A0D7E for ; Fri, 26 Jun 2020 23:10:41 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id k6so10285845ili.6 for ; Fri, 26 Jun 2020 23:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xyg8X8VEthzCcIvwETHEXtaaXetKDUzGwuBmjDZ/pmc=; b=Icf4m53W+tECPufLooaPjaTvNIwhhuHpe9gNyHe0QxFAxibT1c4zzKLv9DPzYVrC7I Zewy9sUmA58wRIrJzKY7VUnEq5n7SpNMH1mxq+GgCJLaBQEjoyWUg/j1NENTksmi4isi iWRVwVY3tUlOCeDlfcWnC2dU2Xuw87fdSE6Zp+1W/dvihpGmiwafP5kY5zdHdtjiM7gr UEg+BW3LAVLzPAyjl+5BtKJljPSf+rXzoWFxDAi1Om+rrhQVt5IrdHO8md9uOAgS8/no UP0QLi7XEf9ACehnCzWOgIkHoYE6eQMGA8CAJod8oNkLZrvru98Y+tUcvNGeNxvOpVaf GrwA== 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=xyg8X8VEthzCcIvwETHEXtaaXetKDUzGwuBmjDZ/pmc=; b=UxAsj9ZrYFdkLLLGVwozgda5KYtFIoa1H8kKDOiAXkGdQWbFlf3mN+L9F4F6lmZkqC FSRqic3bX7+3irJx1I9Y2V/2RrEq6xbghJkKyYU91pTlGd4npVp5V+J6/6TJF6w+30VW WCaRn3BIUBVOyZgZ7UeIQrVFuMXPKes1g5NY/3a/QXRxuvHZpXlmNLOTioMy0qiCExWh O9+JeD/ld3il3J7rrmQTp6ceT6b4G53zTAhirc+DV2iy6WGn32KzCJivjjlZlpS5ANy1 W9c02kBQTKtqqvDC3QSG3ziMCdUUmIgXx9LfErHhuxk+rR+iWjkhEsELiXh3UlXyYgbx lagg== X-Gm-Message-State: AOAM531RfQmHzH0V8iJgeIvT3JmayeUHTeoFTpWbuhwhu2OFaBp/MAfA tbUELwQGmwcnJyAYIP5xXXmd0Tl7B6Vyyr7fMy/slQ== X-Google-Smtp-Source: ABdhPJy32tQasFX0LPgthGp4RPRY7JCnMZqRkvpXO5RR4Kj6NYles5qEUSDexBCnO2IuuSF/ZMr+BpekKeHEk1SeYBc= X-Received: by 2002:a92:a04e:: with SMTP id b14mr6692896ilm.261.1593238240175; Fri, 26 Jun 2020 23:10:40 -0700 (PDT) MIME-Version: 1.0 References: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> In-Reply-To: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> From: Manu Bretelle Date: Fri, 26 Jun 2020 23:10:29 -0700 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000592a1405a90aaf4c" Archived-At: Subject: Re: [Add] Encrypted DNS support in iOS and macOS X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 06:10:51 -0000 --000000000000592a1405a90aaf4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Tommy for providing more on the technical details behind the implementation. The implementation looks solid and will take care of a lot of the edge cases (captive portal, administered device, vpn, happy eyeball), lifting a lot from the application developpers. There is one case that I did not see mentioned yet and I wonder if it is already supported or if there is any plan in supporting/detecting it, which is NAT64/DNS64. Thanks! Manu On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly wrote: > Hello, > > I want to share some relevant updates with the ADD working group about > encrypted DNS support in iOS and macOS. > > In the iOS 14 and macOS 11 betas, DoH and DoT are both natively supported > by the system DNS resolvers. These are technologies that many apps have > already been using on iOS and macOS via VPN provider APIs or by embedding > application-specific DNS resolver code. Now that these protocols are buil= t > into the operating system, these use cases can move over to a > system-provided path that provides greater efficiency and tighter > integration with built-in APIs that provide Happy Eyeballs and other > features. > > These videos released as part of the Worldwide Developer Conference cover > details of how encrypted DNS can be used by app developers: > > Build trust through better privacy: > https://developer.apple.com/videos/play/wwdc2020/10676 (Timestamps > 11:55-13:50) > Enable encrypted DNS: > https://developer.apple.com/videos/play/wwdc2020/10047/ > > One of the key goals of integrating encrypted DNS into the operating > system is ensuring that when users get the privacy and security benefits = of > encrypted DNS, they don=E2=80=99t have to face breakages for key use case= s that > require interaction with local DNS providers and private/enterprise DNS > servers. Beyond that, the APIs are designed to make it easy to migrate to > automatic use of encrypted DNS=E2=80=94the goal of the ADD working group. > > To summarize the WWDC videos, there are three different ways that > encrypted DNS is being used in the iOS and macOS betas: > > 1. Provide a system-wide encrypted DNS resolver selection, as an > alternative to providing a =E2=80=9CVPN=E2=80=9D configuration that ju= st configures DNS > 2. Require encrypted DNS within an app (along with a resolver to > prefer if no encrypted resolver is otherwise available), as an alterna= tive > to apps embedding their own DNS resolution code > 3. Start automatically discovering designated resolvers for domains > that advertise a DoH URI > > I=E2=80=99m including details for each of these three mechanisms below. > > Best, > Tommy > > > > System-wide: > (https://developer.apple.com/documentation/networkextension/dns_settings) > (https://developer.apple.com/documentation/devicemanagement/dnssettings) > A system-wide DNS configuration can be provided either by an app that use= s > the NetworkExtension framework, or a configuration profile that can be > installed by the user or by an enterprise Mobile Device Management > solution. These configurations can select an encrypted DNS server for all > domains or only a subset of domains; and can apply to all networks or a > subset of networks and network types. > > System-wide configurations require an explicit opt-in by a user through > Settings, or configuration of a managed device by an enterprise or simila= r > organization. To this end, it is equivalent to how a VPN applies on the > operating system. > > System-wide configurations are meant to not interfere with critical > services that need to use the local network resolver. Captive network > interaction and cellular network services continue to use the resolver > configured by the local network. Similarly, if a VPN is active, the VPN > resolver takes precedence for whichever domains it handles. Note that VPN > providers can now indicate that an encrypted DNS resolver should be used > within the VPN tunnel as well. > > Since these system-wide configurations are based on a user opt-in, there > is no mechanism for a local network to disable them. If the connections a= re > blocked, resolution will fail rather than sending out in the clear. This = is > because these configurations are equivalent to using a VPN=E2=80=94they r= epresent a > security policy that the system enforces on behalf of the user. > > App opt-in: > ( > https://developer.apple.com/documentation/network/nwparameters/privacycon= text/3548851-requireencryptednameresolution > ) > An app can choose to opt into encrypted DNS for resolution within its > process. This is compatible with any system API that does name resolution= , > whether a connect-by-name API or in standard APIs like getaddrinfo(). > > The opt-in here is specifically about requiring that specific DNS > resolutions use some encrypted DNS protocol (DoH or DoT). Since many > devices at first won=E2=80=99t be using encrypted DNS, the app can provid= e a DNS > resolver config to use as a =E2=80=9Cfallback=E2=80=9D. This config indic= ates a DoH or DoT > server to use if and only if the resolution wouldn=E2=80=99t otherwise us= e DoH or > DoT. If there is a system-wide configuration, or a VPN configuration, or > automatic detection of DoH or DoT, then the app will use those resolvers > instead. > > It is important that applications can enable a policy to require encrypte= d > DNS without needing to rewrite their connection logic or adopt entirely > different APIs for name resolution. It is also important that as they > require encrypted DNS, they have a path forward to be compatible with use= r > preferences around DNS and mechanisms for automatic use of encrypted DNS. > If the efforts of ADD are successful in defining standard ways to make > encrypted DNS more universal, any app that adopts these APIs should be > ready. > > Automatic discovery: > > The iOS and macOS betas also start going down the road of automatic > discovery by implementing some of the mechanisms described in > https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00..html > . > I=E2=80=99m including the details below to explain any traffic you see be= ing > generated by these betas, and to explain how to interact with the system = if > you want to experiment. The system isn=E2=80=99t doing any automatic use = of > locally-hosted DoH/DoT servers at this point. > > Specifically, the system: > > - Starts sending out requests for HTTPS(HTTPSSVC) records along with A > and AAAA queries. This is currently using the testing RR type of 65479= . The > plan is to use the official allocation once that is made after the wir= e > format is finalized. It parses out a DoH URI template with a key value= of > 7. This value will also change to one in the correct > first-come-first-served range when we change RR type numbers. > - Relies on validating that a given zone allows designation to a DoH > server using the mechanism described in Section 3.3, Mutual Confirmati= on > with PvD JSON. > > Along with the client support, Apple is running a DoH server ( > https://doh.dns.apple.com/dns-query) for a very limited set of names > within apple.com. This is not a general-purpose DoH resolver, but one > that is only meant to be used as a designated resolver for Apple > properties. The configuration is at > https://doh.dns.apple.com/.well-known/pvd/dns-query, and the confirmation > is performed by checking https://apple.com/.well-known/pvd. > > If connections to the automatically discovered DoH resolvers fail, the > system currently fails over to use traditional DNS. > > If the user has selected a system-wide DoH resolver, that will take > precedence. However, any app opt-in prefers using the discovered resolver > to the app-provided resolver. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000592a1405a90aaf4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Tommy for providing more on the technical details b= ehind the implementation.
The implementation=C2=A0looks solid and will = take care of a lot of the edge cases (captive portal, administered device, = vpn, happy eyeball), lifting a lot from the application developpers.
There is one case that I did not see mentioned yet and I wonder if it is a= lready supported or if there is any plan in supporting/detecting it, which = is NAT64/DNS64.

Thanks!
Manu

On Fri, Jun 26, 2020 at 2:28 PM= Tommy Pauly <tpauly=3D40a= pple.com@dmarc.ietf.org> wrote:
Hello,

I want to sh= are some relevant updates with the ADD working group about encrypted DNS su= pport in iOS and macOS.

In the iOS 14 and macOS 11 betas, DoH an= d DoT are both natively supported by the system DNS resolvers. These are te= chnologies that many apps have already been using on iOS and macOS via VPN = provider APIs or by embedding application-specific DNS resolver code. Now t= hat these protocols are built into the operating system, these use cases ca= n move over to a system-provided path that provides greater efficiency and = tighter integration with built-in APIs that provide Happy Eyeballs and othe= r features.

These videos released as part of the Worldwide Devel= oper Conference cover details of how encrypted DNS can be used by app devel= opers:

Build trust through better privacy: https://developer.apple.com/videos/play/wwdc2020= /10676=C2=A0(Timestamps 11:55-13:50)

One of the key g= oals of integrating encrypted DNS into the operating system is ensuring tha= t when users get the privacy and security benefits of encrypted DNS, they d= on=E2=80=99t have to face breakages for key use cases that require interact= ion with local DNS providers and private/enterprise DNS servers. Beyond tha= t, the APIs are designed to make it easy to migrate to automatic use of enc= rypted DNS=E2=80=94the goal of the ADD working group.

=
To summari= ze the WWDC videos, there are three different ways that encrypted DNS is be= ing used in the iOS and macOS betas:
  1. Provide a s= ystem-wide encrypted DNS resolver selection, as an alternative to providing= a =E2=80=9CVPN=E2=80=9D configuration that just configures DNS
  2. Require enc= rypted DNS within an app (along with a resolver to prefer if no encrypted r= esolver is otherwise available), as an alternative to apps embedding their = own DNS resolution code
  3. Start autom= atically discovering designated resolvers for domains that advertise a DoH = URI
I=E2=80=99m including details for each of these three mechanisms below.<= /div>

Best,
Tommy



System-wide:
A system-wide DNS configuration can be provided either by a= n app that uses the NetworkExtension framework, or a configuration profile = that can be installed by the user or by an enterprise Mobile Device Managem= ent solution. These configurations can select an encrypted DNS server for a= ll domains or only a subset of domains; and can apply to all networks or a = subset of networks and network types.

System-wide configurations= require an explicit opt-in by a user through Settings, or configuration of= a managed device by an enterprise or similar organization. To this end, it= is equivalent to how a VPN applies on the operating system.
Sys= tem-wide configurations are meant to not interfere with critical services t= hat need to use the local network resolver. Captive network interaction and= cellular network services continue to use the resolver configured by the l= ocal network. Similarly, if a VPN is active, the VPN resolver takes precede= nce for whichever domains it handles. Note that VPN providers can now indic= ate that an encrypted DNS resolver should be used within the VPN tunnel as = well.

Since these system-wide configurations are based on a user= opt-in, there is no mechanism for a local network to disable them. If the = connections are blocked, resolution will fail rather than sending out in th= e clear. This is because these configurations are equivalent to using a VPN= =E2=80=94they represent a security policy that the system enforces on behal= f of the user.

App opt-in:
An app can cho= ose to opt into encrypted DNS for resolution within its process. This is co= mpatible with any system API that does name resolution, whether a connect-b= y-name API or in standard APIs like getaddrinfo().

The opt-in he= re is specifically about requiring that specific DNS resolutions use some e= ncrypted DNS protocol (DoH or DoT). Since many devices at first won=E2=80= =99t be using encrypted DNS, the app can provide a DNS resolver config to u= se as a =E2=80=9Cfallback=E2=80=9D. This config indicates a DoH or DoT serv= er to use if and only if the resolution wouldn=E2=80=99t otherwise use DoH = or DoT. If there is a system-wide configuration, or a VPN configuration, or= automatic detection of DoH or DoT, then the app will use those resolvers i= nstead.

It is important that applications can enable a policy to= require encrypted DNS without needing to rewrite their connection logic or= adopt entirely different APIs for name resolution. It is also important th= at as they require encrypted DNS, they have a path forward to be compatible= with user preferences around DNS and mechanisms for automatic use of encry= pted DNS. If the efforts of ADD are successful in defining standard ways to= make encrypted DNS more universal, any app that adopts these APIs should b= e ready.

Automatic discovery:

The iOS and macOS betas= also start going down the road of automatic discovery by implementing some= of the mechanisms described in https://tools.ietf.org/id/draft-pauly-add-resolver-disco= very-00..html. I=E2=80=99m including the details below to explai= n any traffic you see being generated by these betas, and to explain how to= interact with the system if you want to experiment. The system isn=E2=80= =99t doing any automatic use of locally-hosted DoH/DoT servers at this poin= t.

Specifically, the system:
  • Starts send= ing out requests for HTTPS(HTTPSSVC) records along with A and AAAA queries.= This is currently using the testing RR type of 65479. The plan is to use t= he official allocation once that is made after the wire format is finalized= . It parses out a DoH URI template with a key value of 7. This value will a= lso change to one in the correct first-come-first-served range when we chan= ge RR type numbers.
  • Relies on v= alidating that a given zone allows designation to a DoH server using the me= chanism described in Section 3.3, Mutual Confirmation with PvD JSON.
    • Along w= ith the client support, Apple is running a DoH server (https://doh.dns.apple.com/dns-query) for a very limited= set of names within apple.com. This is not a general-= purpose DoH resolver, but one that is only meant to be used as a designated= resolver for Apple properties. The configuration is at https://doh.dns.apple.com/.well-known/pvd/dns-que= ry, and the confirmation is performed by checking https://apple.com/.well-known/pvd.

    =
    If c= onnections to the automatically discovered DoH resolvers fail, the system c= urrently fails over to use traditional DNS.

    If the user has sele= cted a system-wide DoH resolver, that will take precedence. However, any ap= p opt-in prefers using the discovered resolver to the app-provided resolver= .

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000592a1405a90aaf4c--