-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathdraft-muffett-end-to-end-secure-messaging-04.txt
224 lines (148 loc) · 8.82 KB
/
draft-muffett-end-to-end-secure-messaging-04.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
CFRG A. Muffett
Internet-Draft Security Researcher
Intended status: Informational 8 November 2022
Expires: 12 May 2023
A 'Duck Test' for End-to-End Secure, Encrypted Messenger Software
draft-muffett-end-to-end-secure-messaging-04
Abstract
This internet-draft describes a test which MAY be used, either singly
or in association with further tests, to establish whether end-to-end
secure, encrypted messenger software correctly exhibits behaviours
that are commonly associated with those and related descriptions of
messenger software.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 May 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Muffett Expires 12 May 2023 [Page 1]
Internet-Draft e2esm November 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Work in Progress . . . . . . . . . . . . . . . . . . . . 2
1.2. Why CFRG? . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Why a 'Duck Test'? . . . . . . . . . . . . . . . . . . . 2
1.4. Why only 'Messenger Software'? . . . . . . . . . . . . . 3
2. The 'Field Model' . . . . . . . . . . . . . . . . . . . . . . 3
2.1. The 'Duck Test' . . . . . . . . . . . . . . . . . . . . . 4
2.2. 'Learn Some Information'? . . . . . . . . . . . . . . . . 4
2.3. 'Conditions and Exceptions' . . . . . . . . . . . . . . . 4
1. Introduction
1.1. Work in Progress
This document is a complete rewrite from the ground up; if you are
interested in seeing contextual previous work, see the "draft-
muffett-end-to-end-secure-messaging-04-abandoned" series.
1.2. Why CFRG?
The IRTF CFRG charter (https://datatracker.ietf.org/doc/charter-irtf-
cfrg/01/) says:
| The CFRG serves as a bridge between theory and practice, bringing
| new cryptographic techniques to the Internet community and
| promoting an understanding of the use and applicability of these
| mechanisms via Informational RFCs ... Our goal is to provide a
| forum for discussing and analyzing general cryptographic aspects
| of security protocols, and to offer guidance on the use of
| emerging mechanisms and new uses of existing mechanisms.
This internet-draft proposes an informational RFC which assists
understanding of the use and applicability of end-to-end secure,
encrypted messenger software. This is achieved via discussion and
analysis of general cryptographic aspects of the security which such
software commonly offers, thereby providing the reader with guidance
regarding the use - especially fitness and choice - of such software.
Hence this internet-draft is submitted to CFRG.
1.3. Why a 'Duck Test'?
There are efforts afoot to help a user determine whether some
software 'looks' like end-to-end secure, encrypted messenger
software. Such determinations may require considerable information,
discussion of nuance, and application of considerable judgement.
Muffett Expires 12 May 2023 [Page 2]
Internet-Draft e2esm November 2022
By contrast, this internet-draft specifies a simple 'falsifiability'
test using which a person may establish whether some software does
not 'quack' in the way that end-to-end secure, encrypted messenger
software is commonly expected.
The described test is not intended to be complete; additional tests,
checks and obligations may be brought to bear by people who wish to
determine whether some software also offers other characteristics
such as 'anonymity', or broader forms of 'metadata privacy'.
If some software fails to satisfy the duck test, it will be deemed
only to have failed the duck test, and nothing more excepting that by
failing the duck test we can clearly state that the software fails to
exhibit some commonly expected characteristics of end-to-end secure,
encrypted messenger software.
1.4. Why only 'Messenger Software'?
This internet-draft is written for the test to be applied to end-to-
end secure, encrypted messenger software.
It may be that the concepts describe could be more broadly applied -
for instance to other encrypted transport protocols - but the scale
of adoption, invention, and discussion of messenger software demands
a focused document which deals exclusively with the particular use-
case, common features and foibles of end-to-end secure, encrypted
messenger software.
Future documents may explore the aspects of this duck test which are
well-suited for other purposes.
2. The 'Field Model'
Several key sources on encryption and privacy (TK, TK, TK) observe
using similar terms that in pre-industrial-revolution societies:
| All that was once necessary for two or more people to have a
| private conversation was for them to walk into a field - away from
| eavesdroppers - where they could simply talk...
We refer to this as the 'field model' of secure communication, and
observe several characteristics from which we derive the duck test:
* There is a 'speaker', who will be the 'first party', named 'Alice'
('A')
* There are 'listeners', who will be 'second parties', named 'Bob'
('B'), 'Carol' ('C'), 'Dave' ('D'), etc...
Muffett Expires 12 May 2023 [Page 3]
Internet-Draft e2esm November 2022
* The speaker, and the listeners which are visible to the speaker as
standing 'within earshot' alongside her in the field, comprise the
'participants' for a given message as uttered by the speaker
* Each message may have different 'participation', as Bob, Carol,
and Dave variously arrive and depart, all being seen by Alice
* There is a 'field' or 'platform' ('P') for the conversation,
acting as a 'third party', analogous to 'WhatsApp' or 'Signal' or
other end-to-end secure, encrypted messenger software; the third
party is inert ground and is incapable of comprehension of the
conversation
* All other entities outside of these three sets, are 'fourth
parties'
2.1. The 'Duck Test'
From the above we may define the duck test:
| Subject to a fixed set of conditions and exceptions: for any given
| message, if *any* entity that was not a 'participant' for that
| message *may* use partial or complete knowledge of the platform -
| including logs of past-sent and future-sent messages - to learn
| *some* information regarding that message's content, then the
| platform fails to satisfy the duck test
2.2. 'Learn Some Information'?
The duck test pivots upon an entity which was not first- or second-
party to a message, "learning some information" about that message.
How much is "some information"?
| For the duck test we define "learning about a single bit of
| message content to greater than 50% certainty" as being sufficient
| information to have learned so as to cause failure of the test
This condition extends beyond message content into some aspects of
sensitive metadata - for instance zero (or very short) message
lengths can leak single bits of message content to greater than 50%
certainty, and therefore must be mitigated.
2.3. 'Conditions and Exceptions'
...
Muffett Expires 12 May 2023 [Page 4]