Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

Sara Dickinson <> Fri, 04 October 2019 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A4C4120872 for <>; Fri, 4 Oct 2019 06:26:25 -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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YSty3DEyZvTK for <>; Fri, 4 Oct 2019 06:26:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02FF512085F for <>; Fri, 4 Oct 2019 06:26:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=ePh8Ip9DkPWVZPzrVxysGH7cIw4HzODnf8p8aNV0jD4=; b=GhmZicREE8nlLj9lONrsAodSO0 uEfd9i7tr5oo6mXV2oo7dQibRd/A2OE9x1zJCn7V5GQ/2ixUSIlnMQSCJV5U9vNYyw2NSRCSeeDXW Xu5o5TaxKQD1DmAQLKtEi9yPuvI9o354ct3N8iRfqU6YMRmXAgAHBNC1ZG1uodIi0eEMbRYvUSo8j eHhF5lkNkcP+GTx/Kii/DjpH5XwXlsrkcz84zd1nsp0/EXfaZA7lWzUnRGBn9bnGWJAo1os5v4LWC wBEqWvJnrm5+LiAbC3H8IoKoQudD2jre5xqslOm4Yz4sVVB4+SQbqfq6eSs7F0qp0XzBIoabGyRbz sXTwrpPw==;
Received: from [2001:b98:204:102:fffa::41e7] (port=56521) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1iGNbB-0000rv-18; Fri, 04 Oct 2019 14:26:21 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sara Dickinson <>
X-Priority: 3
In-Reply-To: <>
Date: Fri, 4 Oct 2019 14:26:19 +0100
Cc: Tim Wicinski <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Vittorio Bertola <>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <>
Subject: Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Oct 2019 13:26:25 -0000

> On 3 Oct 2019, at 12:16, Vittorio Bertola <>; wrote:
>> Il 27 settembre 2019 17:54 Sara Dickinson <>; ha scritto:
>> I hope the changes address most of your concerns - please review and let me know.
> I went through the changes, and I like them - you did a really good job in capturing my comments and more generally the recent development of the discussion on privacy and DNS, doing it in a balanced way (I can tell because I would have used more pointy language in a couple of places :-) ). So thanks for this. 

Thanks very much for this feed back - at this late stage I was trying to make sure the new text was something we could get consensus on from the WG :-)

> The only note I still have is on The revised text seems to say that blocking remote resolvers is either damaging or neutral for privacy, but in some cases it could actually be beneficial.

I did deliberately scope this section to just networks where the user privacy was compromised in someway : ‘...'when the local resolver does not offer encryption and/or has very poor privacy policies.” so the user had a justification for actively choosing a remote resolver to improve privacy in some way. 

> So we could add at the end of the first paragraph:
> "In some cases, networks might block access to remote resolvers for security reasons, for example to cripple malware and bots or to prevent data exfiltration methods that use encrypted DNS communications as transport; in these cases, the block would actually increase the protection of the user's privacy.”

Can I modify the last bit of text slightly given the above context?

"In some cases, networks might block access to remote resolvers for security reasons, for example to cripple malware and bots or to prevent data exfiltration methods that use encrypted DNS communications as transport. In these cases, if the network fully respects user privacy in other ways (i.e. encrypted DNS and good data handling policies) the block can serve to further protect user privacy by ensuring such security precautions.”


> Apart from this, there might be a bit of beautifying to do here and there in (things like "application-specific" in place of "application specific" or "the user's full knowledge" in place of "the users full knowledge"... sorry for being grammar-nazi). I can do more proofreading separately if you want.

Mohamed Boucadair did a very good review with many such editorial improvements. I’m working on an update to incorporate those and I’ll do my best to catch the ones you mention and others like them. I’ll send you a link to the GitHub repo before I publish and if you have time for proofreading that would be great!

Best regards