< draft-knodel-e2ee-definition-00.txt   draft-knodel-e2ee-definition-01.txt >
Model-T M. Knodel mls M. Knodel
Internet-Draft CDT Internet-Draft CDT
Intended status: Informational F. Baker Intended status: Informational F. Baker
Expires: August 26, 2021 Expires: November 8, 2021
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
February 22, 2021 May 07, 2021
Definition of End-to-end Encryption Definition of End-to-end Encryption
draft-knodel-e2ee-definition-00 draft-knodel-e2ee-definition-01
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 August 26, 2021. This Internet-Draft will expire on November 8, 2021.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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-to-end principle . . . . . . . . . . . . . . . . . . 3 2.1. End point . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. End-to-end principle . . . . . . . . . . . . . . . . . . 3
2.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . 4
3. End-to-end encrypted systems design . . . . . . . . . . . . . 5 3. End-to-end encrypted systems design . . . . . . . . . . . . . 5
3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Necessary features . . . . . . . . . . . . . . . . . 5 3.1.1. Necessary features . . . . . . . . . . . . . . . . . 6
3.1.2. Optional/desirable features . . . . . . . . . . . . . 6 3.1.2. Optional/desirable features . . . . . . . . . . . . . 6
3.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . 7
4. End-user expectations . . . . . . . . . . . . . . . . . . . . 8 4. End-user expectations . . . . . . . . . . . . . . . . . . . . 8
4.1. A conversation is confidential . . . . . . . . . . . . . 8 4.1. A conversation is confidential . . . . . . . . . . . . . 8
4.2. Providers are trustworthy . . . . . . . . . . . . . . . . 8 4.2. Providers are trustworthy . . . . . . . . . . . . . . . . 9
4.3. Access by a third-party is impossible . . . . . . . . . . 9 4.3. Access by a third-party is impossible . . . . . . . . . . 9
4.4. Pattern inference is minimised . . . . . . . . . . . . . 9 4.4. Pattern inference is minimised . . . . . . . . . . . . . 9
4.5. The e2ee system is not compromised . . . . . . . . . . . 9 4.5. The e2ee system is not compromised . . . . . . . . . . . 10
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . 10 9. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 16 skipping to change at page 3, line 19
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, defined in the
IETF because of its importance to internet protocols; and encryption, IETF because of its importance to internet protocols; and encryption,
an application of cryptography and the primary means employed by the an application of cryptography and the primary means employed by the
IETF to secure internet protocols. IETF to secure internet protocols.
2.1. End-to-end principle 2.1. End point
An important question in any review of the End-to-End Principle Intuitively, an "end" either sends messages or receives them, usually
[RFC3724] is "what constitutes an end?" Intuitively, an "end" either both; other systems on the path are just that - other systems.
sends messages or receives them, usually both; other systems on the
path are just that - other systems. It is, however, not trivial to establish the definition of an end
point in isolation, because its existence inherentely depends on at
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,
which introduces nuance, described in the following sub-section.
However despite the nuance for engineers, it is now widely accepted
that the communication system itself begins and ends with the user
[RFC8890]. We imagine people (through an application's user
interface, or user agent) as components in a subsystem's design. An
important exception to this in E2EE systems might be the use of
public key infrastructure where a third party is often used in the
authentication phase to enhance the larger system's trust model.
We cannot equate user agent and user, yet we also cannot fully
separate them. As user-agent computing becomes more complex and
often more proprietary, the user agent less of an "advocate" for the
best interests of the user. This is why we focus in a later section
on the e2ee system being able to fulfil user expectations.
2.2. End-to-end principle
We needed first to answer "what constitutes an end?", which is an
important question in any review of the End-to-End Principle
[RFC3724]. However the notion of an end point is more fully defined
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's used to design around questions about which parts of the system It's 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
skipping to change at page 3, line 50 skipping to change at page 4, line 29
868 (the "Nagle algorithm"), which accumulates writes in a buffer 868 (the "Nagle algorithm"), which accumulates writes in a buffer
until there is no data in flight between the communicants, and then until there is no data in flight between the communicants, and then
sends it - which might happen several times during a single search by sends it - which might happen several times during a single search by
the RIB manager. In that sense, the RIB manager might be thought of the RIB manager. In that sense, the RIB manager might be thought of
as the "end", because it decides what should be communicated, or TCP as the "end", because it decides what should be communicated, or TCP
might be the "end", because it actually sends the TCP Segment, might be the "end", because it actually sends the TCP Segment,
detects errors if they occur, retransmits it if necessary, and detects errors if they occur, retransmits it if necessary, and
ultimately decides that the segment has been successfully ultimately decides that the segment has been successfully
transferred. transferred.
However despite the nuance for engineers, it is now widely accepted
that the communication system itself begins and ends with the user
[RFC8890]. We imagine people (through an application's user
interface) as components in a subsystem's design. An important
exception to this in E2EE systems might be the use of public key
infrastructure where a third party is often used in the
authentication phase to enhance the larger system's trust model.
Another important question is "what statement exactly summarizes the Another important question is "what statement exactly summarizes the
end-to-end principle?". Saltzer answered this in two ways, the first end-to-end principle?". Saltzer answered this in two ways, the first
of which is that the service implementing the transaction is most of which is that the service implementing the transaction is most
correct if it implements the intent of the application that sent it, correct if it implements the intent of the application that sent it,
which would be to move the message toward the destination address in which would be to move the message toward the destination address in
the relevant IP header. Salzer's more thorough treatment, however, the relevant IP header. Salzer's more thorough treatment, however,
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.
2.2. 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
 End of changes. 15 change blocks. 
30 lines changed or deleted 47 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/