IETF Logo Mail Archive

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

Adam Roach <adam@nostrum.com> Mon, 06 November 2017 06:16 UTC

Return-Path: <adam@nostrum.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 058A613FB2D for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 22:16:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 r_tCvgIKYMTx for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 22:16:46 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB86B13FB24 for <doh@ietf.org>; Sun, 5 Nov 2017 22:16:46 -0800 (PST)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA66Gim4026485 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 00:16:45 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: "doh@ietf.org" <doh@ietf.org>
References: <78BA4BE2-1475-4F36-B735-FF6EAF0B594B@vpnc.org> <459AFD25-B3FB-4FD2-A688-2380CB0AC6D3@icann.org> <76b12c4d-dbd5-d5bb-9c68-6b36b280f0ae@cisco.com> <CE272411-48EE-4614-BD86-ABD5BBE32089@icann.org> <0208f6a7-f9a7-ade5-2eac-18de4d678116@nostrum.com> <B3A9EF7A-A81A-4134-A79B-CE71343B6D0A@icann.org>
From: Adam Roach <adam@nostrum.com>
Message-ID: <f3ba8776-3135-88b8-638a-66d7992c4269@nostrum.com>
Date: Mon, 06 Nov 2017 00:16:39 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <B3A9EF7A-A81A-4134-A79B-CE71343B6D0A@icann.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/PfuF-0YZxO8W77202QIqh9Yk5_k>
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: Mon, 06 Nov 2017 06:16:48 -0000

On 11/5/17 13:58, Paul Hoffman wrote:
> On Nov 5, 2017, at 11:48 AM, Adam Roach <adam@nostrum.com> wrote:
>>> It sounds like the operational document might say something like "an enterprise that cares about which DNS resolver its users access needs to also make that policy in DOH-enabled web clients".
>> s/web clients/DNS clients/, right?
> Maybe?
>
>> I don't get the impression that the use cases are intended to be restricted to web browsers as clients.
> They are not restricted to web clients (I was careful not to say "browsers"), but I don't expect current DNS clients to add DOH capabilities any time in the near future. We have had approximately zero success in getting stub resolvers deployed with DNS-over-TLS (RFC 7858), and getting them to do that would be easier than DNS-encoded-in-HTTP-over-TLS. DNS clients are a use case listed in Section 3 of the draft, but not one that we've heard much interest in.

Right. And if we're talking about text that we're planning to add to 
documents that will be published as RFCs, I think we'd want them to be 
valid for a pretty long period of time, rather than just for "the near 
future."

/a

v2.23.0 | Report a Bug | By Email