Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers

Tommy Pauly <tpauly@apple.com> Fri, 26 June 2020 21:46 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 11DB73A0CCE for <add@ietfa.amsl.com>; Fri, 26 Jun 2020 14:46:22 -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 rLu8I_XUjpcV for <add@ietfa.amsl.com>; Fri, 26 Jun 2020 14:46:20 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 76E1E3A0CCD for <add@ietf.org>; Fri, 26 Jun 2020 14:46:20 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 05QLaJ44028609; Fri, 26 Jun 2020 14:46:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=TEcli7rBfUw7dyb5x+h7pzk9JncVObDXdaeiR9UVg5M=; b=X0J6BXbX1RIpx1YCSNLftYEVc7OH+7FeRMnT7U/t75MulL5B14xglRwLIxtb8ECSaLe3 atTskXB0e3e52/srVJlzLVQlDZwOYSO0VNgOqyjCMlYhPXdyR/6QXEbxPKbqea1AtfKe 3qtZQvYgzso5gULONDZJsTJ5/zPOy6SOHxFveetKEGOUwLALHQNjfgc6g7ty93vThQM1 rjBQpN4w1p/2cVJMzl5MrziyT7fIRswVMKrLAHcUtawLe/s11iaUJqJLzGbrvM3uxoxX TkLjohNvFqTyUq0q5rdkINtumNXjUWCLVc3R+4svZxPESG/nw6ZdCfIkYq/rW9wnp3N5 5g==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp01.apple.com with ESMTP id 31uut6ke8q-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 Jun 2020 14:46:20 -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-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QCJ00SXTZ57YJ70@rn-mailsvcp-mta-lapp01.rno.apple.com>; Fri, 26 Jun 2020 14:46:19 -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 <0QCJ00Z00YZZA100@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 26 Jun 2020 14:46:19 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 1682cb633e8834c32dfc165e32ca8e8d
X-Va-E-CD: e62e75a901ccfe6f540d297acf2a8a70
X-Va-R-CD: 058881bde0e11f2926a580f2a100d551
X-Va-CD: 0
X-Va-ID: a9a53d7c-7114-4c8a-9c96-3ad2d1b31832
X-V-A:
X-V-T-CD: 1682cb633e8834c32dfc165e32ca8e8d
X-V-E-CD: e62e75a901ccfe6f540d297acf2a8a70
X-V-R-CD: 058881bde0e11f2926a580f2a100d551
X-V-CD: 0
X-V-ID: 3548e422-3082-4d27-8bc3-f9bff59a65de
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 <0QCJ00GIJZ56LG00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 26 Jun 2020 14:46:19 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\))
Date: Fri, 26 Jun 2020 14:46:18 -0700
In-reply-to: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com>
Cc: ADD Mailing list <add@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com>
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/YMTrjq9pGVk-1xheLty0Wds36kQ>
Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers
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:46:22 -0000

Hi Ekr,

Thanks for sharing this draft. Very exciting to see this step forward in supporting the automatic use of DoH.

Regarding the choice of using DNS + CNAME, I completely understand and sympathize with the practical deployment aspects. Going forward, I’d like to see if collectively we can use a record that gives a full DoH URI. Your draft does reference the option of using HTTPS RRs for this, as Tommy Jensen has proposed in https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti <https://tools.ietf.org/id/draft-pauly-add-resolver-discovery-00.html#name-discovery-of-doh-capabiliti>.

In my email to this list just a bit ago, I mentioned that we’re starting to request these RR types (well, the older version for HTTPSSVC, but will be updated) on the iOS and macOS betas. Hopefully we can measure based on that how much RRType interference exists in networks. I’d be curious to hear what kinds of measurements the Mozilla team is taking in this space, as you are able to share.

I’d also be interested to have a discussion here about the acceptable ranges for breakage. Certainly, if the percentage of home wifi setups that fails with a new RRType is very high, it’s a problem. However, if the percentage is lower but still significant (say, 5%?), we can consider the tradeoff of solutions. Intolerance to passing unknown RRTypes is one way that this could break; however, there are many other ways a local wifi router could potentially interfere. For example, a wifi router might not recurse to the ISP's DNS resolver, but some other resolver (which if it is 1.1.1.1 or 8.8.8.8 would support DoH, but could be something else that doesn’t). There will always be *some* tail of networks that won’t work, even with the CNAME approach; and I’d like to see a long-term solution that allows for richer information than just a hostname. Thoughts?

Best,
Tommy

> On Jun 25, 2020, at 7:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Hi folks,
> 
> As has been noted previously, the current Firefox DoH/TRR design
> bypasses the ISP resolver even if the ISP resolver supports DoH.
> 
> I have just posted draft-rescorla-doh-cdisco-00, which describes a
> CNAME-based mechanism for discovering when a local resolver supports
> DoH/TRR. Firefox can then determine whether that resolver is on the
> TRR list and if so can use it in preference to generic resolver.. The
> use of CNAME was chosen for pragmatic reasons (laid out in the draft).
> We're studying other designs but thought it would be a good idea
> to document this one.
> 
> See: https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt <https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt>
> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add