Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments

<mohamed.boucadair@orange.com> Wed, 08 January 2020 16:09 UTC

Return-Path: <mohamed.boucadair@orange.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 8B86E1200B5; Wed, 8 Jan 2020 08:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 7gGdfqLCDv6t; Wed, 8 Jan 2020 08:09:33 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE781201B7; Wed, 8 Jan 2020 08:09:32 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 47tDhq1MdCz1yj4; Wed, 8 Jan 2020 17:09:31 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 47tDhq019vzDq7j; Wed, 8 Jan 2020 17:09:31 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM44.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 8 Jan 2020 17:09:31 +0100
From: mohamed.boucadair@orange.com
To: Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, Christian Huitema <huitema@huitema.net>, Sara Dickinson <sara@sinodun.com>
CC: "last-call@ietf.org" <last-call@ietf.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
Thread-Topic: [Last-Call] [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments
Thread-Index: AQHVxhjOoMDYdxwsKkCBEzFr7HSiGqfg7Z8A
Date: Wed, 08 Jan 2020 16:09:30 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330313F779C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <4639bd67-6fca-47d1-aaeb-85fcd0394f46@www.fastmail.com> <7E5F804D-535F-4CB3-8F7F-ABD0ED4B833A@sinodun.com> <CABcZeBON0ung2htbaiKWGKJSUsHrPhrcEfJgVDoO3+UYCQZxsg@mail.gmail.com> <7729E44B-38EB-4EAF-8EFF-ED286696373E@sinodun.com> <CABcZeBNKsQ1pEVwxwYMgGTUhFntQ4h+L1Qyo=Q_nfN7p13y-UQ@mail.gmail.com> <85cb9bdb-690f-dd01-b824-3f33dbe111b7@huitema.net> <313877282.18779.1578483742473@appsuite-gw2.open-xchange.com>
In-Reply-To: <313877282.18779.1578483742473@appsuite-gw2.open-xchange.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330313F779COPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/auWjTQCVZ2Gxp6lchfJJlo50e6s>
Subject: Re: [dns-privacy] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments
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: Wed, 08 Jan 2020 16:09:36 -0000

Hi all,

I agree with Vittorio.

FWIW, slide 6 of https://datatracker.ietf.org/meeting/104/materials/slides-104-maprg-dns-observatory-monitoring-global-dns-for-performance-and-security-pawel-foremski-and-oliver-gasser-01 shows that very few DNS providers are handling +53% of the traffic. It is fair to mention the risk to see such centralization further exacerbated. Of course, the one mentioned by Christian is to be called as well.

Cheers,
Med

De : last-call [mailto:last-call-bounces@ietf.org] De la part de Vittorio Bertola
Envoyé : mercredi 8 janvier 2020 12:42
À : Christian Huitema; Sara Dickinson
Cc : last-call@ietf.org; DNS Privacy Working Group
Objet : Re: [Last-Call] [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03 - Section 3.5.1.1 Comments


Il 08/01/2020 09:10 Christian Huitema <huitema@huitema.net> ha scritto:


Centralization manifests itself in many ways. EKR is correct that big ISP do get a huge part of the traffic -- last time I checked, there was at least one ISP in China and another in India that served pretty much as many customers as Google DNS. There is also centralization at work due to outsourcing of the DNS service by ISP. This is a classic concentration path: an outsourcer that serves many ISP will achieve economies of scale and may be able to monetize the data flow, making outsourcing a viable option for the ISP. Experience predicts that competition between these outsourcers will exhibit "winners take all" dynamics leading to concentration. As EKR says, the move to third party resolvers may well counter concentration in the back end of the network. It could also achieve the opposite, but there are risks on both sides of this issue. I don't see how we can achieve consensus that one side of the risk is more dangerous than the other.
As I understood it, the purpose of the draft is to document all possible risks, and not necessarily to provide a consensus view on which ones are stronger or more important than others. Personally, I think that ISPs can "take all" on the scale of a single country/region but their "physicalness" makes it much harder for them to achieve dominance on a global scale, while third parties operating immaterial services over the network can more easily "take all" on a planetary level - but this is just a personal assessment, and I may just be wrong. So you could just state this view and the opposite one, and then the readers (the implementers using this as guidance) will then be free to decide which of these risks are more relevant to their use case, context and views of the world.

Thus I would suggest text that describes "both sides of the risk" and then leaves it to the readers to decide which one is more problematic for them.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com<mailto:vittorio.bertola@open-xchange.com>
Office @ Via Treviso 12, 10144 Torino, Italy