Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

Sara Dickinson <sara@sinodun.com> Tue, 07 January 2020 18:35 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EF212089B; Tue, 7 Jan 2020 10:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
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 1NcQyj0jAUND; Tue, 7 Jan 2020 10:35:57 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 27C68120802; Tue, 7 Jan 2020 10:35:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=x59K8HxqwS2sFh5IbGTWAHQDw/QwZbCKkHfLFcwte44=; b=FEWs4XsE2w9X5DyKKmUybEDbkw KBkBaJawejnDW57C8rELZlQfedE9HlCEcgnF8nhSNen99FoRmzNPe/ZTDIbTAdOyrHmDD23QtdjLd VeslOOl9U2igpbGlhcqKGBMJWSyrYuJ4/3aEBHS3LfL9APQmkI4RDe/e6uu9k1ON2/bX6a8d7sAez ZhZcNaOWvKmqpJzSk0T7rDvFSWxWP3/nQm+af8A6rI5i+I0ljP5dwiHBVWIS/Rfc7uu+l7baeY79W zaCFdaMqCvakHh7+vt1h1ARPB/FvuPyyFWqq9b71h9bQi7qeubYRL1fc7cleWplkQ+zbRhi9KcaQH BaHDfrdQ==;
Received: from [2a02:8010:6126:0:1d21:ef98:8b8e:dcec] (port=64235) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1iothm-0000pN-OB; Tue, 07 Jan 2020 18:35:54 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <CAChr6SyAhA8V7AQHC67vTEmHWgd+gMzM-ZtFTkBDUhsvVQEC8A@mail.gmail.com>
Date: Tue, 07 Jan 2020 18:35:50 +0000
Cc: draft-ietf-dprive-rfc7626-bis.all@ietf.org, last-call@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <614B534F-D62D-432C-A3E5-A01D9BF972AA@sinodun.com>
References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> <a02720cf-01b3-d61a-94d2-b3d0a399f107@cs.tcd.ie> <20191223220509.GK35479@kduck.mit.edu> <CAChr6SyAhA8V7AQHC67vTEmHWgd+gMzM-ZtFTkBDUhsvVQEC8A@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/CGxBkrjMOVtMJobT42_vuhycgRk>
Subject: Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 18:36:01 -0000


> On 23 Dec 2019, at 22:12, Rob Sayre <sayrer@gmail.com> wrote:
> 
> Hi, here are comments I mistakenly sent to a thread about another dprive last call.

I took the liberty of removing Stephen, Ben and secdir from the cc list and modifying the subject as I believe this is a general review of the document not one specific to the issues raised by the secdir review. Please correct me if I’m wrong. 

> Summary: the section about "DoH Specific Considerations" is highly questionable, and seems like advocacy rather than a representation of IETF consensus.
> 
> ----
> 
> Hi,
> 
> I found two issues with [this draft]. The document mentions unattributed "concerns" in a few places.. That doesn't seem like helpful content, but I can't say that such "concerns" and rampant use of the passive voice are uncommon in today's IETF. 

I would suggest replacing ‘concerns' with ‘considerations', given that the title of the document is DNS Privacy Considerations.

> 
> Secondly, I found the entire section "3.5.1.5.2.  DoH Specific Considerations" to be objectionable, and recommend removing it. It mentions many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow extension fields and metadata, so there's nothing unique to DoH here (source: I've implemented DoH and ESNI clients). The entire section amounts to a description of fields that privacy conscious DoH clients /might/ send if they were poorly implemented. But it seems strange to stop there. Implementation quality ratholes can go on for a while: for example, the document doesn't mention the numerous problems with today's TLS, PKI, and BGP infrastructure that apply to both DoT and DoH.

As mentioned since this document is an analysis of the privacy considerations of actually _using_ DNS (not just the protocol definitions) then privacy considerations raised by poor implementations seem entirely in scope. The document does also discuss such issues with TLS, ones with PKI and PGP are clearly out of scope for this document. 

Sara.