[Standards] Stanza Content Encryption

Paul Schaub vanitasvitae at fsfe.org
Tue Jun 18 08:36:46 UTC 2019


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
> moment.
>
> 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 may
> 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 :)



More information about the Standards mailing list