[Standards] Stanza Content Encryption
vanitasvitae at fsfe.org
Thu Jun 20 11:20:57 UTC 2019
Oh and I forgot:
OpenPGP kind of solves the issue as it allows to bind encryption
preferences to the key itself. This may be worth taken into
On 20.06.19 13:17, Paul Schaub wrote:
> 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
> further extended?
> 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
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards