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

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 15 September 2017 22:04 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 9EA91133209; Fri, 15 Sep 2017 15:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Fo-imUq15cSn; Fri, 15 Sep 2017 15:04:43 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FCE1330A1; Fri, 15 Sep 2017 15:04:43 -0700 (PDT)
Received: from [10.32.60.139] (50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v8FM3TRc075760 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Sep 2017 15:03:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42] claimed to be [10.32.60.139]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Cc: doh@ietf.org, IETF <ietf@ietf.org>
Date: Fri, 15 Sep 2017 15:04:36 -0700
Message-ID: <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org>
In-Reply-To: <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <CA+9kkMBJAP23GmGf_ix-DMeOMB=Rbas+qsBQhrVwZuA5-Cv7Mg@mail.gmail.com> <EB3D58DB-1F8D-4E32-AE71-841EBCDDC3CA@vpnc.org> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <CA+9kkMDokEDbBiCR_TRQda2RBHxoHag6mQL57Uzn7ALqakm1Og@mail.gmail.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/ty4zMc5veL2ovj-WwAYPNBiYouQ>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
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: Fri, 15 Sep 2017 22:04:44 -0000

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

> 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. If you have some proposed MUST NOTs on the 
current document, by all means send them in.

--Paul Hoffman