Subject: [xmpp] Why no E2E security solution?

From: Sean Turner <[email-masked]>
Date: Mon, 08 Nov 2010 11:37:10 +0800

I'm curious about the root cause for why an E2E security solution hasn't 
been deployed.

I've heard from a couple of people that the reason is that there's no 
JavaScript support for "it".  I assume that the "it" is either ASN.1 
and/or crypto.  Is this really the reason an implemented E2E solutions 
hasn't materialized?

Is another reason maybe that there's no customers asking for an E2E 
security solution

spt

---

From: Justin Karneges <[email-masked]>
Date: Sun, 7 Nov 2010 20:44:17 -0800

> and/or crypto.  Is this really the reason an implemented E2E solutions

There has been marginal success with XEP-0027 and OTR.  I think the reason 
none of the more recent proposals have caught on is two part:

  1) For the people that do care about e2e security, the sheer number of 
different proposals makes for quite a standardization mess (Peter counted 6 
competing specs the other day?).  Part of why we have so many specs is the 
fact that we haven't been able to agree on requirements.  Plausible 
Deniability was big at one point.  Interest in signed stanzas comes and goes, 
much like the McRib.

  2) They are harder to implement.  contrast to PGP and OTR which have 
libraries that act like simple black boxes.

> Is another reason maybe that there's no customers asking for an E2E

Could be.  I know a big selling point of most XMPP server vendors is the 
ability to log chats for corporate compliance (solving the problem of 
employees running around using unregulated AIM or MSN), and e2e encryption 
certainly doesn't help with that.

Similar to lack of consumer pressure is the lack of time in open source 
projects.  I personally didn't think RFC 3923 was terrible, and I would have 
implemented it had there not been more pressing things in the way.

-Justin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 08 Nov 2010 13:40:04 +0800

Based on a few minutes of googling, it doesn't seem like it would be a 
Herculean effort to write a Javascript library that parses CMS.  There 
are existing things out there that do basically all of the heavy 
lifting, for example:

ASN.1: <http://lapo.it/asn1js/>
RSA:   <http://www.ohdave.com/rsa/>
DES:   <http://www.tero.co.uk/des/>
AES:   <http://www.movable-type.co.uk/scripts/aes.html>

--Richard

On 11/8/10 11:37 AM, Sean Turner wrote:
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Dave Cridland <[email-masked]>
Date: Mon, 08 Nov 2010 14:00:15 +0000

> Is another reason maybe that there's no customers asking for an E2E  

Whilst lots of people really like the notion that there exists an  
end-to-end security technology, what we have in the way of identity  
assurance is in practical terms (seen as) good enough. Spoofing  
servers (and therefore end-user jids) is indeed possible with the  
current deployment on the internet, but not very easy, and certainly  
not as practical as simply registering a bunch of essentially  
anonymous accounts.

When "proper" TLS-based authentication is used for servers, then it  
becomes very difficult to spoof a domain, in which case the added  
value of E2E is slim, and largely based on distrust of a peer  
server's authentication policy - this itself seems less likely in the  
kinds of environments where security is this important.

Similarly for signing, there is a strong requirement and much nodding  
of heads that signing is important (especially with security labels,  
which XMPP has via XEP-0258), but the requirements feels, to me, to  
be much more of a rubber-stamping exercise to satisfy received wisdom.

Finally, the barriers to adoption are usually high. For example in  
the face of low bandwidth cases, where compression and stanza sizes  
are important, it seems to me that the added value for both E2E  
encryption and E2E signing is entirely overridden by practical  
concerns.

(This may be read as saying there's no point working on these kinds  
of technologies, which I don't think is the case - I think we should  
be both minimizing the barriers and maximizing the benefits most  
carefully, however).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 8 Nov 2010 06:16:36 -0800

On Nov 7, 2010, at 7:37 PM, Sean Turner wrote:

> I'm curious about the root cause for why an E2E security solution hasn't been deployed.
> I've heard from a couple of people that the reason is that there's no JavaScript support for "it".  I assume that the "it" is either ASN.1 and/or crypto.  Is this really the reason an implemented E2E solutions hasn't materialized?
> Is another reason maybe that there's no customers asking for an E2E security solution

There's lots of reasons.   Personally, I think the lack of solution solutions is more tied to demand than anything else.   There's very little demand for such solutions and what demand there is is quite fragmented (different desires/needs in the space), leading to a wide range of different solutions, each of which is tended to have fairly narrow scope.

I suspect that much of the small consumer demand for E2E security solution will more likely get met by E2E secure channel over XMPP solution than an XMPP XMPP object level encryption solution, and hence suspect we'll see broader support for former first.

Here at Isode, we have some customer demand for object-level digital signatures (though not necessarily E2E) and, hence, will be nudge forward a (yet another) specification to met these demands.  XEP-274 discusses why I think yet another solution is need.   I'm currently drafting a solution which utilized encapsulated signature (as opposed to the encapsulating signature approaches we have in various other specs, including the recently introduced XEP 285).

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Nov 2010 03:29:10 +0800

On 11/8/10 11:37 AM, Sean Turner wrote:
> security solution?

Justin Karneges, Dave Cridland, and Kurt Zeilenga have explained the
core reasons why e2e security hasn't caught on. IMHO the (perceived)
lack of ASN.1/PKIX support in JavaScript is not the primary cause. If it
were, the path forward would be clearer than it is. It's much more
difficult to deal with apathy among the vast majority of end users,
positive hostility on the part of many service providers (e.g.,
enterprise deployments), developer overload and the relative difficulty
of implementing such technologies from scratch, different requirements
for different user communities, the fragmentation introduced by so many
proposals (itself driven by the fragmentation of requirements), the
"checkbox" mentality that we "must" have an e2e security solution to
nominally satisfy some approving body, etc.

So far, two technologies have been relative successes in this space:
OpenPGP (XEP-0027) and off-the-record messaging (OTR). The rest have
been abject failures. Perhaps it would be valuable to look at both of
those more closely, because they have produced running code (by which I
don't mean compiling code, I mean stuff that's actually been deployed to
some significant extent). Both OpenPGP and OTR have made it relatively
easy for client developers to add e2e security to their applications
(via gnupg and libotr). We might have had similar success with XEP-0116
if someone had developed a library that developers could have used.
Naturally the XMPP community could rally around a new technology, or it
could settle on one of the technologies that has more-or-less worked.
For various reasons I think the most likely candidate is OTR, but I'm
open to being argued out of that tentative conclusion.

Once we're well and truly done with the core specs I'll be turning more
of my attention to e2e security, but the considerations mentioned by the
previous posters in this thread make it clear that the landscape will be
difficult to navigate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/