[messaging] Security arguments for read receipts

[Ximin Luo]

I hear that OpenWhisperSystems don't want to implement "read receipts" because
they consider this to be a security issue, and have closed several user tickets
requesting this feature as "wont fix". I don't think it's a security issue, at
least not in a significant sense, and in fact I think *not* having read
receipts is a worse security issue.

Firsty, let's clear up some definitions:

Delivery receipt
  A notice by the transport layer that they delivered the message. Since it's
  by the transport layer, there's no security value in such things. TextSecure
  have implemented these, leading to user surprises such as #3245, #3528 [1].
  But the transport could lie, and the fact that TextSecure markets such weight
  in security in *other* aspects of itself, might lead users to falsely believe
  that delivery receipts have higher security levels than "trust the server".

Read receipt
  A notice by the actual reader (or a trusted delegate, such as another person
  at your house, or a program acting on behalf of you) that they read message.
  This *can* be done with end-to-end authenticated levels of security.

Implicit manual ack
  If your reader manually replies, in a new message, to acknowledge "I got
  this" (or the equivalent) and refers to your previous message(s), this can be
  implicitly interpreted to mean an end-to-end secure read receipt.

Explicit automatic ack
  End-to-end secure version of what is commonly called "read receipt" - an
  automatic reply from the reader that they got your message. On computer
  systems, the automation can be done by a program. Note that this doesn't have
  to happen immediately, and could happen after a random timeout.

For the rest of this post, I'll use "auto-ack" in place of "read receipt",
carrying the same end-to-end authenticated guarantee as normal messages.

[1] I guess because the transport doesn't know about the client-side blocking.
    But this furthur indicates just how worthless delivery receipts are.

Benefits of auto-acks:

1. As the author, your messaging program automatically verifies that the
   message was delivered successfully (reliability).

2. As a reader, your messaging program automatically verifies that other
   readers also saw the messages (consistency).

Specifically, you defend against (certain classes of) transport-level drop
attacks and all attacks that depend on these, such as consistency attacks.

Benefits of no auto-acks:

1. (reasonable argument) To avoid some notion of "creep factor" which some
   people think is important. You don't want an author to know that you've
   already received the message, because it would be socially awkward to not
   reply quickly, or something like that. You want to be in control of when the
   author gains that knowledge.

2. (fallacious argument) You leak timing information to an outside attacker,
   that might then use this information to deanonymise members of the group.

3. (fallacious argument) Normal postal conversations don't have read receipts,
   so we shouldn't do this either. (Analogous to deniability argument in OTR.)

Counterarguments:

1. a) For cases where people message you unexpectedly (e.g. strangers), this
   has high significance. However, the opposite scenario, where you're having a
   friendly co-operative conversation, is also common:

   - As the author, you can't be sure whether your readers received your
     message, unless they manually reply to do so. As the reader, this is such
     a common thing to do, the messaging layer should do it automatically,
     instead of expecting you to manually play these verification games.

   b) What is the majority use-case here? Actually that's a weak argument, we
   also want to protect minorities, if they are significant. I assert that read
   receipts are wanted by a significant portion of users - I want them, many
   messaging apps have it, and tickets have been filed against TS for them. Why
   not implement *both options* to allow users to choose, *based on their
   security needs*? E.g.: "Switch off/on automatic read receipts for this
   contact", default OFF for contacts who send you a message whom you've never
   talked to before, default ON for contacts that you talk to regularly.

   c) *Automatic* acks inherently carry less creep factor, your program does it
   automatically so it is perfectly reasonable to argue to the people socially
   judging you that you didn't actually read the message yet.

   d) For security purposes, one should *at least* warn authors after a timeout
   that "maybe your message wasn't actually delivered", if the program don't
   receive an ack (manual or automatic) within a given timeout. Of course, this
   won't fit OWS' standards of usability because the warning would *happen so
   often*. But this indicates that their position is flawed - just because you
   refuse to add a security warning, **doesn't mean there is no problem** -
   you've just brushed it under the carpet.
   
   e) Any user studies done without considering (d) are **fallacious** - you
   haven't communicated to the user that the opposite scenario carries security
   problems, i.e. the potential that their message was not delivered, so their
   supposed trade-off is **based upon incorrect information**. Of *course* you
   can pass user studies by not giving them all the relevant information - that
   is what insecure software has done to users for decades!!!

   f) What are the actual threat models here? With authenticity, you want to
   bring up your peer's belief in some fact to 100% - epsilon; with
   confidentiality you want to bring your attacker's belief as low as possible,
   hopefully (number of possibilities)^(-1). With auto-acks, you achieve
   authenticated reliability and consistency, i.e. close to full confidence,
   and transport-level drop attacks are *always a concern*. With no auto-acks,
   you achieve what? For an author (your attacker) that sent you a message,
   instead of having 100% confidence that you read it, they begin at 50% or
   whatever the base rate is, tending towards 80-90% as time passes? *Oooh
   great defense there(!)* And that's *only* if I even care to not give this
   information away in the first place.

2. If the reader had manually replied "I got this message", you would *also*
   leak timing information to an attacker. A good timing-defence-system must
   protect against this, and therefore it should be possible to do auto-acks
   (perhaps with a random timeout) to fall within this protection.

3. This argument holds for OTR due to other specifics; it is *not* a general
   principle that we want to emulate real world conversations all the time.

   For example, Tor does not emulate any real world conversation, though one
   *could* run it on the postal service, if one was very disciplined about it,
   and had the appropriate automation technologies. Similarly, one *could*
   implement automatic acks on the postal service, if one had similar low-cost
   technology. I often worry about whether my peer received my physical letter,
   and actually such technology would be pretty nice, as would Tor-over-post.

   Non-repudiability is indeed specifically wanted in some cases. But this is
   such a small minority of use cases of OTR, that it's reasonable to say "just
   sign your messages using some other program". If it was wanted more, it
   would be responsible to add this option to the protocol.

   OTOH, read receipts are wanted in a much greater proportion of cases. Yes,
   they are relevant in asynchronous messaging. In practise, I definitely worry
   that my emails haven't been received, more than I worry about being judged
   at not replying quickly enough. Yes, a user study about this would be nice.
   But please don't make fallacies like 1(e) in those studies.

Another proposal:

The UI could let readers specifically manually ack a message (or multiple at
once), and warn *them* if they don't do this after a timeout - the same timeout
as the "message maybe not delivered" warning on the author's side, that OWS
probably won't implement. The reader-side warning could read "Your peer isn't
sure if you've received the message, don't leave them hanging!" or something
like that. When the author receives the ack, instead of displaying it as a
whole new message (like how manual "I got this" acks would be displayed), just
mark a tick next to the appropriate acked messages.

Or just allow automatic acks, and not bother the user with this trivia.

I can also understand if OWS doesn't want to do this for engineering cost
reasons. It is entirely appropriate to get priorities straight, and fixing this
issue is less important than making sure the existing system has no bugs, or
whatever else is on the "priority" list. However, it is a disservice to users
to try to convince them that this feature is harmful to their security. At
least, excuse my potential ignorance, I haven't seen any acknowledgement from
OWS that read receipts *do* benefit some important security considerations, as
described at the beginning of this post, that in the rest of this post I've
argued is more important than the "socially awkward" security concern.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151103/19fe302f/attachment.sig>