Re: [Doh] DOH and Induced DNS

Adam Roach <adam@nostrum.com> Mon, 06 November 2017 23:39 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 C1B1E13FB59 for <doh@ietfa.amsl.com>; Mon, 6 Nov 2017 15:39:46 -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 WYdVBXDlDGfB for <doh@ietfa.amsl.com>; Mon, 6 Nov 2017 15:39:45 -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 22A0713F698 for <doh@ietf.org>; Mon, 6 Nov 2017 15:39:44 -0800 (PST)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA6Ndg1i041193 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Nov 2017 17:39:43 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Mark Nottingham <mnot@mnot.net>, dagon <dagon@sudo.sh>
Cc: doh@ietf.org
References: <20171106170750.GA24665@sudo.sh> <C93D011F-68D3-4B21-BB37-4ABF10488372@mnot.net>
From: Adam Roach <adam@nostrum.com>
Message-ID: <73c2dac6-b3bb-c9f7-4710-e1c3750b50f8@nostrum.com>
Date: Mon, 6 Nov 2017 17:39:42 -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: <C93D011F-68D3-4B21-BB37-4ABF10488372@mnot.net>
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/BEEZ6vStoeY0ZtHot0lEKklYkFw>
Subject: Re: [Doh] DOH and Induced DNS
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 23:39:47 -0000

On 11/6/17 5:32 PM, Mark Nottingham wrote:
>
>> On 7 Nov 2017, at 4:07 am, dagon <dagon@sudo.sh> wrote:
>>
>>   c) Header-only?  If we assume implementation mistakes will always
>> occur in DOH stubs and recursives, perhaps the wire encoding should
>> appear only in HTTP headers, since these are less easily manipulated
>> by crafted javascript and HTML.  At the same time, the headers are
>> presumably within reach of the stub.  Header fields seem more likely
>> to reflect browser user decisions, and not the HTML author's malicious
>> whims.  (At least the problem would only be as bad as DNS prefetch, in
>> terms of volume.)
> It's trivial for scripts to modify headers, EXCEPT those starting with Sec-:
>    https://fetch.spec.whatwg.org/#forbidden-header-name
>
> If this is a concern, it might be workable to define a header that looks something like:
>
> Sec-Doh: 1
>
> to indicate that the request was generated by the browser / client internals, not script.

If the notion here is to prevent JS-initiated queries, I'll point out 
that this is explicitly prohibited by the working group charter: "While 
access to DNS-over-HTTPS servers from JavaScript running in a typical 
web browser is not the primary use case for this work, precluding the 
ability to do so would require additional preventative design. The 
working group will not engage in such preventative design."

/a