Changes between Initial Version and Version 1 of EndToEndXMPPCrypto

Timestamp:

Jan 26, 2014, 1:27:52 AM (10 years ago)

Author:

elb

Comment:

--

EndToEndXMPPCrypto

@@ +1 @@
+= An End-to-End XMPP Cryptographic Protocol Desiderata =
+
+This is an idea [wiki:elb] has been kicking around for a long time.  This page does not represent due diligence on existing efforts; there may be a candidate protocol in the works that [wiki:elb] is simply not aware of.  Compare-and-contrasts with existing protocols or protocol proposals are welcome.
+
+== Rationale ==
+
+There are numerous end-to-end crypto protocols for IM, but they suffer from a myriad of flaws, or target a use case that I do not find ideal.  Some of them are even very good at what they do.  This protocol is not intended to supplant those that are very good at what they do, but to provide a specific, simple but secure user experience to encourage universal secure communications over XMPP.
+
+Some specific flaws I see in existing protocols that I would like to avoid are:
+
+ * '''Proprietary.'''  This is an obvious non-starter; several protocols provide native e2e crypto facilities that are undocumented, require buy-in (or even authentication) from the provider, etc.
+ * '''Protocol-agnostic.'''  While this is a feature in some sense, it is also limiting.  OTR, for example, is a successful, portable, and secure protocol with many features going for it.  However, its protocol agnosticism is both a strength and a weakness.  It's great to be able to secure conversations over a variety of networks, both open and proprietary, but lack of protocol integration means that, for example, advertising OTR capability through XMPP presence is not supported.  (To my knowledge, at least!)
+ * '''Reliance on SSL PKI.'''  Similar to proprietary protocols, this is an obvious non-starter.  Who trusts those guys?
+ * '''Limited third-party authentication functionality.'''  Most or all existing protocols provide only limited support for authenticating an interlocutor's keys.  In some cases the keys are used only for the protocol in question, and verification is provided only by the client itself.  Some protocols use exclusively a specific third-party authentication mechanism (e.g., GPG or x.509 certificates with CA signatures).