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 E44873A0CA0 for ; Fri, 26 Jun 2020 14:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=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 a8OOtPFnVY62 for ; Fri, 26 Jun 2020 14:28:43 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 87F7A3A0C9F for ; Fri, 26 Jun 2020 14:28:43 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05QLJiY2021158 for ; Fri, 26 Jun 2020 14:28:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=wwE1jOG1zf8Ty7UnIvq3tCA6uT9Ch9AQeqMUQc4j9bA=; b=JjZ2T04O2a5yyJ6292xA0bNL5WHJAO51gNUrr45weNqWXSP15W/9boD/QFkfwC7+vzR4 kufJQ91ImCAidplltdtyDwmAbl8WkEwhvAm6Irm1+YsTB7SSiDUv1BM7ike91rPOcOXS NzS2XnK1jXPe7JFdJ+ucKedcXj4rTRw9gbiaXudA/PYGQ7GgcmHrbAPstBuMYPcXA7Xe r1eTxCHKhv+c3W0LG4lbFR2RgnE2mbp/G/pkA/Of9FMSZkkXSQGG7pC42SAOH3njkLSF 2eqZ84dqNqEFLjB5nOeOrbj4BfuHTlXqUXDIIgbZ8kHY1mnCMBLh20En7bim2wr9DY0Z +g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 31uurxu9st-21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 26 Jun 2020 14:28:41 -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-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCJ00L36YBTD0H0@rn-mailsvcp-mta-lapp03.rno.apple.com> for add@ietf.org; Fri, 26 Jun 2020 14:28:41 -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.5.20200312 64bit (built Mar 12 2020)) id <0QCJ00P00Y75PV00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for add@ietf.org; Fri, 26 Jun 2020 14:28:41 -0700 (PDT) X-Va-A: X-Va-T-CD: 5daaeb935bbe0e8d25090cf6b04f92b4 X-Va-E-CD: c10540ee026d34ce700dbe4e87c40fd4 X-Va-R-CD: b9c8a414f1e97e5ac01914532a054dbe X-Va-CD: 0 X-Va-ID: cddb7cf6-e8b1-447f-b2eb-c4fa311e50c1 X-V-A: X-V-T-CD: 5daaeb935bbe0e8d25090cf6b04f92b4 X-V-E-CD: c10540ee026d34ce700dbe4e87c40fd4 X-V-R-CD: b9c8a414f1e97e5ac01914532a054dbe X-V-CD: 0 X-V-ID: 581553de-194d-484e-914d-a8744d08c19c X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 Received: from [17.234.81.96] (unknown [17.234.81.96]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QCJ009EWYBSK300@rn-mailsvcp-mmp-lapp02.rno.apple.com> for add@ietf.org; Fri, 26 Jun 2020 14:28:41 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Message-id: <637E7D0A-AF96-4D7D-B7CB-69E04F995F6F@apple.com> Date: Fri, 26 Jun 2020 14:28:40 -0700 To: ADD Mailing list X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 Archived-At: Subject: [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: Fri, 26 Jun 2020 21:28:47 -0000 --Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 built 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 = cases 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: Provide a system-wide encrypted DNS resolver selection, as an = alternative to providing a =E2=80=9CVPN=E2=80=9D configuration that just = configures DNS Require encrypted DNS within an app (along with a resolver to prefer if = no encrypted resolver is otherwise available), as an alternative to apps = embedding their own DNS resolution code 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 = uses 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 = similar 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 = are 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 represent 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 = provide a DNS resolver config to use as a =E2=80=9Cfallback=E2=80=9D. = This config indicates a DoH or DoT server 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 instead. 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 that = as they require encrypted DNS, they have a path forward to be compatible = with user 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 = 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 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 wire = 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 Confirmation = 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. --Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 built 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)

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 cases 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 just = configures DNS
  2. Require encrypted DNS within an app (along with a resolver to = prefer if no encrypted resolver is otherwise available), as an = alternative 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/dnss= ettings)
A system-wide DNS configuration = can be provided either by an app that uses 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 similar 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 are 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 represent a security policy that the system = enforces on behalf of the user.

App opt-in:
(https://developer.apple.com/documentation/network/nwparameters/= privacycontext/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 provide a DNS resolver config to use as a = =E2=80=9Cfallback=E2=80=9D. This config indicates a DoH or DoT server 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 = instead.

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 that as they require encrypted DNS, = they have a path forward to be compatible with user 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 being generated by these betas, and to explain how to = interact with the system if you want to experiment. The system isn=E2=80=99= t 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 wire 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 = Confirmation 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.

= --Apple-Mail=_AF7AFC73-4664-46B2-963A-2BD54B737F6B--