Re: [Doh] [Ext] Associating a DoH server with a resolver

Paul Hoffman <paul.hoffman@icann.org> Thu, 25 October 2018 14:57 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613B8130E5A for <doh@ietfa.amsl.com>; Thu, 25 Oct 2018 07:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 Fgm0OJ6buul9 for <doh@ietfa.amsl.com>; Thu, 25 Oct 2018 07:57:12 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13938130E69 for <doh@ietf.org>; Thu, 25 Oct 2018 07:57:12 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 25 Oct 2018 07:57:09 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Thu, 25 Oct 2018 07:57:09 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: DoH WG <doh@ietf.org>
Thread-Topic: [Ext] [Doh] Associating a DoH server with a resolver
Thread-Index: AQHUbHMAS2WH9fYpIkSbfmTvqNJTAg==
Date: Thu, 25 Oct 2018 14:57:09 +0000
Message-ID: <9232174A-E543-40BA-8293-9682FC412D30@icann.org>
References: <02C39DFD-9550-447D-B00E-702B441A88BE@icann.org> <CAHbrMsCg61hQs2+yZk2Cyrn5VSAR--=sXaUNhH+7Wgp+6zBG=Q@mail.gmail.com>
In-Reply-To: <CAHbrMsCg61hQs2+yZk2Cyrn5VSAR--=sXaUNhH+7Wgp+6zBG=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_8E298BAB-67BC-4AF7-9504-795BFBBBA9C1"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/0QLQ9DXP-QgZsdaOI7uhST7UUcI>
Subject: Re: [Doh] [Ext] Associating a DoH server with a resolver
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2018 14:57:14 -0000

Sorry for the belated reply to this. Gotta love corporate mail systems...


On Oct 23, 2018, at 2:05 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> Hi Paul, thanks for the continuing work on this topic.
> 
> Two related questions:
> 1. Does the resolver have to return its own IP in the RR for resolver-addresses.arpa, or can it return some other IP addresses?

The current wording is that the resolver returns its own IP address, which makes the resolver operator responsible for running the service that will respond to the well-known URI. There is no expectation that the URI templates returned from the well-known URI will all point to that same resolver; it would be find for the resolver operator to point to trusted third-party services.

> 2. If a client has some OS-specific way to enumerate the DNS server IPs for the default network interface, is it still required to perform "Step 1"?  (Most OSes do have some enumeration mechanism like this.)

Good point; I'll add this to the next draft and say "no". I'll also say "if the application can enumerate the OS's preferred DoH servers, there is no need to use the protocol here at all".

> Other minor comments:
> On Section 4, User Interface: I don't see the need for a user interface here.  In my view, opportunistic security generally shouldn't require user action and shouldn't produce a user-visible change.

Browser vendors might prefer that, privacy-concerned users might want a UI. I guess I'm targeting the latter.

> I think interaction with DoT is worth discussing here, even though it's probably trivial.  If I can probe for DoT and (with this draft) DoH, which one do I probe first, and which should I prefer if both succeed?

Yes, I'll add a stub for discussion of this.

--Paul Hoffman