Re: [Doh] WG Review: DNS Over HTTPS (doh)

Patrick McManus <> Sat, 16 September 2017 02:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FEEA1320C9 for <>; Fri, 15 Sep 2017 19:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.287
X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M_7LoiVka0yA for <>; Fri, 15 Sep 2017 19:23:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1DC88126B7E for <>; Fri, 15 Sep 2017 19:23:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 1615C3A01B for <>; Fri, 15 Sep 2017 22:23:31 -0400 (EDT)
Received: by with SMTP id l196so3938337lfl.1 for <>; Fri, 15 Sep 2017 19:23:31 -0700 (PDT)
X-Gm-Message-State: AHPjjUgZhSr/T6cBEGW44ocv6K/X2nX/DVEyvQA8v1hvhG4BKjOAsXz7 Lr/jNRgON7iqiEBohB20EMSxx0pQpPQ8suTq/nU=
X-Received: by with SMTP id z28mt10327196lje.124.1505528609675; Fri, 15 Sep 2017 19:23:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 15 Sep 2017 19:23:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Patrick McManus <>
Date: Fri, 15 Sep 2017 19:23:28 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
Cc:, IETF <>
Content-Type: multipart/alternative; boundary="001a114b522cfc89dd05594531e6"
Archived-At: <>
X-Mailman-Approved-At: Sat, 16 Sep 2017 02:54:38 -0700
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Sep 2017 02:23:34 -0000

Hi All. I'll respond to most of the key points in one message. Forgive the

* This is meant to be over "https" full stop. Whether that means we require
a particular minimum level of version (which the input draft defines as >=
h2 not == h2 btw) to satisfy the uses at hand is a controversy suitable for
the wg to resolve.

On one hand we should consider that semantic http has no versioning, so
using the semantics from something like javascript becomes impossible to
enforce the versioning requirement (though the server could do so). otoh
you could argue that the mechanisms of <=h1 are not technically up to the
task (hol blocking, lack of priority, etc..) of providing a reasonable
implementation for a recursive resolver like use case.. or even argue that
the IETF would have been better off historically across the board using new
functionality as a forcing function for migrating to newer specifications
rather than putting such a premium on backwards compatibility (or arguing
against that based on bootstrapping costs, etc..). As I said - that's a
controversy for the wg. The charter should be over https, and the wg can
decide exactly what that means there is no need to litigate it in a charter

* I believe adam and mnot are right on the questions of same origin, js,
https:// uris..

* I think its fine for the charter to say the group must document the
security considerations of the source of a name resolution.


On Fri, Sep 15, 2017 at 3:33 PM, Stephen Farrell <>

> On 15/09/17 23:04, Paul Hoffman wrote:
> > On 15 Sep 2017, at 14:44, Stephen Farrell wrote:
> >
> >> On 15/09/17 20:25, Ted Hardie wrote:
> >>>
> >>> This set of questions is pretty different from the ones you get
> >>> with "function over different paths", because the locus of
> >>> control moves from the mostly-trusted browser to the mostly not
> >>> trusted downloaded application.
> >>
> >> FWIW, I share Ted's concerns about origins. Regardless of what
> >> approaches are taken, the effects of this need to be well
> >> understood I think. I don't object to the WG being chartered though
> >> but would suggest that there be a mention in the charter that the
> >> WG needs to document the consequences, including the dangers, of
> >> caching and re-use of DNS answers for likely implementations.
> >
> > The charter already points to the document that the work will be
> > based on, which has that topic in it, because *you* pointed it out in
> > the earlier discussion of the document. As co-author on the document,
> > I assure you we will not remove it, if for no other reason than I
> > wouldn't want to face your wrath again in IETF Last Call. :-)
> "Wrath" has to count a pretty speedy escalation in terms,
> and especially when I'm so shy and retiring about saying
> what I think:-)
> I'm also confident that that security considerations will
> cover this topic in some sense. I'm not confident that I
> understand the relevant consequences at this point in
> time, so ISTM useful to mention it in the charter as that
> might help later.
> >
> >> I'd be even happier if the resulting spec had a bunch of MUST NOT
> >> statements about that, if such statements were likely to be
> >> effective.
> >
> > All MUST NOTs are only partially effective, but we use them anyway
> > to help good implementers.
> Agreed. And sometimes we use them to describe damaging
> things bad implementers might otherwise be likely to do
> without realising the downsides.
> > If you have some proposed MUST NOTs on
> > the current document, by all means send them in.
> Probably better in a different thread, but I think there
> is scope for a MUST NOT (re-)use answers outside the same
> origin, but I've no doubt there are subtleties there that
> the WG would need to figure out and that'd make this
> sentence a bad idea to include on it's own.
> S.
> >
> > --Paul Hoffman
> >