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

Stephen Farrell <> Fri, 15 September 2017 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB9A8133224; Fri, 15 Sep 2017 15:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NOczRNmiIVwj; Fri, 15 Sep 2017 15:33:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA58B13208E; Fri, 15 Sep 2017 15:33:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40533BE73; Fri, 15 Sep 2017 23:33:12 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tddlDlmO2idk; Fri, 15 Sep 2017 23:33:10 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id C5C4FBE6F; Fri, 15 Sep 2017 23:33:10 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1505514790; bh=7hPGXjfc6FjglGhZcbpQw+vQUI2Qvzo9G5Zjhlvfrxo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LVkRRXlnlTRKgvq5Z0gT7DD/QaEc42lzbvAWzZ5+TuH/jUFFI6o9OUjriDzCssCc0 yGvDUFGSk+0oor82LEY4xGwmAK/XtAodMwAmvPHrOYkD/5wOWv1fNstFNKDtEv6dka eMtpr4B0i/VvH/GkGUKsfRoVr0b97XuaeUP33fmA=
To: Paul Hoffman <>
Cc:, IETF <>
References: <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 15 Sep 2017 23:33:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f4vb2pJImm1GENCLUMahUapFkDxTSwaDD"
Archived-At: <>
X-Mailman-Approved-At: Fri, 15 Sep 2017 15:35:58 -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: Fri, 15 Sep 2017 22:33:19 -0000

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.


> --Paul Hoffman