IETF Logo Mail Archive

Re: [Add] I-D Action: draft-btw-add-home-00.txt

Vittorio Bertola <vittorio.bertola@open-xchange.com> Tue, 10 March 2020 10:18 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 684523A0FD4 for <add@ietfa.amsl.com>; Tue, 10 Mar 2020 03:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_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 o3VnjhwqgAEj for <add@ietfa.amsl.com>; Tue, 10 Mar 2020 03:18:45 -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 25CB13A0FD2 for <add@ietf.org>; Tue, 10 Mar 2020 03:18:44 -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 EC9066A272; Tue, 10 Mar 2020 11:18:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1583835523; bh=2x3n2VsCGULE4XArqBy8BW2bJl69P/dzIC2AwmCZi4Q=; h=Date:From:To:In-Reply-To:References:Subject:From; b=CpvEpOlbpsT7IltiFczTC218tKbx9VVLA/3WCH/c3n+3AhSz7iXjCuijMC2ycq+dF 31wJJWaFOUqU+pjS6qubBSR3othjGUUbIdgLJ6Or0rkuT4G+ZLkGA3x3igvxp/0ISl UitMn8YS+MJn95JBAsl0qkSMJ/wrXeZoXDvvHuyxy4l32C918aZc7o0/J0TF5N1+dS 4cZZ1A4S66FgLfTli+pdKUGfmayL/MgK5jFr9GaNYBxURJF8/2z0emOMPZMzQq6G2s JWdcZC9+sf9kAQyo/xUh6q9xa6AgcszCyIeQtCGlxzdxRkN6S+t6aXfc1ZUT3zsEV0 jLZrTQx8V8J5Q==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 E0DF63C0310; Tue, 10 Mar 2020 11:18:42 +0100 (CET)
Date: Tue, 10 Mar 2020 11:18:42 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: mohamed.boucadair@orange.com, ADD Mailing list <add@ietf.org>
Message-ID: <1659773937.38028.1583835522817@appsuite-gw2.open-xchange.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933031463FFC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <158330934617.29404.4287578882183435520@ietfa.amsl.com>, <787AE7BB302AE849A7480A190F8B93303145E6CC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MW2PR00MB0410F2E1D3575DD07752082AFAE30@MW2PR00MB0410.namprd00.prod.outlook.com> <787AE7BB302AE849A7480A190F8B933031463FFC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_38026_275031167.1583835522801"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev5
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/FBk_J8H95G224G29w4B-w2cq5oM>
Subject: Re: [Add] I-D Action: draft-btw-add-home-00.txt
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: Tue, 10 Mar 2020 10:18:47 -0000

>     Il 07/03/2020 18:18 mohamed.boucadair@orange.com ha scritto:
> 
> 
>     We need collectively to think about the exact behavior to follow. For example, it does not make sense to seek for the user consent to upgrade to DoT/DoH while that same server is used for Do53.
> 
I agree, though "user consent" is generic. If we suggest that as a best practice consent should be asked, we should make it explicit why, and what should the user be consenting to.

If user consent is introduced to comply with data protection laws, then the elements of the consent are:
- who will get the data
- what will that party do with the data
This means that the transmission channel over which data is sent to that party is unimportant in terms of consent, so if the user is ok with the DNS operator receiving their information via Do53, it can be assumed that he/she is also ok with the DNS operator receiving the same information via DoT/DoH or in any other way.

On the other hand, if the consent is tied to the degree of channel security that is offered, then indeed the switch of channel might affect the user's desire to consent. Still, if we can assume that DoT/DoH towards the same operator always offers more security than Do53, and that the user has already consented to Do53, then we can also assume that the user will be happy with DoT/DoH as well.

Bottom line: if we want to discuss consent-related issues in a draft, we should expand the reasons behind our suggestions. Or we can just strike the discussion entirely, as apparently it has been done in the last versions.

--

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

v2.23.0 | Report a Bug | By Email