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 11DB73A0CCE for ; 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 ; 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 ; 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 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: Cc: ADD Mailing list To: Eric Rescorla References: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 21:46:22 -0000 --Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99= 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 = . In my email to this list just a bit ago, I mentioned that we=E2=80=99re = 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=E2=80=99d be curious to hear what kinds of measurements the = Mozilla team is taking in this space, as you are able to share. I=E2=80=99d 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=E2=80=99s 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=E2=80=99t). There will = always be *some* tail of networks that won=E2=80=99t work, even with the = CNAME approach; and I=E2=80=99d 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 wrote: >=20 > Hi folks, >=20 > As has been noted previously, the current Firefox DoH/TRR design > bypasses the ISP resolver even if the ISP resolver supports DoH. >=20 > 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. >=20 > See: = https://www.ietf.org/internet-drafts/draft-rescorla-doh-cdisco-00.txt = >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99d 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.

In my email to this list just a bit = ago, I mentioned that we=E2=80=99re 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=E2=80=99d be curious to hear what = kinds of measurements the Mozilla team is taking in this space, as you = are able to share.

I=E2=80=99d 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=E2=80=99= 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=E2=80=99t). There will = always be *some* tail of networks that won=E2=80=99t work, even with the = CNAME approach; and I=E2=80=99d 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

-Ekr







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

= --Apple-Mail=_812D50F8-DA17-4557-B434-C2605008FE2E--