Trac is being migrated to new services! Issues can be found in our new YouTrack instance and WIKI pages can be found on our website.

Changes between Initial Version and Version 1 of EndToEndXMPPCrypto


Ignore:
Timestamp:
Jan 26, 2014, 1:27:52 AM (10 years ago)
Author:
elb
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • EndToEndXMPPCrypto

    v1 v1  
     1= An End-to-End XMPP Cryptographic Protocol Desiderata =
     2
     3This 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.
     4
     5== Rationale ==
     6
     7There 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.
     8
     9Some specific flaws I see in existing protocols that I would like to avoid are:
     10
     11 * '''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.
     12 * '''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!)
     13 * '''Reliance on SSL PKI.'''  Similar to proprietary protocols, this is an obvious non-starter.  Who trusts those guys?
     14 * '''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).
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!