From nobody Wed Apr 13 06:03:01 2022 Return-Path: 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 ; 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 ; 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 ; 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 ); Wed, 13 Apr 2022 15:02:52 +0200 Date: Wed, 13 Apr 2022 15:02:52 +0200 (CEST) From: Vittorio Bertola To: Mallory Knodel , e2ee@ietf.org Message-ID: <312091520.3629.1649854972492@appsuite-gw1.open-xchange.com> In-Reply-To: References: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2022 13:03:00 -0000 ------=_Part_3627_1826998424.1649854972473 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Il 21/03/2022 13:18 Mallory Knodel ha scritto: >=20 >=20 >=20 >=20 >=20 > Hi all, >=20 >=20 > This morning I presented the draft [0] to openpgp with these slides [1]. >=20 >=20 > 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 repl= y to the e2ee@ietf.org list with your review. I fina= lly had the time to go through this document and here is my initial review. =C2=A72.2: This text is quite convoluted :) Anyway, I'll point out that the= re are two conditions for the lower layer endpoints to be acceptable as a r= eplacement for the "end identity"; one, as pointed out, is that no third pa= rty 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 do= wn 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 e= ncryption". (I was wondering if we should try to introduce different terms for "end-use= r-to-end-user encryption" and "endpoint-software-to-endpoint-software encry= ption". If we found good ones, this could actually help in making users awa= re of this very important difference, and of the requirement of being able = to fully trust their communication apps.) =C2=A72.3: Perhaps there should be some discussion of endpoint authenticati= on, which should be provided by the encryption mechanism. If you securely e= ncrypt your communications to the wrong endpoint, can we still call this "e= nd-to-end encryption"? Technically, yes, but substantially? =C2=A74.2: I found the reference to "user expectations" a too weak proxy fo= r the idea that a system is trustworthy if it acts in the interest of the e= nd-user only. Many of the surveillance capitalism companies claim that thei= r users actually expect to be tracked, profiled and sold to third parties a= s 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 o= f a 52-page fine print T&Cs document that they have to scroll through and a= ccept to access the service. It should be clear that providers behaving thi= s 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. =C2=A74.3: I am confused. We seem to say that access to content intended fo= r an e2ee communication by any party which is not the two humans that are c= ommunicating breaks e2ee, even if it happens before the content is encrypte= d or after it is decrypted, so even if it technically does not break the en= cryption. I can share this view, but then, the "not-fully-benevolent commun= ications provider" problem is also fully in scope and should be addressed m= ore 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 damag= e limitation measures such as transparency and accountability of the mechan= ism. 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 Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_3627_1826998424.1649854972473 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =20 =20

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 r= eply to the e2ee@ietf.org list with yo= ur review.
I finally had the time to go through this document and here is my initia= l review.

=C2=A72.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, howeve= r, is that whoever supplies the software and applications that implement th= ose lower layer endpoints acts in the full interest of the user, without do= ing 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 e= nd-to-end encrypted communication" cannot at all be equated with "end-to-en= d 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 en= cryption". If we found good ones, this could actually help in making users = aware of this very important difference, and of the requirement of being ab= le to fully trust their communication apps.)

=C2=A72.3: Perhaps there should be some discussion of endpoint authentic= ation, which should be provided by the encryption mechanism. If you securel= y encrypt your communications to the wrong endpoint, can we still call this= "end-to-end encryption"? Technically, yes, but substantially?

=C2=A74.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 th= e end-user only. Many of the surveillance capitalism companies claim that t= heir users actually expect to be tracked, profiled and sold to third partie= s as this will provide them with a "better, customised service"; or that us= ers should expect to be tracked since this is what they agreed to at page 3= 7 of a 52-page fine print T&Cs document that they have to scroll throug= h and accept to access the service. It should be clear that providers behav= ing this way are not trustworthy. It should also be clear that "user expect= ations" should only be defined by the users and not by any other party clai= ming to speak for them.

=C2=A74.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 ar= e communicating breaks e2ee, even if it happens before the content is encry= pted 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 com= munications provider" problem is also fully in scope and should be addresse= d more extensively throughout the document.

I am wondering if we should, as part of reality, recognize that there wi= ll 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 da= mage limitation measures such as transparency and accountability of the mec= hanism. However this is supposed to be a definitions document, so perhaps t= his 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 metad= ata 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.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
------=_Part_3627_1826998424.1649854972473--