[Standards] Stanza Content Encryption
vanitasvitae at fsfe.org
Thu Jun 20 11:17:22 UTC 2019
Hi Philipp, Kim and Ivan,
thank you for your feedback and input.
It appears that XEP-0030 really doesn't fit in this situation, as it
cannot deal with offline devices and also doesn't really suite a
scenario where messages go to multiple receiving devices (carbons).
This could be a strong indication towards not doing any fine grained
feature negotiation, which is unfortunate for testing out early
implementations (it makes getting started way harder).
Maybe we can come up with a fix though. In case of OMEMO, the sender of
a message knows that the recipient has a device capable of OMEMO
encryption due to the fact, that that device published an OMEMO key
bundle in the first place. Same goes for OX. If the device that ends up
receiving the message is the same is another question of course ("It
appears that your device does not support OMEMO"...).
XMPP probably lacks an offline feature detection mechanism, which
functions as a device registry where the sender can determine, which
features are supported by the devices of the recipient even if those are
A hacky solution for now could be to publish an equivalent to a feature
announcement into a pubsub node. The sender could then query that node
and determine, which devices support which features. This is of course a
bad bad downgrade attack vector, but this - or a similar mechanism -
could be worth another thought.
Btw: I heard that some clients are storing client side preferences
inside PubSub. Does anyone happen to know if - and if so, how different
devices are identified/differentiated? Maybe this mechanism could be
On 18.06.19 11:03, Philipp Hörist wrote:
> Im not quite sure what you want to negotiate, but making any part of the
> encryption process depending on disco info of a online resource is a fail.
> Feature negotiation in encryption process is a fail in General. Its simply
> not needed, we have 2 encryption methods right now (OMEMO and PGP) that
> dont depend on any kind of negotiation and this works fine. One of them
> even having full stanza encryption.
> The whole encryption process must be possible while the recipient is
> offline, for the whole process. Feature negotiations also imply that there
> are multiple features to handle differently which makes implementation more
> complicated. You have to think about multiple resources online which would
> support different kind of features, and other resources offline where you
> dont even know the features, this is a nightmare i would not even start to
> Am Di., 18. Juni 2019 um 10:38 Uhr schrieb Paul Schaub <
> vanitasvitae at fsfe.org>:
>> Hi Florian!
>> Am 17.06.19 um 17:58 schrieb Florian Schmaus:
>>> On 15.05.19 16:53, Paul Schaub wrote:
>>>> Thank you very much for your eager interest and numerous replies
>>>> *cough*, in other words, Thank you Florian for your reply :D
>>>> I'm not quite sure, how exactly the process of negotiating expected
>>>> encrypted elements would look like.
>>> XEP-0030 features mostly.
>>>> I can see that this would
>>>> make it easier for adopters to gradually start implementing support for
>>>> one feature at a time (like start with support for <body/> encryption
>>>> and then successively add support for other elements as well), but at
>>>> the same time I feel like this could enable "downgrade" attacks and
>>>> would diminish the "encrypt *all* the sensitive things"-approach that I
>>>> aim for.
>>> The fact that you can gradual start implementing it is just one of the
>>> advantages. Another major advantage is that we can start implementing
>>> it *right now*.
>>> I can not stress the "get it implemented right now" as advantage
>>> enough. For one, it allows us to get implementation experience early,
>>> which is something other E2EE approaches did not, which contributed to
>>> their failure. But more importantly, we are able to reduce the
>>> percentage of unencrypted plaintext, which is still to high at the
>>> After we have secured plaintext, we can take the next step and look
>>> into securing metadata. But one step after another. I want to raise
>>> the floor for privacy first, and then the ceiling. There is no reason
>>> why we should try to tackle everything in one rush (thanks to XMPPs
>>> extensiblity property). In fact, I believe this is actually harmful
>>> because it prevents us from deloying privacy solutions because of
>>> endless discussions, while there is still plaintext on the wire.
>>> Let us start with getting rid of unencrypted messages first, and then
>>> we can focus on the metadata. We certainly should keep downgrade
>>> attacks in mind, but I don't believe that this is an argument against.
>> Fair points. I will look into XEP-0030 then to figure out how one could
>> implement the feature negotiation.
>>>> An alternative approach that some people suggested would be to replace
>>>> the envelopes content element with a normal message stanza. That way
>>>> implementations could simply decrypt that stanza, check it for forbidden
>>>> elements and remove those and then feed the cleaned stanza back into the
>>>> XML stream. That way the client wouldn't have to reimplement listeners
>>>> for all the events. On the other hand, the client would probably want to
>>>> somehow mark the decrypted stanza as end-to-end encrypted.
>>> Injecting stanzas that where never send by the server into the clients
>>> processing chain is an approach that is sometimes mentioned. It may
>>> appears to be a nifty trick at first, but I believe this is not an
>>> good idea for the following reasons:
>>> First, your premise that the client would not have to reimplement
>>> listeners is wrong. You still want to carry around the information
>>> that the data was protected by some mechanism, as you need to pass
>>> that information up to the application. Otherwhise the application can
>>> not tell the difference between a protected chat state and an
>>> unprotected one.
>>> Let's take Chat State Notifications (CSN, xep85) for example. A library
>>> implement a listener/callback/hook once such a notificaiton arrives
>>> that looks like this:
>>> chatStateChange(Chat chat, ChatState chatState, Message message)
>>> Now with protected CSNs you most certainly want to extend the callback
>>> with the information wheter or not the CSN was protected or not:
>>> chatStateChange(Chat chat, ChatState chatState, Message message,
>>> SecurityInformation securityInformation)
>>> Which allows the user to retrieve the information about the used
>>> encryption protocol, if any, from the SecurityInformation
>>> object. Otherwhise the information is not available.
>>> Secondly it feigns events that never happend. Those constructs turn
>>> usually out to be error prone and fragile. Think for example of Stream
>>> Management: Now you have to ensure that those fake received stanzas are
>>> not counted.
>> Good points. Especially the Stream Management stuff is something I
>> haven't considered.
>> Thank you for your insights :)
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards