[messaging] Security arguments for read receipts
infinity0 at pwned.gg
Tue Nov 3 03:08:34 PST 2015
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:
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 .
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".
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.
 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.)
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.
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...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Messaging