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/[EMAIL PROTECTED]/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 popularity. 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. -Justin
