Re: [Doh] [Ext] DOH bypassing protection mechanisms

Eliot Lear <lear@cisco.com> Sun, 05 November 2017 16:29 UTC

Return-Path: <lear@cisco.com>
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 183F013FC80 for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 08:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1tK18Ejr837G for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 08:29:30 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D25513F6BC for <doh@ietf.org>; Sun, 5 Nov 2017 08:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1509899370; x=1511108970; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=f+UWN8HKfpULO9aE2j5yUWyHS+aMiGGAXuKmfAwzSJI=; b=aDorG5BmhKqaC3ALlzdFh0CDQ3gkTOZaqr+MuSy9S6PmjLGWhSP/jg1u yfynqWUxtchGF1jl6MifBdtmXmBy1rNekrSYiB4iYn549GZ8R485D3XSe jAuIULbgXfqOLl4gUMnHGIUyn0XhbGlfwMU3PdDt6bi4MThUMOiqNkYnA M=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQAXO/9Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIsTkCGWRoIRBwOFOwKFGBYBAQEBAQEBAQFrKIUfAQUjZgs?= =?us-ascii?q?YKgICVwYBDAgBAYofqXKCJ4sDAQEBAQEBBAEBAQEBAQESD4MuhWyDAYR7gyuCY?= =?us-ascii?q?gWiDoRCgiOOF4F8iXyHPJYWgTkmCCmBbDQhCB0Vgy6EX0CMKgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,348,1505779200"; d="asc'?scan'208";a="80680"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2017 16:29:28 +0000
Received: from [10.61.199.115] ([10.61.199.115]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA5GTRvZ012825; Sun, 5 Nov 2017 16:29:28 GMT
To: Paul Hoffman <paul.hoffman@icann.org>, "doh@ietf.org" <doh@ietf.org>
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>
From: Eliot Lear <lear@cisco.com>
Message-ID: <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com>
Date: Sun, 5 Nov 2017 17:29:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bMH5GoWk9rBhVhfBoH30joXNmc9twtNkn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/58K0MZkF7t3M42A41RkIrioEEDQ>
Subject: Re: [Doh] [Ext] DOH bypassing protection mechanisms
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: Sun, 05 Nov 2017 16:29:32 -0000


On 11/5/17 4:57 PM, Paul Hoffman wrote:
> As to Eliot's main question: The policy to choose a DOH server is similar to the policy to choose a DNS resolver, it's just done in a different application. For the latter, the typical is "trust whatever DHCP tells you", but there are also commonly policies of "ignore DHCP, always use one of these". Both those policies could be mirrored in a browser for DOH.
>

That's the theory.  In reality, for the enterprise, you would be hard
pressed to find examples in which the enterprise itself doesn't control
where a query goes on a client (DHCP is not the only control function).

Eliot