IETF Logo Mail Archive

[Doh] Use cases and URLs

Paul Hoffman <paul.hoffman@icann.org> Wed, 07 March 2018 03:49 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 1AC4C126CC7 for <doh@ietfa.amsl.com>; Tue, 6 Mar 2018 19:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 r1d-l4Ofg5Fz for <doh@ietfa.amsl.com>; Tue, 6 Mar 2018 19:49:28 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFF1124BE8 for <doh@ietf.org>; Tue, 6 Mar 2018 19:49:28 -0800 (PST)
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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 6 Mar 2018 19:49:26 -0800
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.1178.000; Tue, 6 Mar 2018 19:49:26 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: "doh@ietf.org" <doh@ietf.org>
Thread-Topic: Use cases and URLs
Thread-Index: AQHTtcdJ6G4jKxcbnU6n6Up2z3ylaw==
Date: Wed, 07 Mar 2018 03:49:26 +0000
Message-ID: <24DEFAAB-D2A3-45E5-8CEE-E2E4EA23B9C2@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25ED1C188F34724EBF7C31B163980C15@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/vEEENBAPNI33oC0ODTQCZL9hWUc>
Subject: [Doh] Use cases and URLs
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 07 Mar 2018 03:49:30 -0000

Greetings again. In the discussions in the last month since draft-ietf-doh-dns-over-https-03 came out, particularly at the DNS Privacy Workshop at NDSS, it has become clear that there are a lot of use cases that are related to the two given in Section 3 of the draft, but are not called out explicitly. They fall under the sentence "They might use the DOH server for all queries, or only for a subset of them."

Some that I have heard are (approximately):

- Use the preferred DNS API server for all DNS lookups in the browser whenever the browser is running (start the TLS session with the DNS API when the browser starts).

- If a tab/window for the origin of a configured DNS API server is open, use the configured API server for all DNS lookups.

- If a tab/window for the origin of a configured DNS API server is open, use the configured API server for DNS lookups that are in that origin only.

- If a tab/window for the origin of a configured DNS API server is open, and the configured API server pushes DNS information, accept it.

(Note that you might like or dislike some of these; that's fine.)

In addition, there has been the assumption by many people that they could add new DNS API servers to the list of configured servers in the browser based on various out-of-band information (articles, word-of-mouth, ...). That is, people want the additional DNS privacy through a somewhat-trusted web site rather than no privacy from the who-knows-where they are getting now. (Don't forget that the vast, vast majority of users are doing DNS lookups using resolvers they have no idea about.)

The ability to add new DNS APIs servers leads to the question of the URL being used for a particular DNS API server. In early drafts, we used "https://<origin>/.well-known/dns-query?..." as the standard URL, but it was pointed out that such a standard is prohibited by RFC 5785. The current draft says that there is no standard, and every origin will have its own URL for the API. This makes it much harder for a user to add new configured DNS API servers and thus reduces the chance that some of their DNS queries will be private, based on which of the use cases get implemented.

A protocol point between "here is the fixed URL" and "every origin has its own URL" is "discover the policy for an origin to serve as a DNS API server". That is, use the RFC 5785 ".well-known" scheme as a way to find out what the origin's policy is. That way, a user can configure new servers in their browser only knowing the origin name (which is all they really understand anyway...).

A first guess of a proposal would be that "https://<origin>/.well-known/dns-query/" returns a JSON object that looks like:
   { "has-DNS-API": true, "DNS-API-URLs":
      [ "https://<origin>/admin-dns/?", "https://<origin>/backup-dns/?" ] }

This uses the .well-known for what it is supposed to be used for, and gives each origin a chance to pick their own URL scheme. Getting no response or "{ "has-DNS-API": false }" both tell the user that origin's policy as well, of course.

Thoughts?

--Paul Hoffman

v2.23.0 | Report a Bug | By Email