[guardian-dev] XMPP ubiquitous encryption

Nathan of Guardian nathan at guardianproject.info
Sat Dec 28 08:07:22 EST 2013





Not sure how we missed this, but obviously we support it too!

https://raw.github.com/stpeter/manifesto/master/manifesto.txt

A Public Statement Regarding Ubiquitous Encryption on the XMPP Network Date: 2013-12-16 Version: 0.5 We, as operators of public 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-implem
 ent
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 u
 se 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 t
 oward
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, ESTOS GmbH, 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 Nov
 itskii,
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


More information about the Guardian-dev mailing list