< draft-knodel-e2ee-definition-01.txt   draft-knodel-e2ee-definition-02.txt >
mls M. Knodel mls M. Knodel
Internet-Draft CDT Internet-Draft CDT
Intended status: Informational F. Baker Intended status: Informational F. Baker
Expires: November 8, 2021 Expires: January 13, 2022
O. Kolkman O. Kolkman
ISOC ISOC
S. Celi S. Celi
Cloudflare Cloudflare
G. Grover G. Grover
Centre for Internet and Society Centre for Internet and Society
May 07, 2021 July 12, 2021
Definition of End-to-end Encryption Definition of End-to-end Encryption
draft-knodel-e2ee-definition-01 draft-knodel-e2ee-definition-02
Abstract Abstract
End-to-end encryption (E2EE) is an application of cryptography in End-to-end encryption (E2EE) is an application of cryptography in
communications systems between endpoints. E2EE systems are unique in communications systems between endpoints. E2EE systems are unique in
providing features of confidentiality, integrity and authenticity for providing features of confidentiality, integrity and authenticity for
users. Improvements to E2EE strive to maximise the system's security users. Improvements to E2EE strive to maximise the system's security
while balancing usability and availability. Users of E2EE while balancing usability and availability. Users of E2EE
communications expect trustworthy providers of secure implementations communications expect trustworthy providers of secure implementations
to respect and protect their right to whisper. to respect and protect their right to whisper.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2021. This Internet-Draft will expire on January 13, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Formal definition of end-to-end encryption . . . . . . . . . 3 2. Formal definition of end-to-end encryption . . . . . . . . . 3
2.1. End point . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. End point . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. End-to-end principle . . . . . . . . . . . . . . . . . . 3 2.2. End-to-end principle . . . . . . . . . . . . . . . . . . 4
2.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . 5
3. End-to-end encrypted systems design . . . . . . . . . . . . . 5 2.4. Succinct definition of end-to-end security . . . . . . . 6
3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5 3. End-to-end encrypted systems design . . . . . . . . . . . . . 7
3.1.1. Necessary features . . . . . . . . . . . . . . . . . 6 3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Optional/desirable features . . . . . . . . . . . . . 6 3.1.1. Necessary features . . . . . . . . . . . . . . . . . 7
3.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Optional/desirable features . . . . . . . . . . . . . 7
4. End-user expectations . . . . . . . . . . . . . . . . . . . . 8 3.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. A conversation is confidential . . . . . . . . . . . . . 8 4. End-user expectations . . . . . . . . . . . . . . . . . . . . 10
4.2. Providers are trustworthy . . . . . . . . . . . . . . . . 9 4.1. A conversation is confidential . . . . . . . . . . . . . 10
4.3. Access by a third-party is impossible . . . . . . . . . . 9 4.2. Providers are trustworthy . . . . . . . . . . . . . . . . 10
4.4. Pattern inference is minimised . . . . . . . . . . . . . 9 4.3. Access by a third-party is impossible . . . . . . . . . . 11
4.5. The e2ee system is not compromised . . . . . . . . . . . 10 4.4. Pattern inference is minimised . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. The E2EE system is not compromised . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 9. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document defines end-to-end encryption (E2EE) using three This document defines end-to-end encryption (E2EE) using three
different dimensions that together comprise a full definition of different dimensions that together comprise a full definition of
E2EE, which can be applied in a variety of contexts. E2EE, which can be applied in a variety of contexts.
The first is a formal definition that draws on the basic The first is a formal definition that draws on the basic
understanding of end points and cryptography. The second looks at understanding of end points and cryptography. The second looks at
E2EE systems from a design perspective, both its fundamental features E2EE systems from a design perspective, both its fundamental features
skipping to change at page 3, line 14 skipping to change at page 3, line 14
These dimensions taken as a whole comprise a generally comprehensible These dimensions taken as a whole comprise a generally comprehensible
picture of consensus at the IETF as to what is end-to-end encryption, picture of consensus at the IETF as to what is end-to-end encryption,
irrespective of application, from messaging to video conferencing, irrespective of application, from messaging to video conferencing,
and between any number of end points. and between any number of end points.
2. Formal definition of end-to-end encryption 2. Formal definition of end-to-end encryption
An end-to-end encrypted communications system, irrespective of the An end-to-end encrypted communications system, irrespective of the
content or the specific methods employed, relies on two important and content or the specific methods employed, relies on two important and
rigorous technical concepts: The end-to-end principle, defined in the rigorous technical concepts: The end-to-end principle and what
IETF because of its importance to internet protocols; and encryption, defines an end, according to the IETF because of its importance to
an application of cryptography and the primary means employed by the internet protocols; and encryption, an application of cryptography
IETF to secure internet protocols. and the primary means employed by the IETF to secure internet
protocols. In the tradition of cryptography it's also possible to
achieve a succinct definition of end-to-end encrypted security.
2.1. End point 2.1. End point
Intuitively, an "end" either sends messages or receives them, usually Intuitively, an "end" either sends messages or receives them, usually
both; other systems on the path are just that - other systems. both; other systems on the path are just that - other systems.
It is, however, not trivial to establish the definition of an end It is, however, not trivial to establish the definition of an end
point in isolation, because its existence inherentely depends on at point in isolation, because its existence inherently depends on at
least one other entity in a communications system. That is why we least one other entity in a communications system. That is why we
will now move directly into an anlaysis of the end-to-end principle, will now move directly into an analysis of the end-to-end principle,
which introduces nuance, described in the following sub-section. which introduces nuance, described in the following sub-section.
However despite the nuance for engineers, it is now widely accepted However despite the nuance for engineers, it is now widely accepted
that the communication system itself begins and ends with the user that the communication system itself begins and ends with the user
[RFC8890]. We imagine people (through an application's user [RFC8890]. We imagine people (through an application's user
interface, or user agent) as components in a subsystem's design. An interface, or user agent) as components in a subsystem's design. An
important exception to this in E2EE systems might be the use of important exception to this in E2EE systems might be the use of
public key infrastructure where a third party is often used in the public key infrastructure where a third party is often used in the
authentication phase to enhance the larger system's trust model. authentication phase to enhance the larger system's trust model.
Responsible use of of public key infrastructure is required in such
cases, such that the E2EE system does not admit third parties under
the user's identity.
We cannot equate user agent and user, yet we also cannot fully We cannot equate user agent and user, yet we also cannot fully
separate them. As user-agent computing becomes more complex and separate them. As user-agent computing becomes more complex and
often more proprietary, the user agent less of an "advocate" for the often more proprietary, the user agent becomes less of an "advocate"
best interests of the user. This is why we focus in a later section for the best interests of the user. This is why we focus in a later
on the e2ee system being able to fulfil user expectations. section on the E2EE system being able to fulfill user expectations.
2.2. End-to-end principle 2.2. End-to-end principle
We needed first to answer "what constitutes an end?", which is an We need first to answer "What constitutes an end?", which is an
important question in any review of the End-to-End Principle important question in any review of the End-to-End Principle
[RFC3724]. However the notion of an end point is more fully defined [RFC3724]. However the notion of an end point is more fully defined
within the principle of end-to-end communications. within the principle of end-to-end communications.
In 1984 the "end-to-end argument" was introduced [saltzer] as a In 1984 the "end-to-end argument" was introduced [saltzer] as a
design principle that helps guide placement of functions among the design principle that helps guide placement of functions among the
modules of a distributed computer system. It suggests that functions modules of a distributed computer system. It suggests that functions
placed at low levels of a system may be redundant or of little value placed at low levels of a system may be redundant or of little value
when compared with the cost of providing them at that low level. when compared with the cost of providing them at that low level. It
It's used to design around questions about which parts of the system is used to design around questions about which parts of the system
should make which decisions, and as such the identity of the actual should make which decisions, and as such the identity of the actual
"speaker" or "end" may be less obvious than it appears. The "speaker" or "end" may be less obvious than it appears. The
communication described by Saltzer is between communicating communication described by Saltzer is between communicating
processes, which may or may not be on the same physical machine, and processes, which may or may not be on the same physical machine, and
may be implemented in various ways. For example, a BGP speaker is may be implemented in various ways. For example, a BGP speaker is
often implemented as a process that manages the Routing Information often implemented as a process that manages the Routing Information
Base (RIB) and communicates with other BGP speakers using an Base (RIB) and communicates with other BGP speakers using an
operating system service that implements TCP. The RIB manager might operating system service that implements TCP. The RIB manager might
find itself searching the RIB for prefixes that should be advertised find itself searching the RIB for prefixes that should be advertised
to a peer, and performing "writes" to TCP for each one. TCP in this to a peer, and performing "writes" to TCP for each one. TCP in this
skipping to change at page 4, line 45 skipping to change at page 5, line 7
deals with end cases that come up in implementation: "Examples deals with end cases that come up in implementation: "Examples
discussed in the paper", according to the abstract, "include bit discussed in the paper", according to the abstract, "include bit
error recovery, security using encryption, duplicate message error recovery, security using encryption, duplicate message
suppression, recovery from system crashes, and delivery suppression, recovery from system crashes, and delivery
acknowledgement." It also notes that there is occasionally a acknowledgement." It also notes that there is occasionally a
rationale for ignoring the end-to-end arguments for the purposes of rationale for ignoring the end-to-end arguments for the purposes of
optimization. There may be other user expectations or design optimization. There may be other user expectations or design
features, some explained below, which need to be balanced with the features, some explained below, which need to be balanced with the
end-to-end argument. end-to-end argument.
More concisely, suppose that an end user is the end identity. An
E2EE system may run between potential end points at different network
layers within the end identity's possession. These end points may
then be considered acceptable sub-identities provided that no path
between the end identity and sub-identity is accessible by any third
party. This definition of end points accounts for potentially
several devices owned by a user, and various application-specific
forwarding or delivery options among them. It also accounts for E2EE
systems running at different network layers. Regardless of the sub-
identities allowed, the definition is contingent on that all end sub-
identities are under the end identity's control and no third party
(or their sub-identities, e.g. system components under third-party
control) can access the end sub-identities nor links between the sub-
identity and end identity. This creates a tree hierarchy with the
end user as the root at the top, and all potential end points being
under their direct control, without third party access. As an
example, decryption at organizational network router before message
forwarding (encrypted or unencrypted) to the end identity does not
constitute E2EE. However, E2EE to a user's personal device and
subsequent E2EE message forwarding to another one of the user's
personal devices (without access available to any third party at any
link or on device) maintains E2EE data possession for the user.
2.3. Encryption 2.3. Encryption
From draft-dkg-hrpc-glossary-00, encryption is fundamental to the From draft-dkg-hrpc-glossary-00, encryption is fundamental to the
end-to-end principle. "End-to-End : The principal of extending end-to-end principle. "End-to-End : The principal of extending
characteristics of a protocol or system as far as possible within the characteristics of a protocol or system as far as possible within the
system. For example, end-to-end instant message encryption would system. For example, end-to-end instant message encryption would
conceal communication content from one user's instant messaging conceal communication content from one user's instant messaging
application through any intermediate devices and servers all the way application through any intermediate devices and servers all the way
to the recipient's instant messaging application. If the message was to the recipient's instant messaging application. If the message was
decrypted at any intermediate point-for example at a service decrypted at any intermediate point-for example at a service
provider-then the property of end-to-end encryption would not be provider-then the property of end-to-end encryption would not be
present."[dkg] Note that this only talks about the contents of the present."[dkg] Note that this only talks about the contents of the
communication and not the metadata generated from it. communication and not the metadata generated from it.
The way to achieve a truly end-to-end communications system is indeed The way to achieve a truly end-to-end communications system is indeed
to encrypt the content of the data exchanged between the endpoints, to encrypt the content of the data exchanged between the endpoints,
eg sender(s) and receiver(s). The more common end-to-end technique e.g. sender(s) and receiver(s). The more common end-to-end technique
for encrypting uses a double-ratchet algorithm with an authenticated for encrypting uses a double-ratchet algorithm with an authenticated
encryption scheme, present in many modern messenger applications such encryption scheme, present in many modern messenger applications such
as those considered in the IETF Messaging Layer Security working as those considered in the IETF Messaging Layer Security working
group, whose charter is to create a document that satisfies the need group, whose charter is to create a document that satisfies the need
for several Internet applications for group key establishment and for several Internet applications for group key establishment and
message protection protocols.[mls] OpenPGP, mostly used for email, message protection protocols [mls]. OpenPGP, mostly used for email,
uses a different technique to achieve encryption. It is also uses a different technique to achieve encryption. It is also
chartered in the IETF to create an specification that covers object chartered in the IETF to create a specification that covers object
encryption, object signing, and identity certification.[openpgp] Both encryption, object signing, and identity certification [openpgp].
protocols rely on the use of asymmetric and symmetric encryption, and Both protocols rely on the use of asymmetric and symmetric
have to exchange public keys with amongst end points. encryption, and exchange public keys with amongst end points.
There are dozens of documents in the RFC Series that fundamentally There are dozens of documents in the RFC Series that fundamentally
and technically define encryption schemes. Perhaps interesting work and technically define encryption schemes. Perhaps interesting work
to be done would be to survey all existing documents of this kind to to be done would be to survey all existing documents of this kind to
define, in aggregate, their common features. The point is, the IETF define, in aggregate, their common features. The point is, the IETF
has clear mandate and demonstrated expertise in defining the has clear mandate and demonstrated expertise in defining the
specifics of encrypted communications of the internet. specifics of encrypted communications of the internet.
While encryption is fundamental to the end-to-end principle, it does
not stand alone. As in the history of all security, authentication
and data integrity properties are also linked, and contributed to the
end-to-end nature of E2EE. Permission of data manipulation or
pseudo-identities for third parties to allow access under the user's
identity are against the intention of E2EE. Thus, end point
authenticity must be established as (sub-)identities of the end user,
and end-to-end integrity must also be maintained by the system.
There is considerable system design flexibility available in entity
authentication mechanisms and data authentication that still meet
this requirement.
2.4. Succinct definition of end-to-end security
A succinct definition for end-to-end security can describe the
security of the system by the probability of an adversary's success
in breaking the system. Example snippet:
The adversary successfully subverts an end-to-end encrypted system if
it can succeed in either of the following: 1) the adversary can
produce the participant's local state (meaning the adversary has
learned the contents of participant's messages), or 2) the states of
conversation participants do not match (meaning that the adversary
has influenced their communication in some way). To prevent the
adversary from trivially winning, we do not allow the adversary to
compromise the participants' local state.
We can say that a system is end-to-end secure if the adversary has
negligible probability of success in either of these two scenarios
[komlo].
3. End-to-end encrypted systems design 3. End-to-end encrypted systems design
When looking at E2EE systems from a design perspective, the first When looking at E2EE systems from a design perspective, the first
consideration is the list of fundamental features that distinguish an consideration is the list of fundamental features that distinguish an
E2EE system from one that does not employ E2EE. Secondly one must E2EE system from one that does not employ E2EE. Secondly one must
consider the direction of travel for improving the features of E2EE consider the direction of travel for improving the features of E2EE
systems. In other words, what challenges are the designers, systems. In other words, what challenges are the designers,
developers and implementers of E2EE systems facing? developers and implementers of E2EE systems facing?
The features and challenges listed below are framed holistically The features and challenges listed below are framed holistically
rather than from the perspective of their design, development, rather than from the perspective of their design, development,
implementation or use. implementation or use.
3.1. Features 3.1. Features
Defining a technology can also be done by inspecting what it does, or Defining a technology can also be done by inspecting what it does, or
is meant to do, in the form of features. The features of end-to-end is meant to do, in the form of features. The features of end-to-end
encryption from an implementation perspective can be inspected across encryption from an implementation perspective can be inspected across
several important categories: 1) the necessary features of E2EE of several important categories: 1) the necessary features of E2EE of
authenticity, confidentiality and integrity, whereas features of 2) authenticity, confidentiality, and integrity, whereas features of 2)
availability, deniability, forward secrecy and post-compromise availability, deniability, forward secrecy, and post-compromise
security are enhancements to E2EE systems. security are enhancements to E2EE systems.
3.1.1. Necessary features 3.1.1. Necessary features
Authenticity A system provides message authenticity if the recipient Authenticity A system provides message authenticity if the recipient
is certain who sent the message and the sender is certain who is certain who sent the message and the sender is certain who
received it. received it.
Confidentiality A system provides message confidentiality if only Confidentiality A system provides message confidentiality if only
the sender and intended recipient(s) can read the message the sender and intended recipient(s) can read the message
plaintext, i.e. messages are encrypted by the sender such that plaintext, i.e. messages are encrypted by the sender such that
only the intended recipient(s) can decrypt them. only the intended recipient(s) can decrypt them.
Integrity A system provides message integrity when it guarantees Integrity A system provides message integrity when it guarantees
that messages has not been modified in transit, i.e. a recipient that messages has not been modified in transit, i.e. a recipient
is assured that the message they have received is exactly what the is assured that the message they have received is exactly what the
sender intented to sent. sender intended to send.
3.1.2. Optional/desirable features 3.1.2. Optional/desirable features
Availability A system provides high availability if the user is able Availability A system provides high availability if the user is able
to get to the message when they so desire and potentially from to get to the message when they so desire and potentially from
more than one device, i.e. a message arrives to a recipient even more than one device, i.e. a message arrives to a recipient even
if they have been offline for a long time. if they have been offline for a long time.
Deniability Deniability ensures that anyone with a record of the Deniability Deniability ensures that anyone with a record of the
transcript, including message recipients, cannot cryptographically transcript, including message recipients, cannot cryptographically
prove to others that a particular participant of a communication prove to others that a particular participant of a communication
authored the message. As demonstrated by the Signal and OTR authored the message. As demonstrated by the Signal and OTR
protocols, this property has to exist in conjunction with message protocols, this optional property must exist in conjunction with
authenticity, i.e. participants in a communication have to be the necessary property of message authenticity, i.e. participants
assured that they are communicating with the intended parties but in a communication must be assured that they are communicating
this assurance cannot be proof to any other parties. with the intended parties but this assurance cannot be proof to
any other parties.
Forward secrecy Forward secrecy is a security property that prevents Forward secrecy Forward secrecy is a security property that prevents
attackers from decrypting all encrypted data they have previously attackers from decrypting encrypted data they have previously
captured over a communication channel, even if they have captured over a communication channel before the time of
compromised one of the endpoints. Forward secrecy is usually compromise, even if they have compromised one of the endpoints.
achieved by updating the encryption/decryption keys, and older Forward secrecy is usually achieved by updating the encryption/
ones are deleted periodically. decryption keys, and older ones are deleted periodically.
Post-compromise security Post-compromise security is a security Post-compromise security Post-compromise security is a security
property that seeks to guarantee a way to recover from an end- property that seeks to guarantee a way to recover from an end-
point compromise (and consequently that communication sent post- point compromise (and consequently that communication sent post-
compromise is protected with the same security properties that compromise is protected with the same security properties that
existed before the compromise). It is usually achieved by adding existed before the compromise). It is usually achieved by adding
ephemeral key exchanges to the derivation of encryption/decryption ephemeral key exchanges to the derivation of encryption/decryption
keys. keys.
3.2. Challenges 3.2. Challenges
Earlier we defined end-to-end encryption using formal definitions Earlier we defined end-to-end encryption using formal definitions
assumed by internet protocol implementations. And because "the IETF assumed by internet protocol implementations. Also because "the IETF
is a place for state-of-the-art producing high quality, relevant is a place for state-of-the-art producing high quality, relevant
technical documents that influence the way people design, use, and technical documents that influence the way people design, use, and
manage the Internet" we can be confident that current deployments of manage the Internet" we can be confident that current deployments of
end-to-end encrypted technologies in the IETF indicate the cutting end-to-end encrypted technologies in the IETF indicate the cutting
edge of their developments, yet another way to define what is, or edge of their developments, yet another way to define what is, or
ideally should be, how a technology is defined. ideally should be, how a technology is defined.
Below is an exhaustive, yet vaguely summarised, list of the Below is an exhaustive, yet vaguely summarised, list of the
challenges currently faced by protocol designers of end-to-end challenges currently faced by protocol designers of end-to-end
encrypted systems. In other words, in order to realise the goals of encrypted systems. In other words, in order to realise the goals of
end-to-end encrypted systems, both for users and implementers (see end-to-end encrypted systems, both for users and implementers (see
previous section), these problems must be tackled. Problems that previous section), these problems must be tackled. Problems that
fall outside of this list are likely 1) unnecessary feature requests fall outside of this list are likely 1) unnecessary feature requests
that negligibly, or do nothing to, achieve the aims of end-to-end that negligibly, or do nothing to, achieve the aims of end-to-end
encrypted systems or 2) in some way antithetical to the goals of end- encrypted systems or are 2) in some way antithetical to the goals of
to-end encrypted systems. end-to-end encrypted systems.
Public key verification is very difficult for users to manage. Public key verification is very difficult for users to manage.
Authentication of the two ends is required for confidential Authentication of the two ends is required for confidential
conversations. Therefore solving the problem of verification of conversations. Therefore solving the problem of verification of
public keys is a major concern for any end-to-end encrypted system public keys is a major concern for any end-to-end encrypted system
design. Some applications bind together the account identity and the design. Some applications bind together the account identity and the
key, and leaves users to establish a trust relationship between them, key, and leave users to establish a trust relationship between them,
assisted by public key fingerprint information. assisted by public key fingerprint information.
Users want to smoothly switch application use between devices, but Users want to smoothly switch application use between devices, but
this comes at a cost to the security of user data. Thus there is a this comes at a cost to the security of user data. Thus, there is a
problem of availability in end-to-end encrypted systems because the problem of availability in end-to-end encrypted systems because the
account identity's private key is generated by and stored on the end- account identity's private key is generated by and stored on the end-
user's original device and to move the private key to another device user's original device and to move the private key to another device
compromises the security of one of the end-points of the system. compromises the security of one of the end-points of the system.
Existing protocols are vulnerable to meta-data analysis, even though Existing protocols are vulnerable to meta-data analysis, even though
meta-data is often much more sensitive than content. Meta-data is meta-data is often much more sensitive than content. Meta-data is
plaintext information that travels across the wire and includes plaintext information that travels across the wire and includes
delivery-relevant details that central servers need such as the delivery-relevant details that central servers need such as the
account identity of end-points, timestamps, message size. Meta-data account identity of end-points, timestamps, message size. Meta-data
skipping to change at page 8, line 17 skipping to change at page 9, line 34
cryptography. cryptography.
The whole of a user's data should remain secure if only one message The whole of a user's data should remain secure if only one message
is compromised. However, for encrypted communication, you must is compromised. However, for encrypted communication, you must
currently choose between forward secrecy or the ability to currently choose between forward secrecy or the ability to
communicate asynchronously. This presents a problem for application communicate asynchronously. This presents a problem for application
design that uses end-to-end encryption for asynchronous messaging design that uses end-to-end encryption for asynchronous messaging
over email, RCS, etc. over email, RCS, etc.
Users of E2EE systems should be able to communicate with any medium Users of E2EE systems should be able to communicate with any medium
of their choice, from plain text to large files, however there is of their choice, from text to large files, however there is often a
often a resource problem because there are no open protocols to allow resource problem because there are no open protocols to allow users
users to securely share the same resource in an end-to-end encrypted to securely share the same resource in an end-to-end encrypted
system. Client-side, eg end-point, activities like URL unfurling system. Client-side, e.g. end-point, activities like URL unfurling
scanning. scanning.
Usability considerations are sometimes in conflict with security Usability considerations are sometimes in conflict with security
considerations, such as message read status, typing indicators, URL/ considerations, such as message read status, typing indicators, URL/
link previews. link previews.
Deployment is notoriously challenging for any software application Deployment is notoriously challenging for any software application
where maintenance and updates can be particularly disastrous for where maintenance and updates can be particularly disastrous for
obsolete cryptographic libraries. obsolete cryptographic libraries.
4. End-user expectations 4. End-user expectations
While the formal definition and properties of an E2EE system relate While the formal definition and properties of an E2EE system relate
to communication security, they do not draw from a comprehensive to communication security, they do not draw from a comprehensive
threat model or speak to what users expect from E2EE communication. threat model or speak to what users expect from E2EE communication.
It is in this context that some E2EE designs and architectures may It is in this context that some E2EE designs and architectures may
ultimately run contrary to user expectations of E2EE systems. ultimately run contrary to user expectations of E2EE systems
[GEC-EU] Although some system designs do not directly violate "the [GEC-EU]. Although some system designs do not directly violate "the
math" of encryption algorithms, they do so by implicating and math" of encryption algorithms, they do so by implicating and
weakening other important aspects of an E2EE _system_. weakening other important aspects of an E2EE _system_.
4.1. A conversation is confidential 4.1. A conversation is confidential
Users talking to one another in an E2EE system should be the only Users talking to one another in an E2EE system should be the only
ones that know what they are talking about [RFC7624]. People have ones that know what they are talking about [RFC7624]. People have
the right to privacy as defined in international human rights law and the right to data privacy as defined in international human rights
within the right to free expression and to hold opinions is inferred law and within the right to free expression and to hold opinions is
the right to whisper, whether or not they are using digital inferred the right to whisper, whether or not they are using digital
communications or walking through a field. communications or walking through a field.
4.2. Providers are trustworthy 4.2. Providers are trustworthy
While trustworth can be rigourously defined from an engineering While "trustworthy" can be rigourously defined from an engineering
perspective, for the purposes of this document we choose a definition perspective, for the purposes of this document we choose a definition
of Trustworthy inspired by an internal workshop by Internet Society of Trustworthy inspired by an internal workshop by Internet Society
staff: staff:
Trustworthy A system is completely trustworthy if and only if it is Trustworthy A system is completely trustworthy if and only if it is
completely resilient, reliable, accountable, and secure in a way completely resilient, reliable, accountable, and secure in a way
that consistently meets users' expectations. The opposite of that consistently meets users' expectations. The opposite of
trustworthy is untrustworthy. trustworthy is untrustworthy.
This definition is complete in its positive and negative aspects: This definition is complete in its positive and negative aspects:
what it is, eg "Worthy of confidence" and what it isn't, eg in RFC what it is, e.g. "Worthy of confidence" and what it is not, e.g. in
7258: "behavior that subverts the intent of communicating RFC 7258: "behavior that subverts the intent of communicating parties
partieswithout the agreement of those parties." [RFC7258] without the agreement of those parties" [RFC7258].
Therefore, a trustworthy end-to-end encrypted communication system is Therefore, a trustworthy end-to-end encrypted communication system is
the set of functions needed by two or more parties to communicate the set of functions needed by two or more parties to communicate
among each other in a confidential and authenticated fashion without among each other in a confidential and authenticated fashion without
any third party having access to the content of that communication any third party having access to the content of that communication
where the functions that offer the confidentiallity and authenticity where the functions that offer the confidentiality and authenticity
are trustworthy. are trustworthy.
4.3. Access by a third-party is impossible 4.3. Access by a third-party is impossible
No matter the specifics, any methods used to access to the content of No matter the specifics, any methods used to access to the content of
the messages by a third party would violate a user's expectations of the messages by a third party would violate a user's expectations of
E2EE messaging. "[T]hese access methods scan message contents on the E2EE messaging. "[T]hese access methods scan message contents on the
user's [device]", which are then "scanned for matches against a user's [device]", which are then "scanned for matches against a
database of prohibited content before, and sometimes after, the database of prohibited content before, and sometimes after, the
message is sent to the recipient." [GEC-EU] message is sent to the recipient" [GEC-EU]. Third party access also
covers cases without scanning - namely, it should be possible for any
third-party end point to access the data regardless of reason.
If a method makes private communication, intended to be sent over an If a method makes private communication, intended to be sent over an
encrypted channel between end points, available to parties other than encrypted channel between end points, available to parties other than
the recipient, without formally interfering with channel the sender and intended recipient(s), without formally interfering
confidentiality, that method violates the understood expectation of with channel confidentiality, that method violates the understood
that security property. expectation of that security property.
4.4. Pattern inference is minimised 4.4. Pattern inference is minimised
Analyses such as traffic fingerprinting or homomorphic encryption Analyses such as traffic fingerprinting or other (encrypted or
computations should be considred outside the scope of an E2EE unencrypted) data analysis techniques should be considered outside
system's goals of providing secure communications to end users. the scope of an E2EE system's goals of providing secure
communications to end users.
Such methods of analyses, outside of or as part of E2EE system Such methods of analyses, outside of or as part of E2EE system
design, allows third parties to draw inferences from communication design, allow third parties to draw inferences from communication
that was intended to be confidential. "By allowing private user data that was intended to be confidential. "By allowing private user data
to be scanned via direct access by servers and their providers," the to be scanned via direct access by servers and their providers," the
use of these methods should be considered an affront to "the privacy use of these methods should be considered an affront to "the privacy
expectations of users of end-to-end encrypted communication systems." expectations of users of end-to-end encrypted communication systems"
[GEC-EU] [GEC-EU].
Not only should an E2EE system value user privacy by not allowing Not only should an E2EE system value user data privacy by not
pattern inference, it should actively be attempting to solve issues enabling pattern inference, it should actively be attempting to solve
of metadata and traceability (enhanced metadata) through further issues of metadata and traceability (enhanced metadata) through
innovation that stays ahead of advances in these techniques. further innovation that stays ahead of advances in these techniques.
4.5. The e2ee system is not compromised 4.5. The E2EE system is not compromised
RFC 3552 talks about the Internet Threat model such as the assumption RFC 3552 talks about the Internet Threat model such as the assumption
that the user can expect any communications systems, but perhaps that the user can expect any communications systems, but perhaps
especially E2EE systems, not being compromised.[RFC3552] Compromises especially E2EE systems, to not be intentionally compromised
to E2EE systems are often referred to as "backdoors" but are often [RFC3552]. Intentional compromises of E2EE systems are often
presented as additional design features like "key escrow." Users of referred to as "backdoors" but are often presented as additional
E2EE systems would not expect a front, back or side door entrance design features under terms like "key escrow." Users of E2EE systems
into their confidential conversations and would expect a provider to would not expect a front, back or side door entrance into their
actively resist- technically and legally- compromise through these confidential conversations and would expect a provider to actively
means. resist - technically and legally - compromise through these means.
5. Conclusions 5. Conclusions
From messaging to video conferencing, there are many competing From messaging to video conferencing, there are many competing
features in an E2EE system that is secure and usable. The most well features in an E2EE system that is secure and usable. The most well
designed system cannot meet the expectations of every user, nor does designed system cannot meet the expectations of every user, nor does
an ideal system exist from any dimension. E2EE is a technology that an ideal system exist from any dimension. E2EE is a technology that
is constantly improving to achieve the ideal as defined in this is constantly improving to achieve the ideal as defined in this
document. document.
Features and functionalities of e2ee systems should be developed and Features and functionalities of E2EE systems should be developed and
improved in service of end user expectations for privacy preserving improved in service of end user expectations for privacy preserving
communications. communications.
6. Acknowledgements 6. Acknowledgements
Fred Baker, Stephen Farrell, Richard Barnes, Olaf Kolkman all Fred Baker, Stephen Farrell, Richard Barnes, Olaf Kolkman all
contributed to the early strategic thinking of this document and contributed to the early strategic thinking of this document and
whether it would be useful to the IETF community. whether it would be useful to the IETF community.
The folks at Riseup and the LEAP Encryption Access Project have The folks at Riseup and the LEAP Encryption Access Project have
skipping to change at page 11, line 26 skipping to change at page 13, line 5
[dkg] Gillmor, D., "Human Rights Protocol Considerations [dkg] Gillmor, D., "Human Rights Protocol Considerations
Glossary", 2015, Glossary", 2015,
<https://tools.ietf.org/html/draft-dkg-hrpc-glossary-00>. <https://tools.ietf.org/html/draft-dkg-hrpc-glossary-00>.
[GEC-EU] Global Encryption Coaliation, ., "Breaking encryption [GEC-EU] Global Encryption Coaliation, ., "Breaking encryption
myths: What the European Commission's leaked report got myths: What the European Commission's leaked report got
wrong about online security", 2020, wrong about online security", 2020,
<https://www.globalencryption.org/2020/11/breaking- <https://www.globalencryption.org/2020/11/breaking-
encryption-myths/>. encryption-myths/>.
[komlo] Chelsea Komlo, ., "Defining end-to-end security", 2021,
<https://github.com/chelseakomlo/e2ee/blob/master/
e2ee_definition.pdf>.
[mls] IETF, ., "Messaging Layer Security", 2018, [mls] IETF, ., "Messaging Layer Security", 2018,
<https://datatracker.ietf.org/doc/charter-ietf-mls>. <https://datatracker.ietf.org/doc/charter-ietf-mls>.
[openpgp] IETF, ., "Open Specification for Pretty Good Privacy", [openpgp] IETF, ., "Open Specification for Pretty Good Privacy",
2020, 2020,
<https://datatracker.ietf.org/doc/charter-ietf-openpgp>. <https://datatracker.ietf.org/doc/charter-ietf-openpgp>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
 End of changes. 41 change blocks. 
95 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/