Re: [Add] Encrypted DNS support in iOS and macOS

Tommy Pauly <tpauly@apple.com> Sat, 27 June 2020 15:36 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 C94433A079D for <add@ietfa.amsl.com>; Sat, 27 Jun 2020 08:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, MIME_QP_LONG_LINE=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 tDiF7uwr6m0Z for <add@ietfa.amsl.com>; Sat, 27 Jun 2020 08:35:59 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 6A6BF3A0795 for <add@ietf.org>; Sat, 27 Jun 2020 08:35:59 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05RFZWYV014340; Sat, 27 Jun 2020 08:35:57 -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=MtWyXaH42FK1IrVtGtQRitQ0pEy+Mcfl0xmEiznpS9o=; b=wQ0X/mV0GIEWPWk/2mf+5OdR9BOPoXTlJ2k/7BRSjfzr/ziOVCJX7vUZu93n2+FWXs+u wSOWO9O4p6xaeU4tdU2jRVjx3nT0y1XxijpQ5QjOypRYf2vyrMghFbA1EeBsTGFhB2m2 Lesa4toHXAHLRWfjktrTl8AuuAFMLmV8wZQITokTUCp+vQAKa4v562gC9ZpdMAqDWaC4 fuyRX1doITGz137D7nzehT/TmxTrvwK9kgTTSyThdD0vrLnC33IyCUOB6sLbhL0XQdlX NWdFtD0rT85mLwzTnT3CxnkJwgb1CBY45U52S1wJj+P0HORYJy1IPdY6YnMz5GcLB6nd VA==
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 31x53ub16e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 27 Jun 2020 08:35:57 -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-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCL00ZLXCNX9S30@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sat, 27 Jun 2020 08:35:57 -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.5.20200312 64bit (built Mar 12 2020)) id <0QCL00Z00BQSDK00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 27 Jun 2020 08:35:57 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 40c73510d5f02ab596d60751b7a5285e
X-Va-E-CD: 8d219af0f322673eb814e7f9156c80e8
X-Va-R-CD: 414100da242e1445641903909a2349ad
X-Va-CD: 0
X-Va-ID: 20b4d244-6814-4c1b-804c-c4ec6e4931e3
X-V-A:
X-V-T-CD: 40c73510d5f02ab596d60751b7a5285e
X-V-E-CD: 8d219af0f322673eb814e7f9156c80e8
X-V-R-CD: 414100da242e1445641903909a2349ad
X-V-CD: 0
X-V-ID: fd43ccce-51fb-4154-9e4c-6d0385b129eb
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_05:2020-06-26, 2020-06-27 signatures=0
Received: from [10.104.236.129] (unknown [10.104.236.129]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QCL00M74CNUEZ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sat, 27 Jun 2020 08:35:55 -0700 (PDT)
Content-type: multipart/alternative; boundary=Apple-Mail-F013FEE7-9DD2-4FBE-98B6-73A447C00978
Content-transfer-encoding: 7bit
From: Tommy Pauly <tpauly@apple.com>
MIME-version: 1.0 (1.0)
Date: Sat, 27 Jun 2020 08:35:53 -0700
Message-id: <B2CF15E9-0D5E-4D8E-A3F3-05A0CADFFEF2@apple.com>
References: <CAArYzrLmkpgjgn_HRCSVH4a5w68Wzu=QcyQyiK7HTjcNbKyxWA@mail.gmail.com>
Cc: ADD Mailing list <add@ietf.org>
In-reply-to: <CAArYzrLmkpgjgn_HRCSVH4a5w68Wzu=QcyQyiK7HTjcNbKyxWA@mail.gmail.com>
To: Manu Bretelle <chantr4@gmail.com>
X-Mailer: iPhone Mail (18A316a)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_05:2020-06-26, 2020-06-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/mJ6plnQGJP5RIOa47AQUoAYtmxE>
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 <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: Sat, 27 Jun 2020 15:36:02 -0000


> On Jun 26, 2020, at 11:11 PM, Manu Bretelle <chantr4@gmail.com> wrote:
> 
> 
> 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.

Good point, I should have mentioned this! When the local network is NAT64, we will still request A and AAAA from any DoH/DoT server, and if we get only A answers, we synthesize an IPv6 address using the NAT64 prefix before using it. 

Thanks,
Tommy
> 
> Thanks!
> Manu
> 
>> On Fri, Jun 26, 2020 at 2:28 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> 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 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’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/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)
>> 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. 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) 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