draft-muffett-end-to-end-secure-messaging-04.txt

individual submission                                         A. Muffett
Internet-Draft                                       Security Researcher
Intended status: Informational                          15 December 2021
Expires: 18 June 2022


 Test to Falsify Claims of End-to-End Security or End-to-End Encryption
           in Encrypted Messenger or Encrypted Messaging Apps
              draft-muffett-end-to-end-secure-messaging-04

Abstract

   This draft describes a test which MAY be used to falsify claims that
   a messaging or messenger application, platform, solution, or service
   ("messaging solution") provides either or both of "end-to-end
   security" or "end-to-end encryption". (either/both: "E2E")

   Any messaging solution, or clearly defined subset thereof, which
   claims to provide E2E, MUST satisfy this test; however satisfaction
   of this test is not wholly sufficient to determine that the messaging
   solution actually provides E2E.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 June 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights



Muffett                   Expires 18 June 2022                  [Page 1]

Internet-Draft                    e2esm                    December 2021


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Comments  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Content . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Metadata and PCASM  . . . . . . . . . . . . . . . . . . .   4
       2.3.1.  Content Metadata  . . . . . . . . . . . . . . . . . .   4
       2.3.2.  Size Metadata . . . . . . . . . . . . . . . . . . . .   4
       2.3.3.  Analytic Metadata . . . . . . . . . . . . . . . . . .   5
     2.4.  Message and Intended Recipients . . . . . . . . . . . . .   5
     2.5.  Recipient . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  Sender  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.7.  Platform  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.8.  Conversation and Group Conversation . . . . . . . . . . .   5
     2.9.  Backdoor  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Test Preconditions  . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Recipients are Peers  . . . . . . . . . . . . . . . . . .   6
     3.2.  Groups are closed from within . . . . . . . . . . . . . .   6
     3.3.  Re-injection of old content is legitimate . . . . . . . .   6
     3.4.  Consistent inheritance of group membership as intended
           recipients in centralized messaging solutions . . . . . .   6
   4.  Test  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  OLD MATERIAL BELOW THESE LINES  . . . . . . . . . . . . . . .   6
     6.1.  OLD MATERIAL BELOW THESE LINES  . . . . . . . . . . . . .   6
       6.1.1.  OLD MATERIAL BELOW THESE LINES  . . . . . . . . . . .   6
     6.2.  Conversation, Group, Centralised & Decentralised  . . . .   6
   7.  Principles  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Transparency of Participation . . . . . . . . . . . . . .   7
     7.2.  Integrity of Participation  . . . . . . . . . . . . . . .   7
       7.2.1.  Retransmission Exception  . . . . . . . . . . . . . .   7
     7.3.  Equality of Participation . . . . . . . . . . . . . . . .   8
     7.4.  Closure of Conversation . . . . . . . . . . . . . . . . .   8
       7.4.1.  Public Conversations and Self-Subscription  . . . . .   8
     7.5.  Management of Participant Clients and Devices . . . . . .   8
   8.  Rationales  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Why: Content PCASM  . . . . . . . . . . . . . . . . . . .   8
     8.2.  Why: Size PCASM . . . . . . . . . . . . . . . . . . . . .   9
     8.3.  Why: Analytic PCASM . . . . . . . . . . . . . . . . . . .   9
     8.4.  Why: Conversation Metadata as OPTIONAL PCASM  . . . . . .   9



Muffett                   Expires 18 June 2022                  [Page 2]

Internet-Draft                    e2esm                    December 2021


     8.5.  Why: Entity and Participant . . . . . . . . . . . . . . .   9
     8.6.  Why: Transparency of Participation  . . . . . . . . . . .  10
     8.7.  Why: Integrity of Participation . . . . . . . . . . . . .  10
     8.8.  Why: Equality of Participation  . . . . . . . . . . . . .  11
     8.9.  Why: Closure of Conversation  . . . . . . . . . . . . . .  11
     8.10. Why: Management of Participant Clients and Devices  . . .  11
   9.  OPTIONAL Features of E2ESM  . . . . . . . . . . . . . . . . .  12
     9.1.  Disappearing Messages . . . . . . . . . . . . . . . . . .  12
     9.2.  Mutual Identity Verification  . . . . . . . . . . . . . .  12
   10. Examples of PCASM . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Content PCASM  . . . . . . . . . . . . . . . . . . . . .  12
     10.2.  Size PCASM . . . . . . . . . . . . . . . . . . . . . . .  13
     10.3.  Analytic PCASM . . . . . . . . . . . . . . . . . . . . .  13
     10.4.  Conversation Metadata as OPTIONAL PCASM  . . . . . . . .  13
     10.5.  Non-PCASM  . . . . . . . . . . . . . . . . . . . . . . .  13
   11. See Also  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   12. Live Drafts . . . . . . . . . . . . . . . . . . . . . . . . .  14
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   15. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   "End-to-end security" and "end-to-end encryption" offer digital
   analogues of "closed distribution lists" for sharing content amongst
   a set of intended recipients, where all others are fully excluded
   from access to content.

   This draft assumes a specific application of "end-to-end security" or
   "end-to-end encryption" towards the specific use case of individual
   and group messaging solutions where entities who are later added to a
   messaging group MUST NOT be able to access previously-sent content.

   In turn, use cases for such messaging solutions include the sending
   and receiving of any or all of:

   1.  UNICODE or ASCII messages
   2.  images, video files or audio files
   3.  one-way streaming video or audio
   4.  two-way streaming video or audio, as in live calls

   The application of this test does not depend upon whether the
   messaging solution is built upon a centralized, distributed, hybrid,
   or any other network model.






Muffett                   Expires 18 June 2022                  [Page 3]

Internet-Draft                    e2esm                    December 2021


1.1.  Comments

   Comments are solicited and should be addressed to the working group's
   mailing list and/or the author(s).

1.2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Definitions

   The following terminology SHALL be used for this test.

2.1.  Entity

   An "entity" is that which is distingushed by possessing a distinct
   [TrustedComputingBase]

   Use cases of an entity MAY include being a human being, a software
   bot, a conversation archiver, or something other which sends and/or
   receives messages.

2.2.  Content

   Plaintext content ("content") is information of 0 or more bits, to be
   communicated.

2.3.  Metadata and PCASM

   Plaintext content and sensitive metadata ("PCASM") is the union set
   of content and associated "metadata" that describes the content,
   comprising any or all of:

2.3.1.  Content Metadata

   Content Metadata is any data that can offer better than 50% certainty
   regarding the value of any bit of the content.  Self-evidently, this
   also includes the value of the content itself.

2.3.2.  Size Metadata

   1.  For block encryption of content, "size metadata" is the unpadded
       size of the content.




Muffett                   Expires 18 June 2022                  [Page 4]

Internet-Draft                    e2esm                    December 2021


   2.  For stream encryption of content, "size metadata" is currently
       undefined.  (TODO)
   3.  For transport encryption of content, accurate "size metadata"
       SHOULD NOT be observable or inferable.

2.3.3.  Analytic Metadata

   Analytic Metadata is data that analyses, describes, reduces, or
   summarises the content.

2.4.  Message and Intended Recipients

   A "message" is zero-or-more bits of content which has been composed
   by a sender and which is bound to a fixed and immutable set of zero
   or more recipients ("intended recipients") for that message.

2.5.  Recipient

   A "recipient" of a message is an entity which MAY derive any PCASM
   for that message.  Recipients of a message MAY exist outside of the
   set of intended recipients for that message.  Means of derivation MAY
   include analysis of a larger corpus of messages.

2.6.  Sender

   The "sender" of a message is an entity which composes that message to
   a set of intended recipients and sends that message into the
   messaging solution.

2.7.  Platform

   A "platform" is an entity which provides a messaging solution.

2.8.  Conversation and Group Conversation

   TODO

2.9.  Backdoor

   A "backdoor" is any intentional or unintentional feature of a
   messaging solution whereby, in respect of a given message some PCASM
   of that message MAY become available to an entity that is not an
   intended recipient of that message, other than by the intentional
   action of an intended recipient.







Muffett                   Expires 18 June 2022                  [Page 5]

Internet-Draft                    e2esm                    December 2021


3.  Test Preconditions

   The following preconditions MUST be met for the test to be satisfied.
   Failure to satisfy these preconditions is a failure of the test.

3.1.  Recipients are Peers

   For any message, there exists no method to access its PCASM where
   that method is not equally available to all recipients.

3.2.  Groups are closed from within

   TODO, obvious

3.3.  Re-injection of old content is legitimate

   TODO, obvious

3.4.  Consistent inheritance of group membership as intended recipients
      in centralized messaging solutions

   TODO, no cheating or sneaky insert/elisions

4.  Test

   The test fails if, for any message that is sent through the messaging
   solution, the set of recipients for that message exceeds the set of
   intended recipients for that message.

5.  Analysis

   TODO, non-PCASM, stuff out of scope, Ricochet, etc.

6.  OLD MATERIAL BELOW THESE LINES

6.1.  OLD MATERIAL BELOW THESE LINES

6.1.1.  OLD MATERIAL BELOW THESE LINES

6.1.1.1.  OLD MATERIAL BELOW THESE LINES

6.1.1.1.1.  OLD MATERIAL BELOW THESE LINES

6.2.  Conversation, Group, Centralised & Decentralised

   A "conversation" is a sequence of one or more messages, and the
   responses or replies to them, over a period of time, amongst a
   constant or evolving set of participants.



Muffett                   Expires 18 June 2022                  [Page 6]

Internet-Draft                    e2esm                    December 2021


   A given platform MAY distinguish between and support more than one
   conversation at any given time.

   In "centralised" E2ESM such as WhatsApp or Signal, the software MAY
   offer collective "group" conversation contexts that provide
   prefabricated sets of recipients for the client to utilise when a
   message is composed or sent.

   In "decentralised" E2ESM such as PGP-Encrypted Email or Ricochet the
   recipients of each message are individually determined by each sender
   at the point of composition; however "group" metadata may also exist,
   in terms of (e.g.) email addressees or subject lines.

7.  Principles

   For a series of one or more "messages" each which are composed of
   "plaintext content and sensitive metadata" (PCASM) and which
   constitute a "conversation" amongst a set of "participants", to
   provide E2ESM will require:

7.1.  Transparency of Participation

   In the nature of "closed distribution lists", the participants in a
   message MUST be frozen into an immutable set at the moment when the
   message is composed or sent.

   The complete set of all recipients MUST be visible to the sender at
   the moment of message composition or sending.

   The complete set of participants in a message MUST be visible to all
   other participants.

7.2.  Integrity of Participation

   Excusing the "retransmission exception", PCASM of any given message
   MUST only be available to the fixed set of conversation participants
   from whom, to whom, and at the time when it was sent.

7.2.1.  Retransmission Exception

   If a participant that can access an "original" message intentionally
   "retransmits" (e.g. quotes, forwards) that message to create a new
   message within the E2ESM software, then the original message's PCASM
   MAY become available to a new, additional, and possibly different set
   of conversation participants, via that new message.






Muffett                   Expires 18 June 2022                  [Page 7]

Internet-Draft                    e2esm                    December 2021


7.3.  Equality of Participation

   All participants MUST be peers, i.e. they MUST have equal access to
   the PCASM of any message; see also "Integrity of Participation".

7.4.  Closure of Conversation

   The set of participants in a conversation SHALL NOT be increased
   except by the intentional action of one or more existing
   participants.

   Per "Transparency of Participation" that action (introducing a new
   participant) MUST be visible to all other participants

7.4.1.  Public Conversations and Self-Subscription

   Existing participants MAY publicly share links to the conversation,
   identifying data to assist discovery of the conversation, or other
   mechanisms to enable non-participant entities to subscribe themselves
   as conversation participants.  This MAY be considered legitimate
   "intentional action" to increase the set of participants in the
   group.

7.5.  Management of Participant Clients and Devices

   Where there exists centralised E2ESM software that hosts
   participants:

   1.  The E2ESM software MUST provide each participant entity with
       means to review or revoke access for that participant's clients
       or devices that can access future PCASM.

   2.  The E2ESM software MUST provide each participant entity with
       notifications and/or complete logs of changes to the set of
       clients or devices that can or could access message PCASM.

8.  Rationales

   This explanatory section regarding the principles has been broken out
   for clarity and argumentation purposes.

8.1.  Why: Content PCASM

   Content PCASM MUST be protected as it comprises that which is
   "closed" from general distribution.

   The test for measuring this is (intended to be) modeled upon
   ciphertext indistinguishability [CipherInd]



Muffett                   Expires 18 June 2022                  [Page 8]

Internet-Draft                    e2esm                    December 2021


8.2.  Why: Size PCASM

   Exact size PCASM MUST be protected as it MAY offer insight into
   Content PCASM.

   The test for measuring this is (intended) to address risk of content
   becoming evident via plaintext length.

8.3.  Why: Analytic PCASM

   Analytic PCASM MUST be protected as it MAY offer insight into Content
   PCASM, for instance that the content shares features with other,
   specimen, or known plaintext content.

8.4.  Why: Conversation Metadata as OPTIONAL PCASM

   Conversational Metadata MAY offer insight into Content PCASM, however
   the abstractions of transport mechanism, group management, or
   platform choice, MAY render this moot.

   For example an PGP-Encrypted email distribution list named
   "blockchain-fans@example.com" would leak its implicit topic and
   participant identities to capable observers.

8.5.  Why: Entity and Participant

   The term "participant" in this document exists to supersede the more
   vague notion of "end" in the phrase "end-to-end".

   Entities, and thus participants, are defined in terms of their
   [TrustedComputingBase] to acknowledge that an entity MAY legitimately
   store, forward, or access messages by means that are outside of the
   E2ESM software.

   It is important to note that the concept of "entity" as defined by
   their TCB, is the foundation for all other trust in E2ESM.  This
   develops from the basic definitions of a [TrustedComputingBase] and
   from the concepts of "trust-to-trust" discussed in [RoleOfTrust].
   Failure of a participant to maintain integrity or control over their
   TCB should not be considered a failure of an E2ESM that connects it
   to other participants.

   For example: if a participant accesses their E2ESM software via
   remote desktop software, and their RDP session is hijacked by a third
   party; of if they back-up their messages in cleartext to cloud
   storage leading somehow to data exfiltration, neither of these would
   be a failure of E2ESM.  This would instead be a failure of the
   participant's [TrustedComputingBase].



Muffett                   Expires 18 June 2022                  [Page 9]

Internet-Draft                    e2esm                    December 2021


   Further: it would be obviously possible to burden an E2ESM with
   surfacing potential integrity issues of any given participant to
   other participants, e.g. "patch compliance".  But to require such in
   this standard would risk harming the privacy of the participant
   entity.  See also: "Mutual Identity Verification" in "OPTIONAL
   Features of E2ESM"

8.6.  Why: Transparency of Participation

   The "ends" of "end to end" are the participants; for a message to be
   composed to be exclusively accessible to that set of participants,
   all participants must be visible.

   For decentralised "virtual point-to-point" E2ESM solutions such as
   PGP-Encrypted Email or Ricochet, the set of participants is fixed by
   the author at the time of individual message composition, and MUST be
   visible to all participants.

   For "centralised" E2ESM solutions such as Signal or WhatsApp, the set
   of participants is a "group context" shared amongst all participants
   and at the time of individual message composition it MUST be
   inherited into a set of "fixed" per-participant access capabilities
   by the author.

8.7.  Why: Integrity of Participation

   Inherent in the term "end to end secure messenger" is the intention
   that PCASM will only be available to the participants ("ends") at the
   time the message was composed.

   If this was not the intention we would deduce that an E2ESM would
   automatically make past content available to newly-added conversation
   participants, thereby breaking forward secrecy.  This is not a
   characteristic of any E2ESM, but it is characteristic of several non-
   E2ESM.  Therefore the converse is true.

   As a concrete example this means that participants who are newly
   added to a "group" MUST NOT be able to read messages that were sent
   before they joined that group - unless (for instance) one pre-
   existing participant is explicitly intended to provide a "searchable
   archive" or similar function.  The function of such a participant is
   considered to be out of scope for the messenger.









Muffett                   Expires 18 June 2022                 [Page 10]

Internet-Draft                    e2esm                    December 2021


8.8.  Why: Equality of Participation

   Without equality of participation it would be allowed for a person to
   deploy a standalone cleartext chat server, available solely over TLS-
   encrypted links, declare themselves to be "participants" in every
   conversation from its outset, access all message PCASM on that basis,
   and yet call themselves an E2ESM.

   So this is an "anti-cheating" clause: all participant access to PCASM
   MUST be via the same mechanisms for all participants without favour
   or privilege, and in particular PCASM MUST NOT be available via other
   means, e.g. raw block-device access, raw filestore, raw database
   access, or network sniffing.

8.9.  Why: Closure of Conversation

   If a conversation is not "only extensible from within" then it would
   be possible for participants to be injected into the conversation
   thereby defeating the closure of message distribution.

   A subtle centralised vs: decentralised edge-case is as follows:
   consider a PGP-encrypted email distribution list.  Would it break
   "closure of conversation" for a non-participant email administrator
   to simply add new users to the maillist?

   Answer: no, because in this case the maillist is functioning as a
   "platform" for multiple "conversation" threads, and mere addition of
   of a new "transport-level" maillist member would not include them as
   a participant in ongoing E2ESM conversations; such inclusion would be
   a future burden upon existing participants.

   However: similar external injection of a new entity into a
   centralised WhatsApp or Signal "group" would be clearly a breach of
   "closure of conversation".

8.10.  Why: Management of Participant Clients and Devices

   There is little benefit in requiring conversations to be closed
   against "participant injection" if a non-participant may obtain PCASM
   access by forcing a platform to silently add extra means of PCASM
   access to an existing participant on behalf of that non-participant.

   Therefore to be an E2ESM the platform MUST provide the described
   management of participant clients and devices.







Muffett                   Expires 18 June 2022                 [Page 11]

Internet-Draft                    e2esm                    December 2021


9.  OPTIONAL Features of E2ESM

9.1.  Disappearing Messages

   "Disappearing", "expiring", "exploding", "ephemeral" or other forms
   of time-limited access to PCASM are strongly RECOMMENDED but not
   obligatory mechanisms for E2ESM, not least because they are
   impossible to implement in a way that cannot be circumvented by e.g.
   screenshots.

9.2.  Mutual Identity Verification

   Some manner of "shared key" which mutually assures participant
   identity and communications integrity are strongly RECOMMENDED but
   not obligatory mechanisms for E2ESM.

   The benefits of such mechanisms are limited to certain perspectives
   of certain platforms.

   For instance: in Ricochet the identity key of a user is the absolute
   source of truth for their identity, and excusing detection of
   typographic errors there is nothing which can be added to that in
   order to further assure their "identity".

   Similarly WhatsApp provides each participant with a "verifiable
   security QR code" and "security code change notifications", but these
   codes do not "leak" the number of "WhatsApp For Web" connections,
   desktop WhatsApp applications, or other clients which are bound to
   the E2ESM software which executes on that phone.

   Participant-client information of this kind MAY be a highly private
   aspect of that participant's TCB, and SHOULD be treated sensitively
   by platforms.

10.  Examples of PCASM

   For an example message with content ("content") of "Hello, world.",
   for the purposes of this example encoded as an ASCII string of length
   13 bytes without terminator character.

10.1.  Content PCASM

   Examples of Content PCASM would include, non-exclusively:

   1.  The content is "Hello, world."
   2.  The content starts with the word "Hello"
   3.  The top bit of the first byte of the content, is zero
   4.  The MD5 hash of the content is 080aef839b95facf73ec599375e92d47



Muffett                   Expires 18 June 2022                 [Page 12]

Internet-Draft                    e2esm                    December 2021


   5.  The Salted-MD5 Hash of the content is : ...

10.2.  Size PCASM

   Size PCASM is defined in the main text, as it relates to the
   transport and/or content encryption mechanisms.

10.3.  Analytic PCASM

   Examples of Analytic PCASM would include, non-exclusively:

   1.  The content contains the substring "ello"
   2.  The content does not contain the word "Goodbye"
   3.  The content contains a substring from amongst the following set:
       ...
   4.  The content does not contain a substring from amongst the
       following set: ...
   5.  The hash of the content exists amongst the following set of
       hashes: ...
   6.  The hash of the content does not exist amongst the following set
       of hashes: ...
   7.  The content was matched by a machine-learning classifier with the
       following training set: ...

10.4.  Conversation Metadata as OPTIONAL PCASM

   Examples of Conversation Metadata would include, non-exclusively:

   1.  maillist email addresses
   2.  maillist server names
   3.  group titles
   4.  group topics
   5.  group icons
   6.  group participant lists

10.5.  Non-PCASM

   Information which would not be PCASM would include, non-exclusively:

   1.  The content is sent from Alice
   2.  The content is sent to Bob
   3.  The content is between 1 and 16 bytes long
   4.  The content was sent at the following date and time: ...
   5.  The content was sent from the following IP address: ...
   6.  The content was sent from the following geolocation: ...
   7.  The content was composed using the following platform: ...





Muffett                   Expires 18 June 2022                 [Page 13]

Internet-Draft                    e2esm                    December 2021


11.  See Also

   A different approach to defining (specifically) end-to-end encryption
   is discussed in [I-D.knodel-e2ee-definition].

12.  Live Drafts

   Live working drafts of this document are at:
   https://github.com/alecmuffett/draft-muffett-end-to-end-secure-
   messaging (https://github.com/alecmuffett/draft-muffett-end-to-end-
   secure-messaging)

13.  IANA Considerations

   This document has no IANA actions.

14.  Security Considerations

   This document is entirely composed of security considerations.

15.  Informative References

   [CipherInd]
              Wikipedia, "Ciphertext indistinguishability", 2021,
              <https://en.wikipedia.org/wiki/
              Ciphertext_indistinguishability>.

   [I-D.knodel-e2ee-definition]
              Knodel, M., Baker, F., Kolkman, O., Celi, S., and G.
              Grover, "Definition of End-to-end Encryption", Work in
              Progress, Internet-Draft, draft-knodel-e2ee-definition-02,
              12 July 2021, <https://tools.ietf.org/html/draft-knodel-
              e2ee-definition-02>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RoleOfTrust]
              Clark, D. D. and M. S. Blumenthal, "The End-to-End
              Argument and Application Design: The Role of Trust", 2011,
              <https://www.repository.law.indiana.edu/fclj/vol63/
              iss2/3>.



Muffett                   Expires 18 June 2022                 [Page 14]

Internet-Draft                    e2esm                    December 2021


   [TrustedComputingBase]
              Wikipedia, "Trusted Computing Base", 2021,
              <https://en.wikipedia.org/wiki/Trusted_computing_base>.

Author's Address

   Alec Muffett
   Security Researcher

   Email: alec.muffett@gmail.com









































Muffett                   Expires 18 June 2022                 [Page 15]