[Standards] Stanza Content Encryption

Florian Schmaus flo at geekplace.eu
Mon Jun 17 15:58:00 UTC 2019


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.

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

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190617/21c4bf57/attachment.sig>


More information about the Standards mailing list