From nobody Tue Jul 27 11:29:05 2021 Return-Path: X-Original-To: e2ee@ietf.org Delivered-To: e2ee@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A793A086E; Tue, 27 Jul 2021 11:28:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: "IETF Announcement List" Cc: e2ee@ietf.org, mknodel@cdt.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <162741053103.16732.5392965248951377999@ietfa.amsl.com> Date: Tue, 27 Jul 2021 11:28:51 -0700 Archived-At: Subject: [E2ee] New Non-WG Mailing List: e2ee X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 18:28:57 -0000 A new IETF non-working group email list has been created. List address: e2ee@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/e2ee To subscribe: https://www.ietf.org/mailman/listinfo/e2ee Purpose: This mailing list exists to discuss how to best document a definition of end-to-end encryption (E2EE). In brief, it is an application of cryptography in communications systems between endpoints. E2EE systems are unique in providing features of confidentiality, integrity and authenticity for users. Improvements to E2EE strive to maximise the system's security while balancing usability and availability. Users of E2EE communications expect trustworthy providers of secure implementations to respect and protect their right to whisper. The IETF is the appropriate venue for this discussion and hopes the mailing list discussion results in a published RFC series document. This list belongs to IETF area: SEC For additional information, please contact the list administrators. From nobody Wed Jul 28 12:34:00 2021 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 888E63A1D16 for ; Wed, 28 Jul 2021 12:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MRfHmoCKps2w for ; Wed, 28 Jul 2021 12:33:53 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0DC3A1D13 for ; Wed, 28 Jul 2021 12:33:50 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id a12so2203086qtb.2 for ; Wed, 28 Jul 2021 12:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=otb4T4NYQTogK0ezeFy9O01AZ3bLfyKpE88wO8GeXrI=; b=TPQhvXGDVdTpUIQM87LDr0L9FAblAoiGfnOo4WyKRpFGAlv77bhg5AEs4eOCK6NNrY 0NMDE0lcSvBzXxs8G74Q+txH9/aDEzIsreXjpc/9t9t6rS+br7YF5eNWl6V7oAYVFQjT XTy7Ap5PTSxd0067zrREr18Sz0tsD5OwX8AXjdHRKGiShLOf/JRmg+aO/MA9md9xTnTE bJU6FwApFSH+aRaLirEAnz8PnLSnSfxWRC+8y8LW6IyZ0JglBQECT6l/UwL5LHOR+B2i HT9JKakMGJCLYug12prhbB47yc2Y9qQABoz1Ib/idHVnR4xFJN49teqm0loydfhhEw5F OJSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=otb4T4NYQTogK0ezeFy9O01AZ3bLfyKpE88wO8GeXrI=; b=d3OA7voXAVJnIYcywsYyAA/HLtrROh26rpIHlMESUa2j/lB65+FuL9MZ1zvaTtE+mM qNUO8TfSWpLz+TkNoGTYqgS/AOWH10LbHxTrFDHu/WbovA+Zoo2YKEXzePzpsB8Hj0MI 1PtC4KfihQuflzkedBsWncigVnYGNkuLCuJ7H9xdnv6+xSOiwsNLzLpqLpTVkDi3QEcK oGnHFx7LdnKQZ5JbKC24pNS/Me4H22kCmHAsw+c9BLhVMk/ybyQTKtwv8fQFUzDdDCj7 7YBUiQpwBQJH4eFRH67YGU5pmFi9dElTVyvfgwPJMoYgXbtqBpI3lsQALnMjnqFRR47J v87g== X-Gm-Message-State: AOAM5302p4rXKKrkF2V+XHakWZJFw35yR0PmrZoREoR5O/wMPMMXwNuA ErgYU/erdedsqkiqG4vo2C6xXUdE3X/N09hkV9V2sPYz64vbjA== X-Google-Smtp-Source: ABdhPJyP11xpRM8164LMMZvs0PNTZx7o47BxaYCwMdqEaPTo31RnPw6DQatlgWLrtTfXSlgwDUrvnClS3aoCz3DoASk= X-Received: by 2002:a05:622a:3:: with SMTP id x3mr1027949qtw.321.1627500828614; Wed, 28 Jul 2021 12:33:48 -0700 (PDT) MIME-Version: 1.0 From: Alec Muffett Date: Wed, 28 Jul 2021 20:33:12 +0100 Message-ID: To: e2ee@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2e3ab05c83410a4" Archived-At: Subject: [E2ee] Does the presence of overt, "Non-Ghost" surveillance actors/bots, inhibit E2E Security? X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 19:33:59 -0000 --000000000000c2e3ab05c83410a4 Content-Type: text/plain; charset="UTF-8" Hi All! I'll be presenting this to the CFRG (Crypto Forum Research Group) at IETF 111, late on Friday evening (London time): "A 'Duck Test' for End-to-End Secure Messaging" https://alecmuffett.com/alecm/ietf-111/draft-muffett-e2esm-v1.18a.pdf It's a reasonably short presentation-deck (albeit with a lot of slides) offering a simple, robust, and easily understood metric for people to use when judging assertions like: *"The GCHQ 'Ghost' Proposal does not harm End-to-End Security"* One interesting discussion that I *have* had, twice, regarding my draft is regarding (Slide 25) whether "overt, blatant surveillance" inhibits a system from being E2E-Secure - "because people will not be able to avoid surveillance." It's a great question, which I've answered with two different thought experiments: *Surveillance Scenario A:* Imagine that the UK Government imposes a "Technical Capability Notice" on WhatsApp and requires surveillance on everybody. Further imagine that WhatsApp has the decency to tell everybody that surveillance is enabled. Then Alice, in the UK, wants to talk to Bob with WhatsApp, but without Surveillance. What does Alice do? Answer: there is nothing she can do except "Fix the Government" or "Select a platform which does not implement surveillance on behalf of the UK Government". Her intentions or desires are incapable of changing anything about the situation, other than via political means. *Surveillance Scenario B:* Say that you are using Signal to hold a group chat, and suddenly after a month or so, it gets out that one of the people in the group chat ("Eve?") is actually a member of the state security services. Would that mean that Signal was suddenly no longer end-to-end encrypted? No. If one did believe that, then E2E would have a "Schrodinger's Cat"-quality - that it stops being E2E as soon as a spook looks at it. But if the presence of unknown surveillance does not prevent something being end-to-end encrypted, would the presence of *known* surveillance, up-front, prevent something being considered end-to-end encrypted? Well, when Eve was "outed", nothing has changed with the system other than user choice to continue/not-continue to participate in the chat. As 'user choice" was the only variable, user choice was also the differentiator - including (big picture) the choice to use an individual group chat *or* a messenger platform that was overtly enabled for state surveillance. The choice to pull that surveilled chat or that surveilled platform into one's own TCB/Trusted Compute Base/Zone of Trust, was a user choice. *Perspective* In short: I think that "end-to-end secure messaging with state surveillance overtly and transparently baked-in", is precisely *that*, and should be highlighted as such, for exactly the reasons as explained in *RFC2804*. Thus if people want to avoid surveillance, they should vote with their feet and use a different platform, or obtain a different government; however the surveillance should never be opaque, ghostly, or hidden. What do others think, please? - alec --000000000000c2e3ab05c83410a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All!

I'll be presenting this to the CFRG (Cr= ypto Forum Research Group) at IETF 111, late on Friday evening (London time= ):

"A 'Duck Test' for End-to-End Secure Messaging"= =C2=A0
https://alecmuffett.com/alecm/ietf-111/draft-muffett-e2es= m-v1.18a.pdf

It's a reasonably short presentation-deck (albe= it with a lot of slides) offering a simple, robust, and easily understood m= etric for people to use when judging assertions like:

"The G= CHQ 'Ghost' Proposal does not harm End-to-End Security"

One interesting discussion that I *have* had, twice, regarding my draf= t is regarding (Slide 25) whether "overt, blatant surveillance" i= nhibits a system from being E2E-Secure - "because people will not be a= ble to avoid surveillance."

It's a great question, which I&= #39;ve answered with two different thought experiments:

Surveilla= nce Scenario A:

Imagine that the UK Government imposes a "T= echnical Capability Notice" on WhatsApp and requires surveillance on e= verybody. Further imagine that WhatsApp has the decency to tell everybody t= hat surveillance is enabled.

Then Alice, in the UK, wants to talk to= Bob with WhatsApp, but without Surveillance. What does Alice do? Answer: t= here is nothing she can do except "Fix the Government" or "S= elect a platform which does not implement surveillance on behalf of the UK = Government". Her intentions or desires are incapable of changing anyth= ing about the situation, other than via political means.

Surveill= ance Scenario B:

Say that you are using Signal to hold a group c= hat, and suddenly after a month or so, it gets out that one of the people i= n the group chat ("Eve?") is actually a member of the state secur= ity services.

Would that mean that Signal was suddenly no longer end= -to-end encrypted? No. If one did believe that, then E2E would have a "= ;Schrodinger's Cat"-quality - that it stops being E2E as soon as a= spook looks at it.

But if the presence of unknown surveillance does= not prevent something being end-to-end encrypted, would the presence of *k= nown* surveillance, up-front, prevent something being considered end-to-end= encrypted? Well, when Eve was "outed", nothing has changed with = the system other than user choice to continue/not-continue to participate i= n the chat.

As 'user choice" was the only variable, user ch= oice was also the differentiator - including (big picture) the choice to us= e an individual group chat *or* a messenger platform that was overtly enabl= ed for state surveillance. The choice to pull that surveilled=C2=A0chat or = that=C2=A0surveilled platform into one's own TCB/Trusted Compute Base/Z= one of Trust, was a user choice.

Perspective

In short:= I think that "end-to-end secure messaging with state surveillance ove= rtly and transparently baked-in", is precisely *that*, and should be h= ighlighted as such, for exactly the reasons as explained in RFC2804.= Thus if people want to avoid surveillance, they should vote with their fee= t and use a different platform, or obtain a different government; however t= he surveillance should never be opaque, ghostly, or hidden.

What do = others think, please?

- alec

--000000000000c2e3ab05c83410a4-- From nobody Thu Jul 29 02:55:00 2021 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 CDEB63A1BC2 for ; Thu, 29 Jul 2021 02:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 PYB8eAB1gEw3 for ; Thu, 29 Jul 2021 02:54:53 -0700 (PDT) Received: from mx3.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 90A073A1BC1 for ; Thu, 29 Jul 2021 02:54:53 -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 F2BC36A0EE; Thu, 29 Jul 2021 11:54:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1627552491; bh=kNmgM69AIk/w5P9pwxwh3lR67b8GMKEctAjlgOLqG4I=; h=Date:From:To:In-Reply-To:References:Subject:From; b=rOTAT0lpMRzSGu02PdHaH7y12YsuQ/+D25yEFG+QupSLPhhNX3RMWe2OcnLtXAwyd ikK92ZpZxsh00TQcIfalp4FlOfJuYerzRFIgOzfezaZ65oaurXH6FkJ/sij+Vlfq8i 3sGSXipYY1wPmzF1RGWLMTlFoS1hamSjHYPo3jqHasG5TGNxtoMNzLSYU19p+suNGX AmreKoPoIradOwo7IWaJ1VZVe63V/yWyTetThh5dkYPDoeeg1j3H1NGxO6QNkY+CLD TiiOrs++64PKeCBUZ7DU2wqlJtspeQOjmTn4+z9H8HW0GOtBA96YHftwo4DeYCGLWd tA/iEAtFkGeVg== Received: from appsuite-gw1.open-xchange.com ([10.20.28.81]) by imap.open-xchange.com with ESMTPSA id k8s7O+p6AmH4SgAA3c6Kzw (envelope-from ); Thu, 29 Jul 2021 11:54:50 +0200 Date: Thu, 29 Jul 2021 11:54:50 +0200 (CEST) From: Vittorio Bertola To: Alec Muffett , e2ee@ietf.org Message-ID: <238644631.6269.1627552490927@appsuite-gw1.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6267_1291397901.1627552490911" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev18 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] Does the presence of overt, "Non-Ghost" surveillance actors/bots, inhibit E2E Security? X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 09:54:59 -0000 ------=_Part_6267_1291397901.1627552490911 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 28/07/2021 21:33 Alec Muffett ha scritto: > > > Hi All! > > I'll be presenting this to the CFRG (Crypto Forum Research Group) at IETF 111, late on Friday evening (London time): > > "A 'Duck Test' for End-to-End Secure Messaging" > https://alecmuffett.com/alecm/ietf-111/draft-muffett-e2esm-v1.18a.pdf > > It's a reasonably short presentation-deck (albeit with a lot of slides) offering a simple, robust, and easily understood metric for people to use when judging assertions like: > > "The GCHQ 'Ghost' Proposal does not harm End-to-End Security" > > One interesting discussion that I *have* had, twice, regarding my draft is regarding (Slide 25) whether "overt, blatant surveillance" inhibits a system from being E2E-Secure - "because people will not be able to avoid surveillance." > > It's a great question, which I've answered with two different thought experiments: > > Surveillance Scenario A: > > Imagine that the UK Government imposes a "Technical Capability Notice" on WhatsApp and requires surveillance on everybody. Further imagine that WhatsApp has the decency to tell everybody that surveillance is enabled. > > Then Alice, in the UK, wants to talk to Bob with WhatsApp, but without Surveillance. What does Alice do? Answer: there is nothing she can do except "Fix the Government" or "Select a platform which does not implement surveillance on behalf of the UK Government". Her intentions or desires are incapable of changing anything about the situation, other than via political means. > > Surveillance Scenario B: > > Say that you are using Signal to hold a group chat, and suddenly after a month or so, it gets out that one of the people in the group chat ("Eve?") is actually a member of the state security services. > > Would that mean that Signal was suddenly no longer end-to-end encrypted? No. If one did believe that, then E2E would have a "Schrodinger's Cat"-quality - that it stops being E2E as soon as a spook looks at it. > > But if the presence of unknown surveillance does not prevent something being end-to-end encrypted, would the presence of *known* surveillance, up-front, prevent something being considered end-to-end encrypted? Well, when Eve was "outed", nothing has changed with the system other than user choice to continue/not-continue to participate in the chat. > > As 'user choice" was the only variable, user choice was also the differentiator - including (big picture) the choice to use an individual group chat *or* a messenger platform that was overtly enabled for state surveillance. The choice to pull that surveilled chat or that surveilled platform into one's own TCB/Trusted Compute Base/Zone of Trust, was a user choice. > > Perspective > > In short: I think that "end-to-end secure messaging with state surveillance overtly and transparently baked-in", is precisely *that*, and should be highlighted as such, for exactly the reasons as explained in RFC2804. Thus if people want to avoid surveillance, they should vote with their feet and use a different platform, or obtain a different government; however the surveillance should never be opaque, ghostly, or hidden. > > What do others think, please? > I think that you are mixing three separate concepts: 1) end-to-end encryption, which is a technical property of a communication system; 2) end-to-end security, which is a somewhat abstract concept possibly including other factors than just the communication system; 3) an appropriate disclosure policy for lawful interception, which is interesting but possibly out of scope for the IETF, and more in scope for law-making venues. By the way, the apps you mention (Whatsapp and Signal) do not provide "end-to-end encryption" but "managed end-to-end encryption" - exactly for the reason you point out. A communication is end-to-end-encrypted if the text enters the communication system already encrypted; otherwise, if the communication system also manages your keys and the encryption/decryption procedure, the content is not a secret between the sender and the recipient, but only a secret between the sender, the recipient and the application maker, who could easily include features to screen and report your communication before encrypting it, either to its own servers for business purposes, or, as you suggest, to a third party. Of course, managed e2ee is much easier to use while still providing a good degree of protection, but it requires you to trust the provider of the communication system, and there are clear reasons why people who really need absolute protection from any kind of screening should not rely on it; they should only encrypt and decrypt messages on trusted, separate applications that are not connected to the Internet. But even the average user should be made aware of the risks of managed e2ee, as it's unclear why a for-profit should provide a free communication app without monetizing users in any way; users might then want to pick a provider which is less likely to monetize them. In terms of #3, I'm not sure if it's on topic, but I will note that by definition lawful interception happens according to a law, so the fact that it exists is public. What you as a user do not generally know is if it has been turned on on your account, but there are reasons for that, and also - in democratic countries - appropriate guarantees. Nothing would anyway prevent the app from reminding that, in some cases, your communications could be reported according to a law or court order. -- 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 ------=_Part_6267_1291397901.1627552490911 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 28/07/2021 21:33 Alec Muffett <alec.muffett@gmail.com> ha scritto:


Hi All!

I'll be presenting this to the CFRG (Crypto Forum Research Group) at IETF 111, late on Friday evening (London time):

"A 'Duck Test' for End-to-End Secure Messaging" 
https://alecmuffett.com/alecm/ietf-111/draft-muffett-e2esm-v1.18a.pdf

It's a reasonably short presentation-deck (albeit with a lot of slides) offering a simple, robust, and easily understood metric for people to use when judging assertions like:

"The GCHQ 'Ghost' Proposal does not harm End-to-End Security"
One interesting discussion that I *have* had, twice, regarding my draft is regarding (Slide 25) whether "overt, blatant surveillance" inhibits a system from being E2E-Secure - "because people will not be able to avoid surveillance."

It's a great question, which I've answered with two different thought experiments:

Surveillance Scenario A:
Imagine that the UK Government imposes a "Technical Capability Notice" on WhatsApp and requires surveillance on everybody. Further imagine that WhatsApp has the decency to tell everybody that surveillance is enabled.

Then Alice, in the UK, wants to talk to Bob with WhatsApp, but without Surveillance. What does Alice do? Answer: there is nothing she can do except "Fix the Government" or "Select a platform which does not implement surveillance on behalf of the UK Government". Her intentions or desires are incapable of changing anything about the situation, other than via political means.

Surveillance Scenario B:
Say that you are using Signal to hold a group chat, and suddenly after a month or so, it gets out that one of the people in the group chat ("Eve?") is actually a member of the state security services.

Would that mean that Signal was suddenly no longer end-to-end encrypted? No. If one did believe that, then E2E would have a "Schrodinger's Cat"-quality - that it stops being E2E as soon as a spook looks at it.

But if the presence of unknown surveillance does not prevent something being end-to-end encrypted, would the presence of *known* surveillance, up-front, prevent something being considered end-to-end encrypted? Well, when Eve was "outed", nothing has changed with the system other than user choice to continue/not-continue to participate in the chat.

As 'user choice" was the only variable, user choice was also the differentiator - including (big picture) the choice to use an individual group chat *or* a messenger platform that was overtly enabled for state surveillance. The choice to pull that surveilled chat or that surveilled platform into one's own TCB/Trusted Compute Base/Zone of Trust, was a user choice.

Perspective
In short: I think that "end-to-end secure messaging with state surveillance overtly and transparently baked-in", is precisely *that*, and should be highlighted as such, for exactly the reasons as explained in RFC2804. Thus if people want to avoid surveillance, they should vote with their feet and use a different platform, or obtain a different government; however the surveillance should never be opaque, ghostly, or hidden.

What do others think, please?
I think that you are mixing three separate concepts:
1) end-to-end encryption, which is a technical property of a communication system;
2) end-to-end security, which is a somewhat abstract concept possibly including other factors than just the communication system;
3) an appropriate disclosure policy for lawful interception, which is interesting but possibly out of scope for the IETF, and more in scope for law-making venues.

By the way, the apps you mention (Whatsapp and Signal) do not provide "end-to-end encryption" but "managed end-to-end encryption" - exactly for the reason you point out. A communication is end-to-end-encrypted if the text enters the communication system already encrypted; otherwise, if the communication system also manages your keys and the encryption/decryption procedure, the content is not a secret between the sender and the recipient, but only a secret between the sender, the recipient and the application maker, who could easily include features to screen and report your communication before encrypting it, either to its own servers for business purposes, or, as you suggest, to a third party.

Of course, managed e2ee is much easier to use while still providing a good degree of protection, but it requires you to trust the provider of the communication system, and there are clear reasons why people who really need absolute protection from any kind of screening should not rely on it; they should only encrypt and decrypt messages on trusted, separate applications that are not connected to the Internet. But even the average user should be made aware of the risks of managed e2ee, as it's unclear why a for-profit should provide a free communication app without monetizing users in any way; users might then want to pick a provider which is less likely to monetize them.

In terms of #3, I'm not sure if it's on topic, but I will note that by definition lawful interception happens according to a law, so the fact that it exists is public. What you as a user do not generally know is if it has been turned on on your account, but there are reasons for that, and also - in democratic countries - appropriate guarantees. Nothing would anyway prevent the app from reminding that, in some cases, your communications could be reported according to a law or court order.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_6267_1291397901.1627552490911-- From nobody Thu Jul 29 07:12:46 2021 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 1485F3A2410 for ; Thu, 29 Jul 2021 07:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 J-W53aCqEkZC for ; Thu, 29 Jul 2021 07:12:40 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 496143A2406 for ; Thu, 29 Jul 2021 07:12:40 -0700 (PDT) Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4GbCCq54VSzDq81 for ; Thu, 29 Jul 2021 07:12:39 -0700 (PDT) X-Riseup-User-ID: 2D3C77FE2E24DD0C856E5F1075E0824F708A82B3275CA88021CA5F15F64FF192 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4GbCCn6X6pz5vcc for ; Thu, 29 Jul 2021 07:12:35 -0700 (PDT) Date: Thu, 29 Jul 2021 14:12:30 +0000 From: Matthew Finkel To: e2ee@ietf.org Message-ID: <20210729141230.p62bwxrh6shysjkq@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Archived-At: Subject: [E2ee] Reducing Plaintext Metadata in E2EE Systems X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 14:12:45 -0000 Hi all, This draft is very valuable, thanks to the authors for writing it. I'd like to call more attention to the importance of reducing plaintext metadata. The current draft contains: Existing protocols are vulnerable to meta-data analysis, even though meta-data is often much more sensitive than content. Meta-data is plaintext information that travels across the wire and includes delivery-relevant details that central servers need such as the account identity of end-points, timestamps, message size. Meta-data is difficult to obfuscate efficiently. The phrasing of this paragraph leads me to wonder if obfuscation of metadata should be included as a desirable feature. I don't mean to imply it's possible to eliminate leaking all metadata in all E2EE systems, but there is often some low-hanging fruit, like IP addresses or non-routing metadata, that an E2EE system can try to protect or obfuscate; e.g., MASQUE/OHTTP/Tor for IP addresses, and [0][1] for protecting some extraneous message headers. I can open a PR if this is helpful. Thanks, Matthew Finkel [0] https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers [1] https://signal.org/blog/sealed-sender/ From nobody Thu Jul 29 07:27:44 2021 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 7502E3A247E for ; Thu, 29 Jul 2021 07:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 7GHim9rROPWZ for ; Thu, 29 Jul 2021 07:27:38 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD2D3A2483 for ; Thu, 29 Jul 2021 07:27:37 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id d9so4018732qty.12 for ; Thu, 29 Jul 2021 07:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=qndTgc4u3uoVjWq9GDl5vg4e2ljGe7hRfCU11ino8JA=; b=G6B7jOXqJx66+9K2/cV3TO4B+1d9qOfAh2f2nQlJQXqfLps+sOMbi6MzqrXIfjOQgh 3zQag3Bfmg5Hu/1ct1oGsIELRQ1p0oilAVoCwi52uqHVK+4vTO2r4NKkNhMBTMK4jh8t sx7929PAjFaoeuDuGZfPqoSwEOjyrrw36bV28= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=qndTgc4u3uoVjWq9GDl5vg4e2ljGe7hRfCU11ino8JA=; b=kBT5rnrBfQ8uyG42JZwIO1TlI5f2rmrMWf3L8yMLsuei2XuGrZB1UOe1cVX645Ug8O 6OLa/AO2dhjmfZKVjVjshf5DG0/A+/buafLMC74NVjMuuRF6lDJGG4zBjt0GYakSMnvn 0KgN945etNJrBaOuPvMuYEALkgRiezuJGyfFSJTAP63Pb7Yb+WN4rH9eGHxWgR/SiZ55 dI4urOEjdMfPRFjwukFWPfRSVoaYWUoU6c4MtOz/fxhLeKv3ti/vd+zni4InDryxgCs5 SQdTbtMkMAfiP2lYOw5Y9zfklV8cKLz3pNzQXqpxR9wmsHYOmHGsBUBm7CNw+8FfDR10 1fgg== X-Gm-Message-State: AOAM532UGKYxMTlNtxBMmHMdSwMGET6lQb1JShEnkT7cbxgTzBdGQBAe yTYfUaerPyPlm3jAbZprHHpIkA== X-Google-Smtp-Source: ABdhPJxptZco1oiME2ry+nwq0TTVqjByPiE/YWm1YQ+vRzmfLS9xFWjI77feiMRRZ08J2Yp/hhzfYA== X-Received: by 2002:ac8:764e:: with SMTP id i14mr4442610qtr.247.1627568856230; Thu, 29 Jul 2021 07:27:36 -0700 (PDT) Received: from ?IPV6:2601:14d:8300:7fa0:9c9b:845b:634f:7a0b? ([2601:14d:8300:7fa0:9c9b:845b:634f:7a0b]) by smtp.gmail.com with UTF8SMTPSA id m19sm1245246qtx.84.2021.07.29.07.27.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 07:27:35 -0700 (PDT) Message-ID: Date: Thu, 29 Jul 2021 10:27:34 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.0 Content-Language: en-US To: Matthew Finkel , e2ee@ietf.org References: <20210729141230.p62bwxrh6shysjkq@localhost> From: Mallory Knodel In-Reply-To: <20210729141230.p62bwxrh6shysjkq@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [E2ee] Reducing Plaintext Metadata in E2EE Systems X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 14:27:43 -0000 Thanks a lot Matthew, I agree that this should be a goal. Not all of the features should or could be part of every e2ee system, but the draft should demonstrate the "trajectory" of where the technology goes ideally. Please do create a PR, I would be happy to review and merge. -Mallory On 7/29/21 10:12 AM, Matthew Finkel wrote: > Hi all, > > This draft is very valuable, thanks to the authors for writing it. I'd > like to call more attention to the importance of reducing plaintext > metadata. The current draft contains: > > Existing protocols are vulnerable to meta-data analysis, even though > meta-data is often much more sensitive than content. Meta-data is > plaintext information that travels across the wire and includes > delivery-relevant details that central servers need such as the > account identity of end-points, timestamps, message size. Meta-data > is difficult to obfuscate efficiently. > > The phrasing of this paragraph leads me to wonder if obfuscation of > metadata should be included as a desirable feature. I don't mean to > imply it's possible to eliminate leaking all metadata in all E2EE > systems, but there is often some low-hanging fruit, like IP addresses or > non-routing metadata, that an E2EE system can try to protect or > obfuscate; e.g., MASQUE/OHTTP/Tor for IP addresses, and [0][1] for > protecting some extraneous message headers. I can open a PR if this is > helpful. > > Thanks, > Matthew Finkel > > [0] https://datatracker.ietf.org/doc/html/draft-autocrypt-lamps-protected-headers > [1] https://signal.org/blog/sealed-sender/ > -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Thu Jul 29 11:01:35 2021 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 718303A12CF for ; Thu, 29 Jul 2021 11:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WQ3xTHkx5qpK for ; Thu, 29 Jul 2021 11:01:28 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AC83A12CD for ; Thu, 29 Jul 2021 11:01:28 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id az7so6838287qkb.5 for ; Thu, 29 Jul 2021 11:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5qNmUcjYeeACiHYy9V9qmkSYvdBbflwVTzpXeVqcTZ4=; b=DNHcdGM14sUDRLVdnvOHO3uHl4rNx/Txm1g9zGMu6hcqCz07QIK7HDlLNCWOqTjEpX oFDvtFiaBrhplI9YGGZjCAHyMgc1ApDBpdBFkzZk6oYhxu5Dz9OYsl1pC87tbYh0jDu/ wW6KgZ4NW0qpFHjfLWaLXGD3aV/U8ZqzoAGfCbDgk75BJmF9X234eyNA21pUXqI1zhXv gCO83y4yjer3WSgsIbkkWkuJ79DarCUrABl7zFvadQd747kB1HuGmh4yxWS8jDXnH5W5 AFUB4KDw6NCXwV9GjD9+IfKFE8C7fOhp7wIoNLCkynXp2VDglPoq1tMpJMvac1QPd3yI JGbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5qNmUcjYeeACiHYy9V9qmkSYvdBbflwVTzpXeVqcTZ4=; b=EQsMRfrqxMsLGHPdd12v/1sqR4jrhSsltmbev/0m2vU/I9LHWndF3+CHO4WeTMg9Cl p6Z7sZOoltColav/gi6/SK3E91p9jkDwYf3/stAjGxFJq6ZehF33EFGBVQSVlH8z/7d+ U1KXAdU69Rld6ZhujV5JZ9xPKvCYhnBkFH3JLXM7d28J1996n+7meMSmSHaeT2/P/4km qMscmw74FyjxYv99+m6IxBg/UZ7obPnO1eEgIcqz6T3bRByrL+4KloOo26JyIm0EyoI5 SgRJoyixtGiirbzM/XCoLUZmh30DwTRJv+ZSAPFnTNE8VeEIB3E2/NmRg1KdIJoN1Vpn aPqQ== X-Gm-Message-State: AOAM531YI+zPgVMkClIjniwJRW2Wnb4S8L/4Z6t9u9SFakNnqrSyP6GF wFczGgGKRVWPPeLri6DXSX+dYVIjv2PKYXTnvBFtoEuGpyg= X-Google-Smtp-Source: ABdhPJz+fcWlhbCaPuJ/ZkZ3SjNQwUIhlaiNSKHwt+sKehLIkjFq24ptKcKQBHrq2UVX4NxFCCvijmJttwh77EKUg5E= X-Received: by 2002:a05:620a:129a:: with SMTP id w26mr6376614qki.330.1627581686475; Thu, 29 Jul 2021 11:01:26 -0700 (PDT) MIME-Version: 1.0 References: <238644631.6269.1627552490927@appsuite-gw1.open-xchange.com> In-Reply-To: <238644631.6269.1627552490927@appsuite-gw1.open-xchange.com> From: Alec Muffett Date: Thu, 29 Jul 2021 19:00:50 +0100 Message-ID: To: Vittorio Bertola Cc: e2ee@ietf.org Content-Type: multipart/alternative; boundary="00000000000043efac05c846e4a2" Archived-At: Subject: Re: [E2ee] Does the presence of overt, "Non-Ghost" surveillance actors/bots, inhibit E2E Security? X-BeenThere: e2ee@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 18:01:34 -0000 --00000000000043efac05c846e4a2 Content-Type: text/plain; charset="UTF-8" Hi Vittorio - nice to talk to you again! On Thu, 29 Jul 2021 at 10:54, Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > I think that you are mixing three separate concepts: > 1) end-to-end encryption, which is a technical property of a communication system; > 2) end-to-end security, which is a somewhat abstract concept possibly including other factors than just the communication system; > 3) an appropriate disclosure policy for lawful interception, which is interesting but possibly out of scope for the IETF, and more in scope for law-making venues. Yes, I am. I feel that it is proper and appropriate, given that I am also placing bounds upon how they are being discussed. > By the way, the apps you mention (Whatsapp and Signal) do not provide "end-to-end encryption" but "managed end-to-end encryption" [deletia] I will let you argue definitions of end-to-end encryption with the people authoring the relevant draft for that term; my work is focused narrowly upon "end-to-end secure messaging". > Of course, managed e2ee is much easier to use while still providing a good degree of protection, but it requires you to trust the provider of the communication system, and there are clear reasons why people who really need absolute protection from any kind of screening should not rely on it; Absolutely - the exercise of user choice to import (say) Signal into one's Trusted Compute Base, is a huge and somewhat blind leap of (reputation-based?) trust. > In terms of #3, I'm not sure if it's on topic, but I will note that by definition lawful interception happens according to a law, so the fact that it exists is public. What you as a user do not generally know is if it has been turned on on your account, but there are reasons for that, and also - in democratic countries - appropriate guarantees. Nothing would anyway prevent the app from reminding that, in some cases, your communications could be reported according to a law or court order. Exactly so, per slide 25 at https://alecmuffett.com/alecm/ietf-111/draft-muffett-e2esm-v1.18a.pdf perhaps something like: > Messages you send to this chat and calls are now secured with end-to-end encryption, but may be subject to interception or review by ourselves, and law enforcement, safety communities, and outsourced agents from the following national governments that we have determined from your profile information: [...] ...might be appropriate for people who live in, or cross-, jurisdictions that do not permit them to communicate privately. You know, totalitarian states. That sort of thing. -a -- https://alecmuffett.com/about --00000000000043efac05c846e4a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vittorio - nice to talk to you again!

On Thu, 29= Jul 2021 at 10:54, Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
>=
> I think that you are mixing three separate concepts:
> 1) e= nd-to-end encryption, which is a technical property of a communication syst= em;
> 2) end-to-end security, which is a somewhat abstract concept po= ssibly including other factors than just the communication system;
> = 3) an appropriate disclosure policy for lawful interception, which is inter= esting but possibly out of scope for the IETF, and more in scope for law-ma= king venues.

Yes, =C2=A0I am.=C2=A0 I feel that it is proper and app= ropriate, given that I am also placing bounds upon how they are being discu= ssed.


> By the way, the apps you mention (Whatsapp and Signal= ) do not provide "end-to-end encryption" but "managed end-to= -end encryption" [deletia]

I will let you argue definitions of = end-to-end encryption with the people authoring the relevant draft for that= term; my work is focused narrowly upon "end-to-end secure messaging&q= uot;.

> Of course, managed e2ee is much easier to use while still= providing a good degree of protection, but it requires you to trust the pr= ovider of the communication system, and there are clear reasons why people = who really need absolute protection from any kind of screening should not r= ely on it;

Absolutely - the exercise of user choice to import (say) = Signal into one's Trusted Compute Base, is a huge and somewhat blind le= ap of (reputation-based?) trust.


> In terms of #3, I'm no= t sure if it's on topic, but I will note that by definition lawful inte= rception happens according to a law, so the fact that it exists is public. = What you as a user do not generally know is if it has been turned on on you= r account, but there are reasons for that, and also - in democratic countri= es - appropriate guarantees. Nothing would anyway prevent the app from remi= nding that, in some cases, your communications could be reported according = to a law or court order.

Exactly so, per slide 25 at https:/= /alecmuffett.com/alecm/ietf-111/draft-muffett-e2esm-v1.18a.pdf perhaps = something like:

> Messages you send to this chat and calls are no= w secured with end-to-end encryption, but may be subject to interception or= =E2=80=A8review by ourselves, and law enforcement, safety communities, and = outsourced agents from the following national governments that we have dete= rmined from your profile information: [...]

=C2=A0...might be approp= riate for people who live in, or cross-, jurisdictions that do not permit t= hem to communicate privately.=C2=A0 You know, totalitarian=C2=A0states.=C2= =A0 That sort of thing.
--00000000000043efac05c846e4a2--