Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

Vittorio Bertola <> Tue, 21 January 2020 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 634D91200F5; Tue, 21 Jan 2020 06:46:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0-_nhs1mRP-t; Tue, 21 Jan 2020 06:46:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EE12120090; Tue, 21 Jan 2020 06:46:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0ABE6A275; Tue, 21 Jan 2020 15:46:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1579617980; bh=H4S6/k8bYamk3YM64TZmJAFCUnjwFUVAIOAEiPDy5Zc=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=QKh2ZwnG9TygfyOIRdeh0/9MqvHYn1fNeePsfSmbuQ8lvgiJaq4VaAyT8HGvwbCM+ j78vbGnsD8oAwu7aCI136vXiUsHSiTTSzMU70YsD5YHbaLjOqge3sFmlEnWQBB10PU 1AjRIjVmKke1EjwIqO2qIfw63M7wAAxnVFsCOnQm8ZZRghfL+D9I81yhWRVgtEm2pH Or+sH6s/IZxGD+yV5NkCCD6R3bKFd2oksvpPJmj4FR2pkUVxdOIH343BcLtsK7wQmX uFJW0EVWocfnoXnYvg36PVkYxGB3jEESuvwR/VkR2UAXv02pU2o3hZgfVl5wYSDEQd XhdIbaAbCZPRQ==
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E41043C015C; Tue, 21 Jan 2020 15:46:19 +0100 (CET)
Date: Tue, 21 Jan 2020 15:46:19 +0100 (CET)
From: Vittorio Bertola <>
To: "" <>
Cc: "" <>, "" <>, "" <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev3
X-Originating-Client: open-xchange-appsuite
Autocrypt:; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <>
Subject: Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2020 14:46:31 -0000

> Il 20/01/2020 22:45 Eric Vyncke (evyncke) <>; ha scritto:
> But, as section 3.5.1 ("in the recursive resolvers") raised a lot of discussions during the first IETF Last Call, and as the authors reacted to those comments by deep changes in the text, let's have a new IETF Last Call before proceeding with IESG evaluation.

First of all, I'd like to thank Sara for all the effort in rewriting a lot of text yet another time to address all the comments. I think the result is good, even if I would have preferred other text on certain things.

There is only a minor comment that I still have on 3.5.1. The new version has a part about DNS centralization risks, but it only addresses the risks deriving from the ISP market, not the newer ones coming from "application-specific resolver selection", which were mentioned in -03. I have two alternative text proposals to cover this:

1) in the bullet list in, add another bullet:

"* popular applications directing DNS traffic by default to specific dominant resolvers"


2) in, last paragraph, just after "increase or decrease user privacy" and before the hyphen, add:

"and promote or counter centralization"

Given Eric's (not √Čric's :-) ) comment on the requirements for user control in, i.e. that they also apply to the selection of non-encrypted resolvers today, it would be fine for me if they were extended to device/OS resolver configuration in general. In that case, I would plead for the addition of a point regarding the fact that the user should be enabled to configure the resolver for the OS and all the applications at once, in a single place.

I also have an editorial suggestion: to reduce the nesting of sub-sections in 3.5, perhaps you could break down section 3 into multiple first-level sections and do some renumbering, e.g.

3. -> 3.
3.1, 3.2, 3.3 -> 4.1, 4.2, 4.3 within "4. Risks in the DNS data"
3.4 -> "5. Risks on the wire"
3.5 -> "6. Risks in the servers"
3.6, 3.7 -> 7.1, 7.2 within "7. Other risks"

In any case, I think that we now have a solid document and hope we can release it soon.

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange 
Office @ Via Treviso 12, 10144 Torino, Italy