Open Bug 1550481 Opened 5 years ago Updated 2 years ago

When using XMPP with OTR, disable Message Carbons and tag messages as private and no-copy

Categories

(Chat Core :: Security: OTR, enhancement)

Product:
Chat Core
Component:
Security: OTR
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: KaiE, Unassigned)

References

Details

XMPP can send messages to multiple devices because of the Message Carbons feature (implemented and enabled in Thunderbird). This can cause confusion with OTR v2.

(Although OTR v3 has some support to handle multiple sessions, we haven't implemented the UI for it yet, and it's not yet clear if we should, or could do it in a reliable way. For now, we'll likely keep v3 disabled. See also bug 1550474.)

There are recommendations to disable Message Carbons when using OTR, e.g. see:

The latter text says that outgoing OTR messages should be tagged as "private" and "no-copy".

IIUC, when adding these tags, it seems OK to keep Message Carbons generally enabled.

We should implement sending these tags.

I performed some tests.

I started TB twice. Both connect to the same XMPP account. Then I use a third program (coyim), to chat with one of the running TB.

For the first test, I disabled otr in both TB.
Both sent and received messages are carbon copied to the second TB, too.

In the second test, I enabled otr in both TB.
The second TB did not display any of the messages, neither the initial plaintext message, nor the encrypted messages.

Maybe coyim marked the messages as private/nocopy.

Thanks for investigating this, my initial interpretation was that we needed to do something when Thunderbird was sending messages, not receiving them?

For the next test, I again started two TB instances, connected to the same XMPP account.

In addition, I started a third TB, connected to a different account.

If I chat from TB 2 to TB 3, messages sent by TB 2 are displayed by TB 3, only.
Messages sent by TB are displayed by both TB 2 and TB 1.

If I start OTR using TB 2, then a successful session is started with TB3.
However, TB 1 displays an error, that I couldn't establish OTR.
This means messages were carbon copied to TB 1.

Fixing this bug would prevent this error.

(In reply to Patrick Cloke [:clokep] from comment #2)

Thanks for investigating this, my initial interpretation was that we needed to do something when Thunderbird was sending messages, not receiving them?

You're still correct.

In the experiment from comment 1, coyim probably tagged the sent messages accordingly, so the server prevented them from being carbon copied. It's probably sufficient if one partner of the conversation does the tagging.

In the experiment from comment 3, both sides were TB, neither did that tagging. So carbon copy was active and created confusion.

This is a message received by Thunderbird from coyim (I removed from/to):

<message xmlns="jabber:client" from="" to="" type="chat">
<body xmlns="jabber:client">
?OTRv23? Your peer has requested a private conversation with you, but your client doesn't seem to support the OTR protocol.
</body>
<x xmlns="google:nosave" value="enabled"/>
<record xmlns="http://jabber.org/protocol/archive" otr="require"/>
<no-copy xmlns="urn:xmpp:hints"/>
<no-permanent-store xmlns="urn:xmpp:hints"/>
<private xmlns="urn:xmpp:carbons:2"/>
</message>

It uses a tag to indicate "private", which seems to be intended for consumers that understand the carbons feature.
<private xmlns="urn:xmpp:carbons:2"/>

It uses a tag to indicate no-copy:
<no-copy xmlns="urn:xmpp:hints"/>

In addition, it includes a tag that requests the other side to not create a log of the conversation:
<no-permanent-store xmlns="urn:xmpp:hints"/>

Both no-copy and no-permanent-store are explained in
https://xmpp.org/extensions/xep-0334.html

IMHO, if the local Thunderbird user has disabled logging (cf. bug 1536104), then TB should also send the no-permanent-store hint.

Component: General → Security: OTR
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.