Re: [Add] My principles for discovery

Vittorio Bertola <vittorio.bertola@open-xchange.com> Wed, 25 March 2020 07:33 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333D83A0818 for <add@ietfa.amsl.com>; Wed, 25 Mar 2020 00:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 PRiTP1ryiPqC for <add@ietfa.amsl.com>; Wed, 25 Mar 2020 00:33:01 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 1B4633A003A for <add@ietf.org>; Wed, 25 Mar 2020 00:33:00 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id 3FB3D6A256; Wed, 25 Mar 2020 08:32:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1585121577; bh=1k0N05PdtaYX8BqJRl3sRaMbzquiEpc781adPGlEDKY=; h=Date:From:To:In-Reply-To:References:Subject:From; b=bC19JxOTHnrIEBr1dAWWDMjG+9xXM+0bkWLLAHOZdWSUtr+hr+7qWCNrYwNWPyK8t GKpuhjFM+xdU5Sn5gTNjeFaazt9ouEzRHUDOcFK85IB6vjxN0paNTZv7GfKi8VcUJR EAxKut2dW9AUcxMuMz5OgEoN+mhf+T7iUPIa9AyYLPW6lNwvN4u3uc0uMgoUULanav tMi+HrzZiogv68nMnJWTsDCetz4l3PXIkfeE9GMHfsxVbD0lklfvGuE/pFWgYFHEiK 2v6rMeWl6ej+8I76/q1zVy/GezMXOKYxmzOOWxuXPLwNMUllGQ30L08WLGxuGUrIL1 /0rSX3xfiFKjQ==
Received: from appsuite-dev-gw1.open-xchange.com (appsuite-dev-gw1.open-xchange.com [10.20.30.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 32D9B3C0187; Wed, 25 Mar 2020 08:32:57 +0100 (CET)
Date: Wed, 25 Mar 2020 08:32:57 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Martin Thomson <mt@lowentropy.net>, add@ietf.org
Message-ID: <93585501.473.1585121577118@appsuite-dev-gw1.open-xchange.com>
In-Reply-To: <aec5404a-99eb-4aa7-9020-1e7b4f51b5ca@www.fastmail.com>
References: <aec5404a-99eb-4aa7-9020-1e7b4f51b5ca@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.4-Rev0
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; 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: <https://mailarchive.ietf.org/arch/msg/add/EgvywWeYJ7aHzImOmIKAirQybsc>
Subject: Re: [Add] My principles for discovery
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2020 07:33:07 -0000


> Il 25/03/2020 05:36 Martin Thomson <mt@lowentropy.net> ha scritto:
> 
>  
> As I raised this in the meeting, I think that it's only fair that I include what I think the principles should be.
> 
> In short, I believe that any entity that you interact with should be able to present their views on what resolver you should use.  Client policy will then dictate which - if any - of those is used.

I don't necessarily disagree with the approach, but there is a question to which I need a very convincing answer first.

"Any entity you interact with" already has a way to tell you - even force you - to use a name server they control to effect resolution of their domain names. It's called "authoritative name server".

It seems to me that the model that especially draft-pauly is proposing - i.e. every destination pointing the client to a resolver that the destination controls - is functionally equivalent, in terms of who gets to see which information, to eliminating the concept of an external resolver and having the end-user device implement and run a full resolver on its own.

This, as per Tommy's reply to the question I made at IETF 106, would increase privacy because the resolution process would not provide data to any other party than the "final destination", which would anyway get it when the following HTTPS connection happens. (The fact that the two sets of data are actually the same has been challenged yesterday in the Jabber chat, but that's another discussion.)

I assume that this is also what you are envisaging, since the alternative - every destination pointing the client to a resolver which they don't control, but with which they have commercial or other agreements - opens up the potential for much heavier security threat, centralization and surveillance scenarios than it is ever possible today, so I would expect it to be ruled out much like other out-of-same-origin practices.

So - why do we need to develop all this complex machinery just to let destinations indicate some kind of resolver that does the same thing that their authoritative already does? What's the difference with just implementing a full resolver in the client?

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