[Standards] end-to-end encryption meeting

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Fri Nov 2 02:46:41 UTC 2007

On Thursday 01 November 2007 3:49 pm, Peter Saint-Andre wrote:
> We held a preliminary discussion in the Council room today among some
> folks who are interested (mainly the Board and Council, with invites to
> two people who have implemented Encrypted Sessions and proto-XTLS):
> http://www.jabber.org/muc-logs/council@conference.jabber.org/2007-11-01.html

To add my thoughts: (long :))

For e2e, it is important to consider the user experience aspect and the 
technical aspect.  The current state of affairs is that many people find 
XEP-27 inadequate, and many people love OTR (which esessions is essentially 
modeled after).  Why is this?

User experience: PGP is a huge hassle.  OTR "just works".  OTR generates keys 
in the background, no fuss.  Sure, there's a fingerprint you may have to 
check, but the user can just ignore that step.  Users can blindly sign PGP 
keys as well, but this still requires more effort than simply clicking 
the "continue anyway, i really don't care" button in an OTR app.

Technical: XEP-27 doesn't offer replay prevention, forward secrecy, or 
deniability.  OTR has all of these things.  Users don't really care about 
this though, and I'm pretty sure these features have little to do with OTR's 

It is also worth noting that OTR is possibly (?) the first cross-client IM 
security solution that isn't tied to PGP.  For years we've had clients 
develop their own proprietary security mechanisms, and so 
this "standardization" to OTR is a nice change.

The criticism to OTR, as well as to esessions, is that these protocols came 
out of nowhere.  They have not passed the same security review as other 
specifications, and are thus not as proven.  Esessions is particularly 
experimental.  OTR is less-so, but it suffers from having basically one 
implementation.  We are interested in standard protocols and formats, not 
standard implementations.  For OTR or esessions to have the same credibility 
as OpenPGP or S/MIME, they will need not only review, but many 
implementations, and ideally RFC status (more weight than a XEP) of at least 
some portions of their process.

Of course, users don't care about security reviews or usage of proven 
protocols.  It is up to developers and standards creators (read: us) to care 
about these things, or nobody will.

So, here's a question: can we create a protocol that allows the same user 
experience as OTR, but instead is based on something proven?  I believe the 
answer is yes.  Both RFC 3923 and XTLS would allow for an identical user 
experience as OTR.  Sure, these systems may have different underlying crypto 
featuresets than OTR (e.g, neither have deniability), but they are featureful 
enough for most purposes.

Does this mean we should abandon esessions?  I don't think so.  It offers the 
ultimate set of features that we would like to have eventually, and it takes 
advantage of XMPP in ways other protocols can't.  It is looking to the 
future.  However, it doesn't offer any user experience improvements over the 
other options (except for perhaps its use of SAS, but I'd like to investigate 
if we can do that in an S/MIME or TLS context before granting that).  With 
that in mind, we could develop a system that is good enough today *and* that 
the user can fall in love with.  We don't need OTR or esessions to have such 
a system.


More information about the Standards mailing list