[Add] Encrypted DNS support in iOS and macOS

Tommy Pauly <tpauly@apple.com> Fri, 26 June 2020 21:28 UTC

Return-Path: <tpauly@apple.com>
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 <add@ietfa.amsl.com>; 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 <add@ietfa.amsl.com>; 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 <add@ietf.org>; 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 <add@ietf.org>; 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 <add@ietf.org>; 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 <tpauly@apple.com>
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 <add@ietf.org>
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: <https://mailarchive.ietf.org/arch/msg/add/MbOOWPVHRHM_wvbKhfHuzUTwimI>
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 <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2020 21:28:47 -0000

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 <https://developer.apple.com/videos/play/wwdc2020/10676> (Timestamps 11:55-13:50)
Enable encrypted DNS: https://developer.apple.com/videos/play/wwdc2020/10047/ <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’t 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—the 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 “VPN” 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’m 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/networkextension/dns_settings>)
(https://developer.apple.com/documentation/devicemanagement/dnssettings <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—they 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 <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’t be using encrypted DNS, the app can provide a DNS resolver config to use as a “fallback”. This config indicates a DoH or DoT server to use if and only if the resolution wouldn’t 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 <https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html>. I’m 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’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 <https://doh.dns.apple.com/dns-query>) for a very limited set of names within apple.com <http://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 <https://doh.dns.apple.com/.well-known/pvd/dns-query>, and the confirmation is performed by checking https://apple.com/.well-known/pvd <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.