[messaging] Security arguments for read receipts

[Natanael]

On Tue, Nov 3, 2015 at 3:09 PM, Ximin Luo <infinity0 at pwned.gg> wrote:

> Hi Nataneal,
>
> It sounds like you have a specific proposal in mind, for a system that has
> auto-acks. It would be good if you wrote this up in a separate document.
>

Like I noted, I will. I've got blog post drafts for it now. Still thinking
it through.

>
> My post was about why auto-acks are desireable in the first place. I
> specifically tried to ignore how one might implement this, because that is
> not relevant for user-level security arguments. (Even in a concrete
> proposal, it's good to separate out the *justification* from the
> implementation.) For example, I'm not seeing how parts of what you wrote,
> match up in reply to what I wrote.
>

Some of the seemingly not related comments of mine were included because it
is part of what I've been thinking of before, which *partly overlaps* what
you asked for. So I just included it all in an attempt to explain my
thoughts.


> One comment I'd like to make is regarding this:
>
> > users should be able to request acks for specific messages and flag
> > for when ordering (consistency) matters and needs to be confirmed by
> > the recipients.
>
> Giving this much choice to the user I think is unnecessary complexity.
> What security benefit does it give, to justify that? In my previous post I
> suggested a per-conversation setting. In which real cases do you actually
> need more fine-grained control than that?
>

This example has been given before:

View 1;
Alice: Want to join us?
Bob: Yes
Mallory: And blow up building X?

View 2;
Alice: Want to join us?
Mallory: And blow up building X?
Bob: Yes

Extreme? Sure. But it highlights how ordering can change semantics.
Sometimes you need to be able to declare that somebody else needs to check
out View 1 before making any conclusions. When it matters, you highlight
the relevant messages and chose who to notify about your view of the
ordering.


> Other parts of your post mention things like ordering, as well as
> different models of communication. But I'm missing the background of what
> you're referring to - what ordering assumptions, what models you have in
> mind - so it's hard for me to concretely understand what you wrote. Also
> note that Git is a history of *state*, not diffs. Authentication is done
> over *state* (including history), and the diffs are calculated implicitly
> after you verify all of this.
>

I'm still thinking it through. But in short, there would be a history of
edits. I think Google Wave used XML documents where every change *was* a
diff modifying one part of the document. Chaining them together creates a
tree of edits. Signing diffs with hash trees shows who made what edit based
on what document state.

Basically everybody have one view of their own messages, which can be
considered authorative for them. So everybody maintain personal hash chains
for their messages (no need for having them be permanent and complete, you
can have a "rolling chain" and drop old state if you keep checkpoints).

Everybody also maintain a hash chain that records in what order they saw
messages from others - above Bob saw the message from Alice, then sent his
message, and then saw the message from Mallory. But Mallory is better
connected in the network (fiber vs GPRS), so most people saw Mallory's
reply before Bob's, so they got to see view 2. (As a consequence Bob then
choses to highlight his message order to the group, so they can see that
Mallory's message NOT was part of what he replied to.)

People have different expectations of persistence of what they write. Some
expect their words to be ephemeral, some expect them to be eternal and
provable. By showing them which mode of communication / channel (document
edits vs annotations vs IM) that better match what they want (they don't
need to have that joke signed, but want their document edits be provable),
we can avoid many simple mistakes. You don't want to be held accountable
for some dumb comment made at your last job. You WANT to be attributed for
your work on your collaborative school project.

Let them know the document stays, that the IM is ephemeral and meant to be
"live", for basic coordination of thoughts and quick questions, and other
mostly irrelevant crap, and that annotations are for stuff you want to
store but *not inside the document*. Explanations, references, comments
taken from IM that you want to remember.

Like the difference between speaking at the coffee machine vs on a stage,
in front of a camera vs in a unrecorded meeting. The context of the
communication determines what you say and how, and because you might want
to say things not appropriate for the current context then you want the
ability to switch between different applicable contexts.


> I'd be interested in reading your blog post when you get around to it. But
> beware that that type of medium tends to get out-of-date pretty quickly;
> I'd suggest something like a github documentation repo.


I'm not sure GitHub is relevant yet. So far I've got nothing but some ideas
and sketches. And I don't have the programming skills to create it all
myself, beyond maybe some very very basic prototype. Right now I'm mostly
just hoping my ideas will turn out to be helpful for somebody who *do* have
the skills to make something that works (or that I won't have forgotten
everything by the time I've accumulated the skills necessary to build it
myself).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151103/b801744e/attachment.html>