Re: [xmpp] 3920bis: truth in advertising

[Peter Saint-Andre <[e-mail]>]

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
> 
> 
> On Oct 18, 2010, at 5:16 PM, Peter Saint-Andre wrote:
> 
>> 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., <[e-mail]/orchard>)
>>      and intended for delivery to a client with a session at another
>>      server (e.g., <[e-mail]/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
>>