[messaging] Reduce identity key exposure in Pond

[Trevor Perrin]

On Thu, Apr 2, 2015 at 5:28 PM, Joseph Bonneau <jbonneau at cs.stanford.edu> wrote:
> Coming to this thread a little late, I would try to summarize this as an
> attempt to separate two types of keys:
>
> *Message keys, for which we might like for Bob and Charlie to be able to
> link Alice's message keys to be sure they're talking to the same party (or
> compare against, say, a CONIKS server somewhere).
> *"Identity keys" (not a great name) which are used for routing to a specific
> mailbox.

Agreed we're discussing the relationship between:
 (1) the public keys used by parties to authenticate each other
 (2) the delivery identifiers used to inform recipient servers which
recipient you're delivering a message to

In Pond I think there's a 1-to-1 relationship.  Jeff was suggesting
keeping this but encrypting the delivery identifier to the recipient
server's public key as part of the "delivery tokens" Alice gives to
her correspondents.

I didn't think that accomplished much, since:
 - Communications between Alice's correspondents and Alice's server
will have transport encryption anyways
 - Alice's server needs to receive the identifier either way
 - Alice's correspondents will still be able to recognize they are
talking to the same party due to the "linkable" public key (1)


> We'd like Bob and Charlie (or Bob today and Bob tomorrow) to be
> able to easily set up to route to different mailboxes for Alice, using the
> same message keys for encryption (or keys ratcheted forward from them). That
> way the server can't easily link all of Alice's traffic.
>
> Currently the two are intertwined in Pond and the suggestion of "just have
> multiple Pond identities" is a little unsatisfactory. What if I'd like to
> break up traffic analysis the server can do (or even use multiple servers)
> while keeping a consistent Message key for my correspondents?
>
> Is that the problem that we're trying to solve? If so, I think there are
> some pretty straightforward ways to do this by allowing Alice to have
> multiple mailboxes with the same key

You're suggesting relaxing the 1-to-1 relationship so that Alice could
use her same public key but have different delivery identifiers on
different servers.

I see that as potentially a convenience (Alice could change providers
without triggering TOFU warnings).  But I don't see it as an important
security property: the situation where Alice is OK that her
correspondents can recognize the shared identity but doesn't want her
servers to recognize it seems contrived.

I think a useful notion of unlinkable identities needs to be more
thorough, e.g. either
 - no linkable identifiers, every connection with a correspondent uses
unrelated keys
 - identifiers are linkable, users have to manage separate accounts if
they want separate identities (Pond)


Trevor