Subject: [xmpp] 3920bis: truth in advertising

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Oct 2010 15:16:56 -0600

Something has been nagging at me. In 3920bis we talk about how TLS helps
to ensure confidentiality and integrity at the stream level, but we
don't mention that per-stream encryption does not ensure end-to-end
protection of stanzas. I think it would be appropriate to call out that
fact so we don't lead people astray (and I would expect the reviewer
from the security directorate to do so anyway, so we might as well be
proactive). Here is proposed text for a new security note that I suggest
we add to Section 13.4 ("Confidentiality and Integrity"):

      Security Note: The use of TLS in XMPP applies to a single stream.
      Because XMPP is typically deployed using a distributed client-
      server architecture (as explained under Section 2.5), a stanza
      might traverse multiple streams, and not all of those streams
      might be TLS-protected.  For example, a stanza sent from a client
      with a session at one server (e.g., <[email-masked]/orchard>)
      and intended for delivery to a client with a session at another
      server (e.g., <[email-masked]/balcony>) will traverse three
      streams: the stream from the sender's client to its server, the
      stream from the sender's server to the recipient's server, and the
      stream from the recipient's server to the recipient's client.
      Furthermore, the stanza will be processed as cleartext within the
      sender's server and the recipient's server.  Therefore, even if
      the stream from the sender's client to its server is protected,
      the confidentiality and integrity of a stanza sent over that
      protected stream cannot be guaranteed when the stanza is processed
      by the sender's server, sent from the sender's server to the
      recipient's server, processed by the recipient's server, or sent
      from the recipient's server to the recipient's client.  Only a
      robust technology for end-to-end encryption could ensure the
      confidentiality and integrity of a stanza as it traverses all of
      the "hops" along a communication path.  Unfortunately, the XMPP
      community has so far failed to produce an end-to-end encryption
      technology that might be suitable for widespread implementation
      and deployment, and definition of such a technology is out of
      scope for this document.

/psa

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 18 Oct 2010 17:44:23 -0400

As someone who is scheduled to do a SECDIR review on this document,  
that makes sense to me. It clearly documents what you do and don't get  
from the TLS protections in XMPP (in the 3920bis sense).  The one  
thing you might add is pointer(s) to some of the potential solutions,  
e.g., RFC 3923 or maybe XEP-0285.

--Richard

On Oct 18, 2010, at 5:16 PM, Peter Saint-Andre wrote:

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Oct 2010 16:04:14 -0600

Potential solutions? There are so many! In roughly chronological order
they are:

1. XEP-0027

2. RFC 3923

3. Off-The-Record Messaging (not XMPP-specific)

4. XEP-0116

5. xmlenc / xmldsig (supposedly in use but never documented)

6. draft-meyer-xmpp-e2e-encryption

7. draft-miller-3923bis

8. XEP-0285

I realize that the great thing about standards is that there are so many
to choose from, but this is getting ridiculous. I'd prefer not to point
out this embarrassment of failures. :)

On 10/18/10 3:44 PM, Richard L. Barnes wrote:
> As someone who is scheduled to do a SECDIR review on this document, that
> makes sense to me. It clearly documents what you do and don't get from
> the TLS protections in XMPP (in the 3920bis sense).  The one thing you
> might add is pointer(s) to some of the potential solutions, e.g., RFC
> 3923 or maybe XEP-0285.
> 
> --Richard
> 
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 18 Oct 2010 18:10:33 -0400

Well, ok, but it still seems like there should be *something* positive  
to say :)  Maybe you could say what sort of thing would need to be  
implemented, e.g., object encryption of stanzas or some sort of secure  
channel riding on top of the various XMPP streams.

On Oct 18, 2010, at 6:04 PM, Peter Saint-Andre wrote:

>> that

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Oct 2010 16:19:21 -0600

Ah, so much is captured in that little word "should". :)

But seriously, we could add an informative reference to:

http://tools.ietf.org/html/draft-ietf-xmpp-e2e-requirements

Which is, itself, expired! But we'll restart that work once we've
completed our revisions to 3920/3921, I'd imagine...

---

From: Justin Karneges <[email-masked]>
Date: Mon, 18 Oct 2010 15:22:36 -0700

> out this embarrassment of failures. :)

And don't forget:
  http://xmpp.org/extensions/inbox/secure.html

;)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Oct 2010 16:24:45 -0600

>   http://xmpp.org/extensions/inbox/secure.html

Indeed! Anyone else have proposals? :)

/psa

---

From: Dave Cridland <[email-masked]>
Date: Tue, 19 Oct 2010 09:06:04 +0100

> Indeed! Anyone else have proposals? :)

I think that having a failed E2E encryption proposal is just a rite  
of passage for an XMPP expert. It's probably a requirement for a  
position in the XSF.

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