[Doh] Use Cases

Mark Nottingham <mnot@mnot.net> Thu, 16 November 2017 07:53 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 85E25126DEE for <doh@ietfa.amsl.com>; Wed, 15 Nov 2017 23:53:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nTnVM6Oi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AxDJ/BFM
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pyYL5H1PGglK for <doh@ietfa.amsl.com>; Wed, 15 Nov 2017 23:53:16 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC89A120724 for <doh@ietf.org>; Wed, 15 Nov 2017 23:53:15 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2253B21627 for <doh@ietf.org>; Thu, 16 Nov 2017 02:53:15 -0500 (EST)
Received: from frontend1 ([]) by compute3.internal (MEProxy); Thu, 16 Nov 2017 02:53:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=rSkVUHYtmQ8ML4qjA6Pkp4sytDH+elQq2nyTK/R8GXM=; b=nTnVM6Oi JdIV9AOE9SN88Uq7gF438ThooKrXULEXbjSQAysG9OnK2QsGKVS3UCPahMG4UP6o JCZvIAM+ih9deuSxejBRAzwjdsuzh4CRI6lO25dVNbjGPCp2PExIOw9QQAOM1AEp T+JyzxajCLUKtPQqiigXPYDjpmh4JjCx9RW8zdHjepob4Y5TEvE7omOjMHwr4zPn GthrVQ0MGgfImk9ULNlWm4Fu/SOq1Byj5xB0fAkpnM6ztNXSAmjEk6wvncARVsHf 9wwbIAZcdt2fC9tbsJYus910Z0t0+20N9ky5Mx50k/XYkHNnLWzXRaIOV0k/rvB3 BpdI8qGVg+Bbvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=rSkVUHYtmQ8ML4qjA6Pkp4sytDH+e lQq2nyTK/R8GXM=; b=AxDJ/BFMycghv928e4jGainHsOmdvizVKK7wvhIBzFPf1 5rccq5LayAEAxwE0eo746wpZ3+kSWVdPmb4sE5YAXmb+C6LNCYL6nH3HEIcbuXwm 4YCa5PLPZF7/J63+h7EzE+1pJwFfdj+iHaAKQgVwyOaOvicMizCtjraflhiPZ9yY lw0iJrFpildIzZjxY0/uSR8HlCyQBzOWX+UhW2p9XQV3Pl/h/ZQS+xciAFxAoLL4 YvFZ+qgyiWndmAxjfuw3GtMrzYth+GlxGXDmckbBQrOwqQHv7Z8KZGnufGTdfyay 3/6IVsCG2mQdqRcXVo5sAExh2P7d3tBMUewrA/pkA==
X-ME-Sender: <xms:60MNWqSEEvr2xwTy1QB1ZSXKl6ocbS7DaxfnTAQrwAxo1JuLTtwP8Q>
Received: from dhcp-92b4.meeting.ietf.org (dhcp-92b4.meeting.ietf.org []) by mail.messagingengine.com (Postfix) with ESMTPA id 4A6A37FACF for <doh@ietf.org>; Thu, 16 Nov 2017 02:53:13 -0500 (EST)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Message-Id: <6D59C17D-06AC-4000-8780-CEA4DEC3D217@mnot.net>
Date: Thu, 16 Nov 2017 15:53:59 +0800
To: doh@ietf.org
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/39NvsLeQVDLB1VXgjnUDWVckhU4>
Subject: [Doh] Use Cases
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: Thu, 16 Nov 2017 07:53:18 -0000

In the meeting, I said that it might be helpful to have an explicitly defined use case. Paul mentioned the document already covers this:

3.  Use Cases

   There are two primary use cases for this protocol.

   The primary use case is to prevent on-path network devices from
   interfering with native DNS operations.  This interference includes,
   but is not limited to, spoofing DNS responses, blocking DNS requests,
   and tracking.  HTTP authentication and proxy friendliness are
   expected to make this protocol function in some environments where
   unsecured DNS ([DNS]) or DNS directly on TLS ([RFC7858]) would not.

   A secondary use case is web applications that want to access DNS
   information.  Standardizing an HTTPS mechanism allows this to be done
   in a way consistent with the cross-origin resource sharing security
   model of the web [CORS] and also integrate the caching mechanisms of
   DNS with those of HTTP.  These applications may be interested in
   using a different media type than traditional clients.

That speaks to the motivations, but not how it will actually be achieved using this protocol. I suggest:

3. Use Cases

There are two initial use cases for this protocol.

The primary use case is to prevent on-path network devices from interfering with DNS operations. This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking. 

In this use, clients -- whether operating systems or individual applications -- will be explicitly configured to use a DOH server as a recursive resolver by its user (or administrator). They might use the DOH server for all queries, or only for a subset of them. The specific configuration mechanism is out of scope for this document.

A secondary use case is allowing web applications to access DNS information, by using existing APIs in browsers to access it over HTTP. 

This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its content), but standardisation might make this easier to accomplish. 

Note that in this second use, the browser does not consult the DOH server or use its responses for any DNS lookups outside the scope of the application using them; i.e., there is (currently) no API that allows a Web site to poison DNS for others.

Mark Nottingham   https://www.mnot.net/