draft-muffett-end-to-end-secure-messaging-03-vs-02.diff

*** text/draft-muffett-end-to-end-secure-messaging-02.txt	2021-07-07 14:19:01.000000000 +0100
--- text/draft-muffett-end-to-end-secure-messaging-03.txt	2021-07-12 15:32:34.000000000 +0100
***************
*** 4,15 ****
  
  individual submission                                         A. Muffett
  Internet-Draft                                       Security Researcher
! Intended status: Informational                               7 July 2021
! Expires: 8 January 2022
  
  
                A Duck Test for End-to-End Secure Messaging
!               draft-muffett-end-to-end-secure-messaging-02
  
  Abstract
  
--- 4,15 ----
  
  individual submission                                         A. Muffett
  Internet-Draft                                       Security Researcher
! Intended status: Informational                              12 July 2021
! Expires: 13 January 2022
  
  
                A Duck Test for End-to-End Secure Messaging
!               draft-muffett-end-to-end-secure-messaging-03
  
  Abstract
  
***************
*** 33,39 ****
     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 8 January 2022.
  
  Copyright Notice
  
--- 33,39 ----
     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 13 January 2022.
  
  Copyright Notice
  
***************
*** 53,59 ****
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 1]
  
  Internet-Draft                    e2esm                        July 2021
  
--- 53,59 ----
  
  
  
! Muffett                  Expires 13 January 2022                [Page 1]
  
  Internet-Draft                    e2esm                        July 2021
  
***************
*** 65,124 ****
       1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
     2.  Requirements for an End-to-End Secure Messenger . . . . . . .   4
     3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
!      3.1.  Message and Platform  . . . . . . . . . . . . . . . . . .   4
!      3.2.  Plaintext Content and Sensitive Metadata (PCASM)  . . . .   4
         3.2.1.  Content PCASM . . . . . . . . . . . . . . . . . . . .   5
         3.2.2.  Size PCASM  . . . . . . . . . . . . . . . . . . . . .   5
         3.2.3.  Analytic PCASM  . . . . . . . . . . . . . . . . . . .   5
         3.2.4.  Conversation Metadata (OPTIONAL)  . . . . . . . . . .   5
!      3.3.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . .   5
!      3.4.  Sender and Recipient  . . . . . . . . . . . . . . . . . .   5
       3.5.  Participants and Non-Participants . . . . . . . . . . . .   6
       3.6.  Conversation, Group, Centralised & Decentralised  . . . .   6
!      3.7.  Backdoor  . . . . . . . . . . . . . . . . . . . . . . . .   6
!    4.  Principles  . . . . . . . . . . . . . . . . . . . . . . . . .   6
!      4.1.  Transparency of Participation . . . . . . . . . . . . . .   6
       4.2.  Integrity of Participation  . . . . . . . . . . . . . . .   7
         4.2.1.  Retransmission Exception  . . . . . . . . . . . . . .   7
!      4.3.  Equality of Participation . . . . . . . . . . . . . . . .   7
!      4.4.  Closure of Conversation . . . . . . . . . . . . . . . . .   7
!        4.4.1.  Public Conversations and Self-Subscription  . . . . .   7
!      4.5.  Management of Participant Clients and Devices . . . . . .   7
     5.  Rationales  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.  Why: Content PCASM  . . . . . . . . . . . . . . . . . . .   8
!      5.2.  Why: Size PCASM . . . . . . . . . . . . . . . . . . . . .   8
!      5.3.  Why: Analytic PCASM . . . . . . . . . . . . . . . . . . .   8
!      5.4.  Why: Conversation Metadata as OPTIONAL PCASM  . . . . . .   8
!      5.5.  Why: Entity and Participant . . . . . . . . . . . . . . .   8
!      5.6.  Why: Backdoor . . . . . . . . . . . . . . . . . . . . . .   9
!      5.7.  Why: Transparency of Participation  . . . . . . . . . . .  10
!      5.8.  Why: Integrity of Participation . . . . . . . . . . . . .  10
       5.9.  Why: Equality of Participation  . . . . . . . . . . . . .  11
!      5.10. Why: Closure of Conversation  . . . . . . . . . . . . . .  11
!      5.11. Why: Management of Participant Clients and Devices  . . .  11
     6.  OPTIONAL Features of E2ESM  . . . . . . . . . . . . . . . . .  12
       6.1.  Disappearing Messages . . . . . . . . . . . . . . . . . .  12
!      6.2.  Mutual Identity Verification  . . . . . . . . . . . . . .  12
!    7.  Examples of PCASM . . . . . . . . . . . . . . . . . . . . . .  12
!      7.1.  Content PCASM . . . . . . . . . . . . . . . . . . . . . .  12
       7.2.  Size PCASM  . . . . . . . . . . . . . . . . . . . . . . .  13
!      7.3.  Analytic PCASM  . . . . . . . . . . . . . . . . . . . . .  13
!      7.4.  Conversation Metadata as OPTIONAL PCASM . . . . . . . . .  13
       7.5.  Non-PCASM . . . . . . . . . . . . . . . . . . . . . . . .  14
!    8.  Worked Example  . . . . . . . . . . . . . . . . . . . . . . .  14
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 2]
  
  Internet-Draft                    e2esm                        July 2021
  
  
     9.  See Also  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
!    10. Live Drafts . . . . . . . . . . . . . . . . . . . . . . . . .  15
!    11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
!    12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
!    13. Informative References  . . . . . . . . . . . . . . . . . . .  15
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17
  
  1.  Introduction
--- 65,124 ----
       1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
     2.  Requirements for an End-to-End Secure Messenger . . . . . . .   4
     3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
!      3.1.  Message and Platform  . . . . . . . . . . . . . . . . . .   5
!      3.2.  Plaintext Content and Sensitive Metadata (PCASM)  . . . .   5
         3.2.1.  Content PCASM . . . . . . . . . . . . . . . . . . . .   5
         3.2.2.  Size PCASM  . . . . . . . . . . . . . . . . . . . . .   5
         3.2.3.  Analytic PCASM  . . . . . . . . . . . . . . . . . . .   5
         3.2.4.  Conversation Metadata (OPTIONAL)  . . . . . . . . . .   5
!      3.3.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . .   6
!      3.4.  Sender and Recipient  . . . . . . . . . . . . . . . . . .   6
       3.5.  Participants and Non-Participants . . . . . . . . . . . .   6
       3.6.  Conversation, Group, Centralised & Decentralised  . . . .   6
!      3.7.  Backdoor  . . . . . . . . . . . . . . . . . . . . . . . .   7
!    4.  Principles  . . . . . . . . . . . . . . . . . . . . . . . . .   7
!      4.1.  Transparency of Participation . . . . . . . . . . . . . .   7
       4.2.  Integrity of Participation  . . . . . . . . . . . . . . .   7
         4.2.1.  Retransmission Exception  . . . . . . . . . . . . . .   7
!      4.3.  Equality of Participation . . . . . . . . . . . . . . . .   8
!      4.4.  Closure of Conversation . . . . . . . . . . . . . . . . .   8
!        4.4.1.  Public Conversations and Self-Subscription  . . . . .   8
!      4.5.  Management of Participant Clients and Devices . . . . . .   8
     5.  Rationales  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.  Why: Content PCASM  . . . . . . . . . . . . . . . . . . .   8
!      5.2.  Why: Size PCASM . . . . . . . . . . . . . . . . . . . . .   9
!      5.3.  Why: Analytic PCASM . . . . . . . . . . . . . . . . . . .   9
!      5.4.  Why: Conversation Metadata as OPTIONAL PCASM  . . . . . .   9
!      5.5.  Why: Entity and Participant . . . . . . . . . . . . . . .   9
!      5.6.  Why: Backdoor . . . . . . . . . . . . . . . . . . . . . .  10
!      5.7.  Why: Transparency of Participation  . . . . . . . . . . .  11
!      5.8.  Why: Integrity of Participation . . . . . . . . . . . . .  11
       5.9.  Why: Equality of Participation  . . . . . . . . . . . . .  11
!      5.10. Why: Closure of Conversation  . . . . . . . . . . . . . .  12
!      5.11. Why: Management of Participant Clients and Devices  . . .  12
     6.  OPTIONAL Features of E2ESM  . . . . . . . . . . . . . . . . .  12
       6.1.  Disappearing Messages . . . . . . . . . . . . . . . . . .  12
!      6.2.  Mutual Identity Verification  . . . . . . . . . . . . . .  13
!    7.  Examples of PCASM . . . . . . . . . . . . . . . . . . . . . .  13
!      7.1.  Content PCASM . . . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Size PCASM  . . . . . . . . . . . . . . . . . . . . . . .  13
!      7.3.  Analytic PCASM  . . . . . . . . . . . . . . . . . . . . .  14
!      7.4.  Conversation Metadata as OPTIONAL PCASM . . . . . . . . .  14
       7.5.  Non-PCASM . . . . . . . . . . . . . . . . . . . . . . . .  14
!    8.  Worked Example  . . . . . . . . . . . . . . . . . . . . . . .  15
  
  
  
! Muffett                  Expires 13 January 2022                [Page 2]
  
  Internet-Draft                    e2esm                        July 2021
  
  
     9.  See Also  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
!    10. Live Drafts . . . . . . . . . . . . . . . . . . . . . . . . .  16
!    11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
!    12. Security Considerations . . . . . . . . . . . . . . . . . . .  16
!    13. Informative References  . . . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17
  
  1.  Introduction
***************
*** 129,138 ****
     visible to each other and where non-participants are completely
     excluded from access to message content.
  
!    In client-server network models it is common to implement E2ESM by
!    means of encryption, in order to obscure content at rest upon a
!    central server.  So therefore E2ESM is often narrowly regarded in
!    terms of "end-to-end encryption".
  
     Other architectural approaches exist - for instance [Ricochet] which
     implements closed distribution by using secure point-to-point
--- 129,138 ----
     visible to each other and where non-participants are completely
     excluded from access to message content.
  
!    In client-server-client network models it is common to implement
!    E2ESM by means of encryption, in order to obscure content at rest
!    upon a central server.  So therefore E2ESM is often narrowly regarded
!    in terms of "end-to-end encryption".
  
     Other architectural approaches exist - for instance [Ricochet] which
     implements closed distribution by using secure point-to-point
***************
*** 165,171 ****
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 3]
  
  Internet-Draft                    e2esm                        July 2021
  
--- 165,171 ----
  
  
  
! Muffett                  Expires 13 January 2022                [Page 3]
  
  Internet-Draft                    e2esm                        July 2021
  
***************
*** 201,261 ****
     Further context for several of these definitions can also be found in
     the rationales section, below.
  
! 3.1.  Message and Platform
  
!    A "message" is information of 0 or more bits, to be communicated.
  
!    Messages possess both plaintext "content", and also "metadata" which
!    describes the content.
  
!    A "platform" is a specific instance of software which exists for the
!    purpose of exchanging messages.
  
! 3.2.  Plaintext Content and Sensitive Metadata (PCASM)
  
!    The "PCASM" of a message is defined as the "plaintext content and
!    sensitive metadata" of that message, comprising any or all of:
  
  
  
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 4]
  
! Internet-Draft                    e2esm                        July 2021
  
  
  3.2.1.  Content PCASM
  
     Content PCASM is any data that can offer better than 50-50 certainty
!    regarding the value of any bit of the content.
  
  3.2.2.  Size PCASM
  
     For block encryption of content, Size PCASM is the unpadded size of
     the content.
  
!    For stream encryption of content, Size PCASM is currently undefined
!    (TODO, would benefit from broader input)
  
     For transport encryption of content, exact Size PCASM SHOULD NOT be
     observable or inferable.
  
  3.2.3.  Analytic PCASM
  
     Analytic PCASM is data which analyses, describes, reduces, or
!    summarises the "content".
  
  3.2.4.  Conversation Metadata (OPTIONAL)
  
     Conversation Metadata MAY exist "outside" of messages and describe
     the conversation context.
  
     Whether conversation metadata constitutes PCASM, is an OPTIONAL
     choice for E2ESM software, but that choice MUST be apparent to
     participants.
  
  3.3.  Entity
  
     An "entity" is a human, machine, software bot, conversation archiver,
--- 201,293 ----
     Further context for several of these definitions can also be found in
     the rationales section, below.
  
!    For the avoidance of doubt we define a "messenger" as a software
!    solution which enables communication between two or more entities,
!    without offering newly-added participants retrospective access to
!    content which was previously sent by prior participants.
  
!    This echoes the distinction between a "maillist" versus a "maillist
!    archive" or "web forum"; frequently these solutions are integrated
!    but we only consider the maillist as a "messenger" per se.
  
!    Use cases of a "messenger" may include sending and receiving any or
!    all of:
  
!    1.  UNICODE or ASCII messages
  
!    2.  images, video files or audio files
  
!    3.  one-way streaming video or audio
  
  
  
+ Muffett                  Expires 13 January 2022                [Page 4]
  
+ Internet-Draft                    e2esm                        July 2021
  
  
!    4.  two-way streaming video or audio, as in live calls
  
! 3.1.  Message and Platform
! 
!    A "message" is information of 0 or more bits, to be communicated.
  
+    Messages possess both plaintext "content", and also "metadata" which
+    describes the content.
+ 
+    A "platform" is a specific instance of software which exists for the
+    purpose of routing or exchanging messages.
+ 
+ 3.2.  Plaintext Content and Sensitive Metadata (PCASM)
+ 
+    The "PCASM" of a message is defined as the "plaintext content and
+    sensitive metadata" of that message, comprising any or all of:
  
  3.2.1.  Content PCASM
  
     Content PCASM is any data that can offer better than 50-50 certainty
!    regarding the value of any bit of the content.  See "Rationales" for
!    more.
  
  3.2.2.  Size PCASM
  
     For block encryption of content, Size PCASM is the unpadded size of
     the content.
  
!    For stream encryption of content, Size PCASM is currently undefined.
!    (TODO, would benefit from broader input.)
  
     For transport encryption of content, exact Size PCASM SHOULD NOT be
     observable or inferable.
  
+    See "Rationales" for more.
+ 
  3.2.3.  Analytic PCASM
  
     Analytic PCASM is data which analyses, describes, reduces, or
!    summarises the "content".  See "Rationales" for more.
  
  3.2.4.  Conversation Metadata (OPTIONAL)
  
     Conversation Metadata MAY exist "outside" of messages and describe
     the conversation context.
  
+ 
+ 
+ 
+ 
+ 
+ Muffett                  Expires 13 January 2022                [Page 5]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
     Whether conversation metadata constitutes PCASM, is an OPTIONAL
     choice for E2ESM software, but that choice MUST be apparent to
     participants.
  
+    See "Rationales" for more.
+ 
  3.3.  Entity
  
     An "entity" is a human, machine, software bot, conversation archiver,
***************
*** 273,287 ****
  
     For each message there will be one sender and one or more recipients.
  
- 
- 
- 
- 
- Muffett                  Expires 8 January 2022                 [Page 5]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
  3.5.  Participants and Non-Participants
  
     The union set of sender and recipients for any given message are the
--- 305,310 ----
***************
*** 305,310 ****
--- 328,343 ----
     prefabricated sets of recipients for the client to utilise when a
     message is composed or sent.
  
+ 
+ 
+ 
+ 
+ 
+ Muffett                  Expires 13 January 2022                [Page 6]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
     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,
***************
*** 330,343 ****
     message MUST be frozen into an immutable set at the moment when the
     message is composed or sent.
  
- 
- 
- 
- Muffett                  Expires 8 January 2022                 [Page 6]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     The complete set of all recipients MUST be visible to the sender at
     the moment of message composition or sending.
  
--- 363,368 ----
***************
*** 358,366 ****
     MAY become available to a new, additional, and possibly different set
     of conversation participants, via that new message.
  
  4.3.  Equality of Participation
  
!    All participants MUST be peers who MUST have equal means of access to
     the PCASM of any message; see also "Integrity of Participation".
  
  4.4.  Closure of Conversation
--- 383,402 ----
     MAY become available to a new, additional, and possibly different set
     of conversation participants, via that new message.
  
+ 
+ 
+ 
+ 
+ 
+ 
+ Muffett                  Expires 13 January 2022                [Page 7]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
  4.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".
  
  4.4.  Closure of Conversation
***************
*** 369,377 ****
     except by the intentional action of one or more existing
     participants.
  
  4.4.1.  Public Conversations and Self-Subscription
  
!    Existing participants MAY publicly share links, data, 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
--- 405,417 ----
     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
+ 
  4.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
***************
*** 383,398 ****
     participants:
  
     1.  The E2ESM software MUST provide each participant entity with
!        means to review or revoke access for clients or devices that can
!        access future PCASM.
! 
! 
! 
! 
! Muffett                  Expires 8 January 2022                 [Page 7]
! 
! Internet-Draft                    e2esm                        July 2021
! 
  
     2.  The E2ESM software MUST provide each participant entity with
         notifications and/or complete logs of changes to the set of
--- 423,430 ----
     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
***************
*** 411,416 ****
--- 443,455 ----
     The test for measuring this is (intended to be) modeled upon
     ciphertext indistinguishability [CipherInd]
  
+ 
+ 
+ Muffett                  Expires 13 January 2022                [Page 8]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
  5.2.  Why: Size PCASM
  
     Exact size PCASM MUST be protected as it MAY offer insight into
***************
*** 422,429 ****
  5.3.  Why: Analytic PCASM
  
     Analytic PCASM MUST be protected as it MAY offer insight into Content
!    PCASM, for instance the content sharing features with other,
!    specimen, known plaintext content.
  
  5.4.  Why: Conversation Metadata as OPTIONAL PCASM
  
--- 461,468 ----
  5.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.
  
  5.4.  Why: Conversation Metadata as OPTIONAL PCASM
  
***************
*** 440,455 ****
     The term "participant" in this document exists to supersede the more
     vague notion of "end" in the phrase "end-to-end".
  
- 
- 
- 
- 
- 
- Muffett                  Expires 8 January 2022                 [Page 8]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     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
--- 479,484 ----
***************
*** 470,475 ****
--- 499,511 ----
     be a failure of E2ESM.  This would instead be a failure of the
     participant's [TrustedComputingBase].
  
+ 
+ 
+ Muffett                  Expires 13 January 2022                [Page 9]
+ 
+ Internet-Draft                    e2esm                        July 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
***************
*** 496,511 ****
     "intention or opportunity" - and for all of them an access
     facilitation mechanism is first REQUIRED.
  
- 
- 
- 
- 
- 
- Muffett                  Expires 8 January 2022                 [Page 9]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     An access facilitation mechanism is a "door", and is inherently
     [DualUse].  Because the goal of E2ESM is to limit access to PCASM
     exclusively to a defined set of participants, then the intended means
--- 532,537 ----
***************
*** 528,541 ****
     because it is also not far removed from the similar and established
     term "side channel".
  
  5.7.  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.
  
-    TODO: EXCISE DUPLICATION IN NEXT PARA
- 
     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
--- 554,573 ----
     because it is also not far removed from the similar and established
     term "side channel".
  
+ 
+ 
+ 
+ Muffett                  Expires 13 January 2022               [Page 10]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
  5.7.  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
***************
*** 553,573 ****
     that PCASM will only be available to the participants ("ends") at the
     time the message was composed.
  
- 
- 
- 
- 
- Muffett                  Expires 8 January 2022                [Page 10]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     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.
  
  5.9.  Why: Equality of Participation
  
     Without equality of participation it would be allowed for a person to
--- 585,603 ----
     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.
+ 
  5.9.  Why: Equality of Participation
  
     Without equality of participation it would be allowed for a person to
***************
*** 576,581 ****
--- 606,623 ----
     conversation from its outset, access all message PCASM on that basis,
     and yet call themselves an E2ESM.
  
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ Muffett                  Expires 13 January 2022               [Page 11]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
     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
***************
*** 610,623 ****
     access by forcing a platform to silently add extra means of PCASM
     access to an existing participant on behalf of that non-participant.
  
- 
- 
- 
- Muffett                  Expires 8 January 2022                [Page 11]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     Therefore to be an E2ESM the platform MUST provide the described
     management of participant clients and devices.
  
--- 652,657 ----
***************
*** 631,636 ****
--- 665,679 ----
     impossible to implement in a way that cannot be circumvented by e.g.
     screenshots.
  
+ 
+ 
+ 
+ 
+ Muffett                  Expires 13 January 2022               [Page 12]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
  6.2.  Mutual Identity Verification
  
     Some manner of "shared key" which mutually assures participant
***************
*** 667,679 ****
  
     1.  The content is "Hello, world."
  
- 
- 
- Muffett                  Expires 8 January 2022                [Page 12]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     2.  The content starts with the word "Hello"
  
     3.  The top bit of the first byte of the content, is zero
--- 710,715 ----
***************
*** 687,692 ****
--- 723,735 ----
     Size PCASM is defined in the main text, as it relates to the
     transport and/or content encryption mechanisms.
  
+ 
+ 
+ Muffett                  Expires 13 January 2022               [Page 13]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
  7.3.  Analytic PCASM
  
     Examples of Analytic PCASM would include, non-exclusively:
***************
*** 722,735 ****
  
     4.  group topics
  
- 
- 
- 
- Muffett                  Expires 8 January 2022                [Page 13]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     5.  group icons
  
     6.  group participant lists
--- 765,770 ----
***************
*** 744,749 ****
--- 779,791 ----
  
     3.  The content is between 1 and 16 bytes long
  
+ 
+ 
+ Muffett                  Expires 13 January 2022               [Page 14]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
     4.  The content was sent at the following date and time: ...
  
     5.  The content was sent from the following IP address: ...
***************
*** 775,791 ****
     FooBook MAY retain means to eject reported abusive participants from
     a conversation.  (Decrease in Closure of Participation)
  
- 
- 
- 
- 
- 
- 
- Muffett                  Expires 8 January 2022                [Page 14]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     FooBook MUST NOT retain means to forcibly insert new participants
     into a conversation.  For clarity: this specification does not
     recognise any notion of "atomic" exchange of one participant with
--- 817,822 ----
***************
*** 804,809 ****
--- 835,847 ----
     A different approach to defining (specifically) end-to-end encryption
     is discussed in [I-D.knodel-e2ee-definition].
  
+ 
+ 
+ Muffett                  Expires 13 January 2022               [Page 15]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
  10.  Live Drafts
  
     Live working drafts of this document are at:
***************
*** 833,847 ****
                Wikipedia, "Crypto Wars", 2021,
                <https://en.wikipedia.org/wiki/Crypto_Wars>.
  
- 
- 
- 
- 
- Muffett                  Expires 8 January 2022                [Page 15]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     [DualUse]  Wikipedia, "Dual-use technology", 2021,
                <https://en.wikipedia.org/wiki/Dual-use_technology>.
  
--- 871,876 ----
***************
*** 860,865 ****
--- 889,903 ----
     [Logjam]   Wikipedia, "Logjam", 2021, <https://en.wikipedia.org/wiki/
                Logjam_(computer_security)>.
  
+ 
+ 
+ 
+ 
+ Muffett                  Expires 13 January 2022               [Page 16]
+ 
+ Internet-Draft                    e2esm                        July 2021
+ 
+ 
     [Meltdown] Wikipedia, "Meltdown", 2021,
                <https://en.wikipedia.org/wiki/
                Meltdown_(security_vulnerability)>.
***************
*** 890,903 ****
                <https://en.wikipedia.org/wiki/
                Spectre_(security_vulnerability)>.
  
- 
- 
- 
- Muffett                  Expires 8 January 2022                [Page 16]
- 
- Internet-Draft                    e2esm                        July 2021
- 
- 
     [TrustedComputingBase]
                Wikipedia, "Trusted Computing Base", 2021,
                <https://en.wikipedia.org/wiki/Trusted_computing_base>.
--- 928,933 ----
***************
*** 919,952 ****
  
  
  
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! Muffett                  Expires 8 January 2022                [Page 17]
--- 949,952 ----
  
  
  
! Muffett                  Expires 13 January 2022               [Page 17]