Re: [E2ee] Does the presence of overt, "Non-Ghost" surveillance actors/bots, inhibit E2E Security?

Vittorio Bertola <vittorio.bertola@open-xchange.com> Thu, 29 July 2021 09:54 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 CDEB63A1BC2 for <e2ee@ietfa.amsl.com>; 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 <e2ee@ietfa.amsl.com>; 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 <e2ee@ietf.org>; 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 <vittorio.bertola@open-xchange.com>); Thu, 29 Jul 2021 11:54:50 +0200
Date: Thu, 29 Jul 2021 11:54:50 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Alec Muffett <alec.muffett@gmail.com>, e2ee@ietf.org
Message-ID: <238644631.6269.1627552490927@appsuite-gw1.open-xchange.com>
In-Reply-To: <CAFWeb9JvrpHwsYXADHvAA4Do4OzQiNMCmTyY-QHHgu2MqHAeYg@mail.gmail.com>
References: <CAFWeb9JvrpHwsYXADHvAA4Do4OzQiNMCmTyY-QHHgu2MqHAeYg@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/e2ee/yVbGGH4fczswqLNTIFneKQftiHk>
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: <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: Thu, 29 Jul 2021 09:54:59 -0000

>     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 mailto:vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy