[messaging] Security arguments for read receipts

[Jeff Burdges]

On Tue, 2015-11-03 at 17:00 +0100, Ximin Luo wrote:
> > There are a bunch of reasons for using a limited pool of tokens to
> > authenticate delivery.  I'd imagine such systems might be slow to
> retry
> > dropped messages to avoid waisting the tokens, and they'd likely
> burn
> > several tokens before complaining that the message dropped, so
> you've
> > potentially hours of delay before the system colors your message as
> > dropped.
> 
> Not sure why you need a limited pool of tokens to authenticate
> delivery?


There are not many systems that satisfy both M0/M1 and R0 from :
	
http://www.lothar.com/blog/53-petmail-delivery/
All that I know fit into two categories :


Category 1.  Group signature schemes require pairing-based cryptography

As I understand it, friendly pairings inherently make elliptic curves
far weaker cryptographically, making the curves into big slow
monstrosities.  And thus DoS vector. 

Pond's BBS scheme gives S1 M0 R0 Rev1, btw.  And the VLR scheme would
give S1 M0 R0 Rev0.


Category 2.  Limited pool of delivery tokens.

As discussed here, these scheme usually achieve S0 M1 R0 Rev0 with
rather token sizes around 64 bytes.  If implemented using single-use
reply blocks in a mixnet then we get S0 M0 R0 Rev0 :) but then token
consume more like 256 bytes and they expire relatively quickly.

There is another sort of DoS attack on token schemes in which an
attacker tries to deprive a sender of tokens, or limit a recipients
ability to distribute tokens.  At present, anyone I've seen really
discuss the problem seems to believe this can be handled in a way
that's preferable to group signatures.   It's more your typical sort of
engineering obstetrical as opposed to fears about exotic cryptography. 
 I vaguely recall seeing at least one token supporter complain about
single-use reply blocks, but not sure the context. 


Just fyi, I'm currently in favor of single-use reply blocks as delivery
tokens in the sense that I'm trying to figure out if I know how to make
them viable.  :) 

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151103/0775f11d/attachment.sig>