[messaging] pond alike lists (was: Re: pond alike group messaging)

[azul]

Jeff Burdges:
> On Tue, 2015-06-16 at 16:32 +0000, azul wrote:
>> At a first glance it looks like the distribution mechanism of pond could
>> be generalized to a set of recipients. 
> 
> It depends what you mean.  In Pond, messages are immediately deleted
> from the server when the user downloads them.  In principle, this
> prevents the server from being able to compile statistics about past
> usage of specific mailboxes, which helps protect it from seizure.
I imagine keeping messages on the server for a reasonable time. I think
pond keeps them on the client for two weeks by default. So seizing the
server would reveal the encrypted messages for the last two weeks. I
would be okay with that - maybe there's ways to optimize so the server
knows if all messages have been fetched and can remove them more early.

>> Fetching messages from the server
>> currently requires authenticating to the server with one specific key.
>> This could be extended to multiple recipients with a group
>> authentication scheme similar to the one that pond originally used for
>> authenticating senders. 
> 
> It's doable, but it's harder than it first appears.  We've discussed
> such things before, especially for multiple devices.  I'm unsure if
> you'd want the BBS scheme used in Pond or a newer scheme allowing
> partial revocation.
I was thinking this is similar to multi device scenarios. I have
searched the list archives but i have not found such a discussion - but
maybe i just missed it. Is it archived somewhere?

> Adam is replacing the BBS scheme in Pond with a simpler token based
> system discussed previously on this list because doing the revocations
> has created practical problems.  
Yes. So BBS might not be the best choice. I will look into what the
problems were. I'm not sure if token based scheme is applicable. I guess
every message would have to contain the token for fetching the next message.

>> The server could get some information about which connections come from
>> the same user by observing the messages requested. 
> 
> Yes, clients must request their own messages back from the server.  
> 
> Also, the server can count the number of participants, unless the
> clients rate limit themselves, which makes big lists unusable.
I'm looking at rate limits similar to those pond uses. That would still
allow for receiving a lot of messages per day.


>> There seems to be a rough consensus that pair wise encryption is the way
>> to go for group messaging. However this comes with the condition that
>> participants in a conversation know all other participants keys. In our
>> usecase this may not be easy to achieve.
> 
> Why not?  Just introduce them!  I've a pull request doing this in Pond
> actually : https://github.com/agl/pond/pull/161
Thanks for the link. The discussion is really interesting. However I
think we are looking at different use cases. I'm looking in the
direction of mailing lists while your pull request sounds more like CC
and BCC mails. I tried to clearify in the subject now.

So my main worry with pair wise pond is sending the message to all the
different recipients. Say you have a list with 100 users and send a
message every 6 minutes on average. So it would take 10 hours for it to
get distributed.

Using pair wise crypto and a common server might be an option though.

> If otoh you're worried about participant anonymity then simply do the
> pairwise key exchange with new anonymous long term private keys.
That sounds feasible. I'm currently not planning to integrate this with
pond - so it would be a matter of not reusing keys between lists. It
would be nice to reuse parts of the crypto and have indistinguishable
messages on the wire though.

>> An interesting option to me seems to be using a proxy reencryption
>> scheme like SELS[1] that reencrypts the messages for a given recipient
>> on the server without leaking the plaintext. 
> 
> Am I correct that SELS lacks any forward secrecy, yes?  Forward secrecy
> is essential, so that rules out SELS.
I would love forward secrecy. But frankly... on a list with 100
participants message content secrecy is limited. I would like to see
what can be achieved in such a scenario especially regarding metadata.
So even if it was not forward secret it would still be an improvement
over what we currently have.

>> Are there any that also provide perfect forward secrecy?
> 
> Afaik there is no good group ratchet scheme, like Axolotl or even OtR,
> to provide forward secrecy for a group.  
Thanks for the list of approaches. I will take a look at them.

> We should imho focus on using pairwise encryption whenever remotely
> viable.
I will also think about pairwise encryption with a common server used by
all recipients.


Azul

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