Re: [xmpp] 3920bis: truth in advertising

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

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...

On 10/18/10 4:10 PM, Richard L. Barnes wrote:
> 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:
> 
>> 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
>>>>