/
manifesto.txt
165 lines (140 loc) · 7.34 KB
/
manifesto.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
A Public Statement Regarding Ubiquitous Encryption on the XMPP Network
Version: 0.5
Last Updated: 2014-03-21
We, as operators of federated services and developers of software
programs that use the XMPP standard for instant messaging and
real-time communication, commit to establishing ubiquitous encryption
over our network on May 19, 2014.
Jabber/XMPP technologies were first released on January 4, 1999, by
Jeremie Miller. Since then, channel encryption using Secure Sockets
Layer (SSL) and Transport Layer Security (TLS) has been optional on
the Jabber/XMPP network. Out of respect for the users of our software
and services, we believe it is time to make such encryption mandatory.
Therefore we commit to the following policies, consistent with the
IETF Internet-Draft "Use of Transport Layer Security in XMPP"
<https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/>.
For software implementations:
o support the STARTTLS method in XMPP as specified in RFC 6120,
including mandatory-to-implement cipher suites and certificate
validation consistent with RFC 6125
o prefer the latest version of TLS (TLS 1.2), but provide a
configuration option to negotiate TLS 1.1, TLS 1.0, or SSLv3
for backward compatibility with existing deployed software
o disable support for SSLv2
o provide configuration options to require channel encryption for
client-to-server and server-to-server connections
o provide configuration options to prefer or require cipher
suites that enable forward secrecy
o prefer authenticated encryption (via digital certificates) for
server-to-server connections; if authenticated encryption is not
available, provide a configuration option to allow fallback to
unauthenticated encryption with identity verification using the
XMPP Server Dialback extension (XEP-0220)
o ideally, provide user or administrative interfaces showing:
o if a given client-to-server or server-to-server connection
is encrypted, authenticated, or both
o the version of TLS and the cipher suite in use
o details about a server's certificate
o a warning about any changes to a server's certificate
For service deployments:
o require the use of TLS for both client-to-server and
server-to-server connections, preferably with authentication
(RFC 6125) but as a fallback using unauthenticated encryption
in the form of TLS plus Server Dialback
o prefer or require TLS cipher suites that enable forward secrecy
o if possible, deploy certificates issued by well-known and
widely-deployed certification authorities (it is known that
multi-tenanted hosting services are unable to obtain or
manage certificates for hosted domains)
The schedule we agree to is:
January 4, 2014 - first test day requiring encryption
February 22, 2014 - second test day
March 22, 2014 - third test day
April 19, 2014 - fourth test day
May 19, 2014 - permanent upgrade to encrypted network, coinciding
with Open Discussion Day <http://opendiscussionday.org/>
This commitment to encrypted connections is only the first step
toward more secure communication using XMPP, and does not obviate
the need for technologies supporting end-to-end encryption (such as
Off-the-Record Messaging or OTR), strong authentication, channel
binding, secure DNS, server identity checking, and secure service
delegation. Although we have worked to implement and deploy such
technologies and will continue to do so, we believe that encrypting
the traffic on the XMPP network is a necessary precondition to
offering further security improvements.
Signed,
Peter Saint-Andre, operator of jabber.org and author of XMPP RFCs
Jeremie Miller, inventor of Jabber
Simon Tennant, founder and CEO of buddycloud Ltd.
Ralph Meijer, operator of ik.nu
Thijs Alkemade, lead developer of Adium
Matthew Wild, founder of the Prosody IM server project
Philipp Hancke, co-author of Server Dialback specification
Stefan Eckbauer, CTO of ESTOS GmbH
Patrick R. McDonald, operator of the antagonism.org XMPP server
Mike Taylor (bear), Operations for &yet
Adam Brault, &yet CEO
Ralph J. Mayer, operator of nerd-residenz.de XMPP server
Andreas Kuckartz, W3C Federated Social Web Community Group
Evgeny Khramtsov, ejabberd developer, ProcessOne
Jurre van Bergen, developer at USEOTR
George Hazan, founder of Miranda NG client
Valérian Saliou, founder of the Jappix web-client and operator of the jappix.com server
Marco Cirillo, Metronome IM developer, Jappix maintainer and admin of lightwitch.org
Nikolaus Polak, operator of linuxlovers.at XMPP server
Rafał bluszcz Zawadzki, operator of JabberPL.org
Stefan Strigler, operator of jwchat.org XMPP server
Julien Genestoux, founder Superfeedr
Emil Ivov, founder and project lead of the Jitsi FOSS client
Yana Stamcheva, Jitsi developer
Yann Leboulanger, Gajim developer
Matthew A. Miller, operator of outer-planes.net
Lloyd Watkin, on behalf of Surevine Ltd (surevine.com)
Artur Hefczyc, Tigase project maintainer
Steffen Larsen, XMPP developer (client and server), operator of various domains
Ivan Novitskii, VSTalk developer
Daniele Ricci, Kontalk project leader
Natalia Novosad, take part in VSTalk development
Matthias Wimmer, lead developer of jabberd14
Yiorgis Gozadinos, co-founder of crypho.com
Alexander Gnauck, XMPP developer (libraries), operator of various servers
Tim Schumacher, operator of boese-ban.de & krautspace.de
Michael Weibel, developer of candy chat & xmpp responsible for mila.com
Luis Gonzalez Fernandez, operator of mijabber.es
Georg Lukas, yaxim developer and yax.im operator
Fini Decima, Free Software advocate and owner of linuxbsdos.com
Nigel Kukard, operator of jabber.iitsp.com
Tobias Mädel, operator of twentypercentcooler.de and tbspace.de public XMPP servers
Adán Sánchez de Pedro Crespo, founder of waalt.com and developer of loqui.im
Kevin Walke, operator of opensheffield.net
Nathan Freitas (n8fr8), The Guardian Project & ChatSecure/Gibberbot developer
Peter Schwindt, operator of jabber.ccc.de
Jonas Wielicki, operator of federated private XMPP servers
Fran García, NekBot Developer and nekmo.org operator
Dennis Schubert, operator of dsx.cc and developer of Jabberry
Ludovic Bocquet, XMPP server operator
Benjamin Zimmer, operator of einfachjabber.de
Vasil Kolev, operator of ludost.net
Danilo Bargen, XMPP server operator
Pranesh Prakash, free software advocate and operator of federated private XMPP servers
Kim Alvefur, Prosody developer and operator of piratechat.net
Timothée Jaussoin, founder and maintainer of the Movim project and admin of the movim.eu server
Michał Piotrowski, MongooseIM developer
Christian Bendt, operator of twattle.net XMPP server
Florian Weps, hactrn.ch operator
Thomas Jost, buddycloud enthusiast and operator of pouet.im
Thomas Camaran, chatme.im operator
Sven Gawlik, operator of jabber.de
Sam Whited, operator of formulanone.net and other services
James Tait, buddycloud enthusiast and operator of wyrddreams.org
Holger Weiß, operator of jabber.fu-berlin.de
Mathieu Pasquet, poezio developer
Aleksey Bryohov, jabberon.ru service operator
Roman Kolchigin, operator of jabbik.ru, jabberik.ru
Alexey Skobkin, operator of skobkin.ru
Sergey Skripnick, operator of jabber.com.ua
Alexzander Shevchenko, operator of wotapi.ru
Linus Nordberg, operator of adb-centralen.se and other services
Oleg Alekseenko, owner of jabberworld.info, operator of linuxoid.in
Mike Gogulski, developer of python-otrxmppchannel and other XMPP software
Rene Dhemant, operator of Jabber-Server.de