Re: [E2ee] Draft-e2ee-definition presented to openpgp

Vittorio Bertola <vittorio.bertola@open-xchange.com> Wed, 13 April 2022 13:02 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: e2ee@ietfa.amsl.com
Delivered-To: e2ee@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29E13A1B85 for <e2ee@ietfa.amsl.com>; Wed, 13 Apr 2022 06:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 JvmcD7OdEUMs for <e2ee@ietfa.amsl.com>; Wed, 13 Apr 2022 06:02:55 -0700 (PDT)
Received: from mx3.open-xchange.com (mx3.open-xchange.com [87.191.57.183]) (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 D6BCD3A1B80 for <e2ee@ietf.org>; Wed, 13 Apr 2022 06:02:54 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id 8AC176A0DC; Wed, 13 Apr 2022 15:02:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1649854972; bh=mi+kdSMXLpkH6Ijs8gqrUiH/n9rzmmSmNdgeib4cj6A=; h=Date:From:To:In-Reply-To:References:Subject:From; b=SWlLiKEREmeE9cTAxVKWTgLu5vJ1Hfprc2+siiWe4nIa9iZcHXVbI7oQVnbxgAzhT G55IMwHI5jfNXny8tbqOYuiMOXBGN91SofYhf20vwM65mvBwAO0TrAOypsUy30fBIo YPC2dsagg50hcQEWjQQH4sRCKej9Hwqwf3N8p1bndovjAcF8QRdgbm5EfqFNnIPc9U sLXVcVySxTghjrcXVnq0En15K/Dabt27nj38FMmCDwFJqDc8OX5IoeagrBYTUvz5+r mvla1dV+jisLtGZ6BaJpuJ2chjUB5WvRxIc3HBFEb+UtjwmscPsXnUHElL9sqTlPkM FM04NpDFZnpEg==
Received: from appsuite-gw1.open-xchange.com ([10.20.28.81]) by imap.open-xchange.com with ESMTPSA id ZTpaIPzJVmKMUQAA3c6Kzw (envelope-from <vittorio.bertola@open-xchange.com>); Wed, 13 Apr 2022 15:02:52 +0200
Date: Wed, 13 Apr 2022 15:02:52 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Mallory Knodel <mknodel@cdt.org>, e2ee@ietf.org
Message-ID: <312091520.3629.1649854972492@appsuite-gw1.open-xchange.com>
In-Reply-To: <CAGVFjMKTodqYTFPsGzh2y78sv1_PSCRCef6OSfFm4YJhKvKBvw@mail.gmail.com>
References: <CAGVFjMKTodqYTFPsGzh2y78sv1_PSCRCef6OSfFm4YJhKvKBvw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3627_1826998424.1649854972473"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev12
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/e2ee/wHd2hmtwN5lxTrYs89LoaW3uDAU>
Subject: Re: [E2ee] Draft-e2ee-definition presented to openpgp
X-BeenThere: e2ee@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of the definition of end-to-end encryption." <e2ee.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e2ee>, <mailto:e2ee-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e2ee/>
List-Post: <mailto:e2ee@ietf.org>
List-Help: <mailto:e2ee-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e2ee>, <mailto:e2ee-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2022 13:03:00 -0000


> Il 21/03/2022 13:18 Mallory Knodel <mknodel@cdt.org> ha scritto:
> 
> 
> 
> 
> 
> Hi all,
> 
> 
> This morning I presented the draft [0] to openpgp with these slides [1].
> 
> 
> Big thanks for the feedback in the session, and an additional request for reviews on this document. You can open issues and PRs [2], or you can reply to the e2ee@ietf.org <mailto:e2ee@ietf.org> list with your review. I finally had the time to go through this document and here is my initial review.



§2.2: This text is quite convoluted :) Anyway, I'll point out that there are two conditions for the lower layer endpoints to be acceptable as a replacement for the "end identity"; one, as pointed out, is that no third party can access the communications across the layers; another one, however, is that whoever supplies the software and applications that implement those lower layer endpoints acts in the full interest of the user, without doing any additional data processing or sharing than just passing data up and down the stack. This is somewhat hinted at at the end of 2.1, but it would be necessary to deal with it in 2.2 as well; otherwise, the "lower layer end-to-end encrypted communication" cannot at all be equated with "end-to-end encryption".



(I was wondering if we should try to introduce different terms for "end-user-to-end-user encryption" and "endpoint-software-to-endpoint-software encryption". If we found good ones, this could actually help in making users aware of this very important difference, and of the requirement of being able to fully trust their communication apps.)



§2.3: Perhaps there should be some discussion of endpoint authentication, which should be provided by the encryption mechanism. If you securely encrypt your communications to the wrong endpoint, can we still call this "end-to-end encryption"? Technically, yes, but substantially?



§4.2: I found the reference to "user expectations" a too weak proxy for the idea that a system is trustworthy if it acts in the interest of the end-user only. Many of the surveillance capitalism companies claim that their users actually expect to be tracked, profiled and sold to third parties as this will provide them with a "better, customised service"; or that users should expect to be tracked since this is what they agreed to at page 37 of a 52-page fine print T&Cs document that they have to scroll through and accept to access the service. It should be clear that providers behaving this way are not trustworthy. It should also be clear that "user expectations" should only be defined by the users and not by any other party claiming to speak for them.



§4.3: I am confused. We seem to say that access to content intended for an e2ee communication by any party which is not the two humans that are communicating breaks e2ee, even if it happens before the content is encrypted or after it is decrypted, so even if it technically does not break the encryption. I can share this view, but then, the "not-fully-benevolent communications provider" problem is also fully in scope and should be addressed more extensively throughout the document.



I am wondering if we should, as part of reality, recognize that there will be legal requirements that may make it unavoidable for the app to share or screen content at this stage, and in this case at least advocate some damage limitation measures such as transparency and accountability of the mechanism. However this is supposed to be a definitions document, so perhaps this would be out of scope.



In general, I would like this section to have an additional para devoted to an explicit analysis of the user expectation that the content and metadata of their communications are not used to profile them. (I'd work on text if useful.)



Hope this is useful and thanks for working on this document.


--

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