Re: [Doh] DOH and Induced DNS

Mark Nottingham <mnot@mnot.net> Mon, 06 November 2017 23:32 UTC

Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <20171106170750.GA24665@sudo.sh>
Date: Tue, 07 Nov 2017 10:32:52 +1100
Cc: doh@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C93D011F-68D3-4B21-BB37-4ABF10488372@mnot.net>
References: <20171106170750.GA24665@sudo.sh>
To: dagon <dagon@sudo.sh>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/o15MNjY-gk7EDz6BGSyrYNLO1Ao>
Subject: Re: [Doh] DOH and Induced DNS
Precedence: list


> 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.

Cheers,

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

[Doh] DOH and Induced DNS dagon
Re: [Doh] DOH and Induced DNS Adam Roach
Re: [Doh] DOH and Induced DNS Mark Nottingham
Re: [Doh] DOH and Induced DNS Adam Roach
Re: [Doh] DOH and Induced DNS Mark Nottingham
Re: [Doh] DOH and Induced DNS Adam Roach
Re: [Doh] DOH and Induced DNS Mark Nottingham