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

*** text/draft-muffett-end-to-end-secure-messaging-01.txt	2021-06-13 22:26:44.000000000 +0100
--- text/draft-muffett-end-to-end-secure-messaging-02.txt	2021-07-07 14:19:01.000000000 +0100
***************
*** 4,19 ****
  
  individual submission                                         A. Muffett
  Internet-Draft                                       Security Researcher
! Intended status: Informational                               24 May 2021
! Expires: 25 November 2021
  
  
!           Functional Definition of End-to-End Secure Messaging
!               draft-muffett-end-to-end-secure-messaging-01
  
  Abstract
  
!    This document defines End-to-End Secure Messaging in terms of the
     behaviours that MUST be exhibited by software that claims to
     implement it, or which claims to implement that subset which is known
     as End-to-End Encrypted Messaging.
--- 4,19 ----
  
  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
  
!    This document defines End-to-End Secure Messaging in terms of
     behaviours that MUST be exhibited by software that claims to
     implement it, or which claims to implement that subset which is known
     as End-to-End Encrypted Messaging.
***************
*** 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 25 November 2021.
  
  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 8 January 2022.
  
  Copyright Notice
  
***************
*** 53,61 ****
  
  
  
! Muffett                 Expires 25 November 2021                [Page 1]
  
! Internet-Draft                    e2esm                         May 2021
  
  
  Table of Contents
--- 53,61 ----
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 1]
  
! Internet-Draft                    e2esm                        July 2021
  
  
  Table of Contents
***************
*** 74,80 ****
       3.3.  Entity  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.4.  Sender and Recipient  . . . . . . . . . . . . . . . . . .   5
       3.5.  Participants and Non-Participants . . . . . . . . . . . .   6
!      3.6.  Conversation, Group, De-/Centralised  . . . . . . . . . .   6
       3.7.  Backdoor  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Principles  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Transparency of Participation . . . . . . . . . . . . . .   6
--- 74,80 ----
       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
***************
*** 109,117 ****
  
  
  
! Muffett                 Expires 25 November 2021                [Page 2]
  
! Internet-Draft                    e2esm                         May 2021
  
  
     9.  See Also  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
--- 109,117 ----
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 2]
  
! Internet-Draft                    e2esm                        July 2021
  
  
     9.  See Also  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
***************
*** 119,147 ****
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
     13. Informative References  . . . . . . . . . . . . . . . . . . .  15
!    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16
  
  1.  Introduction
  
     End-to-End Secure Messaging (E2ESM) is a mechanism which offers a
     digital analogue of "closed distribution lists" for sharing message
     content amongst a set of participants, where all participants are
!    visible to each other and where non-participants are 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 [RicochetRefresh]
!    which implements closed distribution by using secure point-to-point
     [RFC7686] networking to literally restrict the distribution of
     content to relevant participants.
  
     Therefore we describe E2ESM in terms of functional behaviours of the
!    software rather than in terms of its implementation goals and
!    technologies.
  
  1.1.  Comments
  
--- 119,147 ----
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
     13. Informative References  . . . . . . . . . . . . . . . . . . .  15
!    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17
  
  1.  Introduction
  
     End-to-End Secure Messaging (E2ESM) is a mechanism which offers a
     digital analogue of "closed distribution lists" for sharing message
     content amongst a set of participants, where all participants are
!    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
     [RFC7686] networking to literally restrict the distribution of
     content to relevant participants.
  
     Therefore we describe E2ESM in terms of functional behaviours of the
!    software rather than in terms of its implementation technologies and
!    architecture.
  
  1.1.  Comments
  
***************
*** 165,173 ****
  
  
  
! Muffett                 Expires 25 November 2021                [Page 3]
  
! Internet-Draft                    e2esm                         May 2021
  
  
  2.  Requirements for an End-to-End Secure Messenger
--- 165,173 ----
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 3]
  
! Internet-Draft                    e2esm                        July 2021
  
  
  2.  Requirements for an End-to-End Secure Messenger
***************
*** 175,183 ****
     Software which functions as an End-to-End Secure Messenger MUST
     satisfy the following principles, and MUST satisfy these principles
     in respect of the provided definitions for all forms of communication
!    and data-sharing that the software offers.  The software MAY comprise
!    either a complete application, or a clearly defined subset of
!    functionality within a larger application.
  
     Any software that does not satisfy these requirements is not an End-
     to-End Secure Messenger, and it does not implement End-to-End Secure
--- 175,183 ----
     Software which functions as an End-to-End Secure Messenger MUST
     satisfy the following principles, and MUST satisfy these principles
     in respect of the provided definitions for all forms of communication
!    and data-sharing that the software offers.  The E2ESM software MAY
!    comprise either a complete application, or a clearly defined subset
!    of functionality within a larger application.
  
     Any software that does not satisfy these requirements is not an End-
     to-End Secure Messenger, and it does not implement End-to-End Secure
***************
*** 195,201 ****
  
     3.  Ricochet Messenger
  
!    4.  PGP-Encrypted Email (in limited circumstances)
  
     Further context for several of these definitions can also be found in
     the rationales section, below.
--- 195,202 ----
  
     3.  Ricochet Messenger
  
!    4.  PGP-Encrypted Email sent to an ad-hoc list of addressees, or to a
!        maillist
  
     Further context for several of these definitions can also be found in
     the rationales section, below.
***************
*** 220,229 ****
  
  
  
  
! Muffett                 Expires 25 November 2021                [Page 4]
! 
! Internet-Draft                    e2esm                         May 2021
  
  
  3.2.1.  Content PCASM
--- 221,229 ----
  
  
  
+ Muffett                  Expires 8 January 2022                 [Page 4]
  
! Internet-Draft                    e2esm                        July 2021
  
  
  3.2.1.  Content PCASM
***************
*** 237,243 ****
     the content.
  
     For stream encryption of content, Size PCASM is currently undefined
!    (TBD)
  
     For transport encryption of content, exact Size PCASM SHOULD NOT be
     observable or inferable.
--- 237,243 ----
     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.
***************
*** 277,285 ****
  
  
  
! Muffett                 Expires 25 November 2021                [Page 5]
  
! Internet-Draft                    e2esm                         May 2021
  
  
  3.5.  Participants and Non-Participants
--- 277,285 ----
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 5]
  
! Internet-Draft                    e2esm                        July 2021
  
  
  3.5.  Participants and Non-Participants
***************
*** 291,297 ****
     outside of the participant set will be "non-participants" in respect
     of that message.
  
! 3.6.  Conversation, Group, De-/Centralised
  
     A "conversation" is a sequence of one or more messages, and the
     responses or replies to them, over a period of time, amongst a
--- 291,297 ----
     outside of the participant set will be "non-participants" in respect
     of that message.
  
! 3.6.  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
***************
*** 305,321 ****
     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 (somewhat)
!    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.
  
  3.7.  Backdoor
  
     A "backdoor" is any intentional or unintentional mechanism, in
!    respect of a given message and that message's set of participants,
!    where some PCASM of that message MAY become available to a non-
!    participant without the intentional action of a participant.
  
  4.  Principles
  
--- 305,321 ----
     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.
  
  3.7.  Backdoor
  
     A "backdoor" is any intentional or unintentional mechanism, in
!    respect of a given message and that message's participants, where
!    some PCASM of that message MAY become available to a non-participant
!    without the intentional action of a participant.
  
  4.  Principles
  
***************
*** 333,341 ****
  
  
  
! Muffett                 Expires 25 November 2021                [Page 6]
  
! Internet-Draft                    e2esm                         May 2021
  
  
     The complete set of all recipients MUST be visible to the sender at
--- 333,341 ----
  
  
  
! 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
***************
*** 389,397 ****
  
  
  
! Muffett                 Expires 25 November 2021                [Page 7]
  
! Internet-Draft                    e2esm                         May 2021
  
  
     2.  The E2ESM software MUST provide each participant entity with
--- 389,397 ----
  
  
  
! Muffett                  Expires 8 January 2022                 [Page 7]
  
! Internet-Draft                    e2esm                        July 2021
  
  
     2.  The E2ESM software MUST provide each participant entity with
***************
*** 408,428 ****
     Content PCASM MUST be protected as it comprises that which is
     "closed" from general distribution.
  
  5.2.  Why: Size PCASM
  
     Exact size PCASM MUST be protected as it MAY offer insight into
     Content PCASM.
  
  5.3.  Why: Analytic PCASM
  
     Analytic PCASM MUST be protected as it MAY offer insight into Content
!    PCASM.
  
  5.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 irrelevant.
  
     For example an PGP-Encrypted email distribution list named
     "blockchain-fans@example.com" would leak its implicit topic and
--- 408,435 ----
     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]
+ 
  5.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.
+ 
  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
  
     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
***************
*** 433,438 ****
--- 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
***************
*** 442,455 ****
     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].
- 
- 
- 
- Muffett                 Expires 25 November 2021                [Page 8]
- 
- Internet-Draft                    e2esm                         May 2021
- 
- 
     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.
--- 459,464 ----
***************
*** 479,510 ****
     The information security community has experienced a historical
     spectrum of mechanisms which have assisted non-participant access to
     PCASM.  These have variously been named as "export-grade key
!    restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and
!    Meltdown), "law enforcement access fields" (Clipper), and "key
!    escrow" (Crypto Wars).
  
     All of these terms combine an "access facilitation mechanism" with an
     "intention or opportunity" - and for all of them an access
     facilitation mechanism is first REQUIRED.
  
-    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
-    of access is clearly the "front door"; and any other access mechanism
-    is a "back door".
- 
- 
- 
  
  
  
  
  
  
! Muffett                 Expires 25 November 2021                [Page 9]
  
- Internet-Draft                    e2esm                         May 2021
  
  
     If the term "back door" is considered innately pejorative,
     alternative, uncertain constructions such as "illegitimate access
--- 488,516 ----
     The information security community has experienced a historical
     spectrum of mechanisms which have assisted non-participant access to
     PCASM.  These have variously been named as "export-grade key
!    restrictions" ([ExportControl], then [Logjam]), "side channel
!    attacks" ([Spectre] and [Meltdown]), "law enforcement access fields"
!    [Clipper], and "key escrow" [CryptoWars].
  
     All of these terms combine an "access facilitation mechanism" with an
     "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
+    of access is clearly the "front door"; and any other access mechanism
+    is a "back door".
  
     If the term "back door" is considered innately pejorative,
     alternative, uncertain constructions such as "illegitimate access
***************
*** 528,537 ****
     composed to be exclusively accessible to that set of participants,
     all participants must be visible.
  
!    For "virtual peer-to-peer" E2ESM solutions such as "Email with PGP"
!    or (to a limited extent) "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
--- 534,545 ----
     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
!    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
***************
*** 545,566 ****
     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.
- 
  
  
  
  
  
  
- Muffett                 Expires 25 November 2021               [Page 10]
- 
- Internet-Draft                    e2esm                         May 2021
  
  
  5.9.  Why: Equality of Participation
  
--- 553,572 ----
     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
  
***************
*** 604,622 ****
     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 25 November 2021               [Page 11]
! 
! Internet-Draft                    e2esm                         May 2021
! 
  
  6.  OPTIONAL Features of E2ESM
  
--- 610,625 ----
     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.
  
  6.  OPTIONAL Features of E2ESM
  
***************
*** 644,651 ****
  
     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" clients which
!    are bound to that phone.
  
     Participant-client information of this kind MAY be a highly private
     aspect of that participant's TCB, and SHOULD be treated sensitively
--- 647,655 ----
  
     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
***************
*** 663,678 ****
  
     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
  
  
  
- Muffett                 Expires 25 November 2021               [Page 12]
  
! Internet-Draft                    e2esm                         May 2021
  
  
     4.  The MD5 hash of the content is 080aef839b95facf73ec599375e92d47
  
--- 667,682 ----
  
     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
  
     4.  The MD5 hash of the content is 080aef839b95facf73ec599375e92d47
  
***************
*** 718,734 ****
  
     4.  group topics
  
-    5.  group icons
  
-    6.  group participant lists
  
  
  
  
- Muffett                 Expires 25 November 2021               [Page 13]
  
! Internet-Draft                    e2esm                         May 2021
  
  
  7.5.  Non-PCASM
  
--- 722,738 ----
  
     4.  group topics
  
  
  
  
+ Muffett                  Expires 8 January 2022                [Page 13]
  
+ Internet-Draft                    e2esm                        July 2021
  
  
!    5.  group icons
  
+    6.  group participant lists
  
  7.5.  Non-PCASM
  
***************
*** 762,768 ****
     Non-Participation)
  
     If FooBook decides to represent itself as a participant, then it MUST
!    NOT have exceptional access to PCASM, despite being the provider of
     the service - for instance via raw database access or network
     sniffing.  However it MAY participate in E2ESM conversations in a
     "normal" way, and thereby have "normal" access to intra-conversation
--- 766,772 ----
     Non-Participation)
  
     If FooBook decides to represent itself as a participant, then it MUST
!    NOT have "exceptional" access to PCASM, despite being the provider of
     the service - for instance via raw database access or network
     sniffing.  However it MAY participate in E2ESM conversations in a
     "normal" way, and thereby have "normal" access to intra-conversation
***************
*** 771,791 ****
     FooBook MAY retain means to eject reported abusive participants from
     a conversation.  (Decrease in Closure of Participation)
  
-    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
-    another, treating it as an ejection, followed by an "illegitimate"
-    insertion.  (Increase in Closure of Participation)
  
  
  
  
  
- Muffett                 Expires 25 November 2021               [Page 14]
  
! Internet-Draft                    e2esm                         May 2021
  
  
     FooBook MUST enable the user to observe and manage the complete state
     of their [TrustedComputingBase] with respect to their FooBook
     messaging services.  (Management and Visibility)
--- 775,797 ----
     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
+    another, treating it as an ejection, followed by an "illegitimate"
+    insertion.  (Increase in Closure of Participation)
+ 
     FooBook MUST enable the user to observe and manage the complete state
     of their [TrustedComputingBase] with respect to their FooBook
     messaging services.  (Management and Visibility)
***************
*** 815,823 ****
--- 821,855 ----
  
  13.  Informative References
  
+    [CipherInd]
+               Wikipedia, "Ciphertext indistinguishability", 2021,
+               <https://en.wikipedia.org/wiki/
+               Ciphertext_indistinguishability>.
+ 
+    [Clipper]  Wikipedia, "Clipper chip", 2021,
+               <https://en.wikipedia.org/wiki/Clipper_chip>.
+ 
+    [CryptoWars]
+               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>.
  
+    [ExportControl]
+               Wikipedia, "Export of cryptography from the United
+               States", 2021, <https://en.wikipedia.org/wiki/Export_of_cr
+               yptography_from_the_United_States#Cold_War_era>.
+ 
     [I-D.knodel-e2ee-definition]
                Knodel, M., Baker, F., Kolkman, O., Celi, S., and G.
                Grover, "Definition of End-to-end Encryption", Work in
***************
*** 825,830 ****
--- 857,869 ----
                22 February 2021, <https://tools.ietf.org/html/draft-
                knodel-e2ee-definition-00>.
  
+    [Logjam]   Wikipedia, "Logjam", 2021, <https://en.wikipedia.org/wiki/
+               Logjam_(computer_security)>.
+ 
+    [Meltdown] Wikipedia, "Meltdown", 2021,
+               <https://en.wikipedia.org/wiki/
+               Meltdown_(security_vulnerability)>.
+ 
     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
***************
*** 834,853 ****
                Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
                2015, <https://www.rfc-editor.org/info/rfc7686>.
  
- 
- 
- 
- Muffett                 Expires 25 November 2021               [Page 15]
- 
- Internet-Draft                    e2esm                         May 2021
- 
- 
     [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>.
  
!    [RicochetRefresh]
!               BlueprintForFreeSpeech, "Ricochet Refresh", 2021,
                <https://www.ricochetrefresh.net>.
  
     [RoleOfTrust]
--- 873,883 ----
                Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
                2015, <https://www.rfc-editor.org/info/rfc7686>.
  
     [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>.
  
!    [Ricochet] BlueprintForFreeSpeech, "Ricochet Refresh", 2021,
                <https://www.ricochetrefresh.net>.
  
     [RoleOfTrust]
***************
*** 856,861 ****
--- 886,903 ----
                <https://www.repository.law.indiana.edu/fclj/vol63/
                iss2/3>.
  
+    [Spectre]  Wikipedia, "Spectre", 2021,
+               <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>.
***************
*** 893,896 ****
  
  
  
! Muffett                 Expires 25 November 2021               [Page 16]
--- 935,952 ----
  
  
  
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! Muffett                  Expires 8 January 2022                [Page 17]