[Standards] Current OTR Info

Yann Leboulanger asterix at lagaule.org
Sun May 8 19:08:30 UTC 2016


On 05/08/2016 07:17 PM, Sam Whited wrote:
> On Sun, May 8, 2016 at 12:05 PM, Sam Whited <sam at samwhited.com> wrote:
>> On Wed, Apr 27, 2016 at 3:48 PM, Chris Ballinger <chris at chatsecure.org> wrote:
>>> A quick fix would be to only send delivery receipts if the message could be
>>> successfully decrypted.
>> I think this makes sense as a recommendation for the informational
>> XEP, but I'd love to know if anyone is actually doing it in the wild.
>> /cc Daniel
> I just sent this response, and then almost immediately did an about
> face and changed my mind (I'm fickle that way). I actually think it is
> a bad idea to send delivery receipts only if the message can be
> decrypted; my reasoning is as follows:
>
> Because the delivery receipt spec was not intended for this (and
> semantically is just supposed to express "delivery" not
> "readability"), and because there is no current consensus on when
> delivery receipts are sent during an OTR session, differnt clients
> will do different things; by allowing delivery receipts to be used for
> both, we'd be encouraging confusion and a lack of interoperability
> between clients (some clients may want to convey delivery and
> redability separately, as you mentioned). A practical example of this
> being confusing might be something like the following: Imagine I had a
> client open and I establish an OTR session with a remote resource and
> begin sending messages. I get back delivery receipts after those
> messages are decrypted. Then, for some reason, I send a message to
> another resource (maybe there was a network blip and the resource I
> was talking too loses their connection) that does not support OTR at
> all: I continue to get message delivery receipts and never notice
> anything has changed, even though the remote resource can no longer
> read my messages. This feels poor.
>
> In fact, in the delivery receipts introduction it states:
>
>> Note well that this specification does not distinguish between delivery and display, as was done in the message events protocol, in part because no implementations of XEP-0022 made that distinction. However, in the absence of such a distinction, readers need to understand that this protocol can provide only a notification that a message has been received at a client, i.e. delivered to a client, not that the message has been actively read or understood by a human user (if any).
> For this reason I think a separate XEP should be written, and the
> recommendation in this informational XEP (if any) would be to send
> delivery receipts on receipt of a message, not after decryption.
>
> Thoughts welcome.

All that is not specific to OTR. All encryption mechanisms are concerned
(GPG for example). Currently, one can send a GPG encrypted message with
a bad key, and never know something goes wrong because we receive
delivery receipts.

-- 
Yann


More information about the Standards mailing list