Send messages to multiple recipients, optionally introducing some of them to all the others

[burdges]

This pull supersedes https://github.com/agl/pond/pull/144 incorporating suggestions by @agl Check https://github.com/agl/pond/pull/144 for further earlier comments on the development.

Messages can be sent to multiple recipients. By default, recipients are not told other recipients exist, like BCC in email. Optionally, recipients may be marked as to "introduce", which tells other recipients about them and tells them about all the other recipients. In particular, an introduced recipient and any other recipients see a "greet" button which allows them to initiate a PANDA key exchange.

As noted in https://github.com/agl/pond/pull/144 introduction functionality creates a vector to socially engineer an MITM attack. We therefore provide three new records introducedBy, verifiedBy, and introducedTo to record your local social graph, as visible from messages containing introductions. In theory, these would help contacts discover such socially engineering attacks. Users may disable collecting these records.

Our short-term TODO list :

• Add sending to multiple recipients to the CLI and make introductions in the CLI use it. @rvedam
• Expose GTK's information dialog boxes in client/gtk.go @emptyset
• Make dialog boxes that explain anything that needs explaining, like the risks of keeping the social graph data, what to do if an introduction creates a second contact with a similar name, etc.
• Allow CLI users to disable collecting social graph information, like in the GUI
• Rename verifiedBy to reintroducedBy.
• Deal with introductions to revoked contacts appropriately
• Remove an introduction's PANDA secret after use prevent using it twice.

Our longer-term TODO list :

• A new outbox message is created for every recipient in this patch. Ideally, we should replace queuedMessage.to with toNormal and toIntroduce fields as well, but this requires allowing a message to live in both client.queue and client.outbox simultaneously. We can make this happen by using the same queuedMessage.id field and leaving the queuedMessage.message pointer nil in one of them, but it's another huge commit.
• An email style "reply all" function makes sense once we've done all that. We can "reply all" to messages containing introductions of course so https://github.com/burdges/pond/commit/cdc1bec458ff19ed88019f92bdf7ffc0c0b3da6e helps as well.
• Allow users to edit a contact's name when doing an introduction. Reply all should presumably preserve such names through a message thread, i.e. if I receive a message introducing @ioerror as ioerror who I already know as Jake then if I reply all I should reintroduce him as ioerror, not Jake. There is a slight downside here that if the original message was an MITM attempt that I didn't catch then I'd create an MITMed ioerror in addition to my real Jake, which I'd continue to propagate. And nobody else would notice "Hey Jeff always calls ioerror Jake".

[burdges]

Again I kept all protobuf rebuilds in separate commits, 4427d653 and 4a2bad1f for client/disk/disk.proto and 995a3eda for protos/pond.proto. It'll reduce the final diff by around 1200 lines if @agl adds another commit that rebuilds these with his protobuf version.

[bnagy]

For the record, I can't support this. It's needlessly leaking metadata and I can't see any upside whatsoever.

[ioerror]

On the idea of group messaging:

I like the idea of allowing sending to multiple people - I also like the idea of optionally introducing those people to each other. That is - I like the idea of BCC to a group - where group state is kept on my machine but not revealed. I also like the idea of CC to a group - where the group is flat and everyone knows everyone else, even if unauthorized. I also like the idea of a fully flat group where everyone may meet everyone else.

By default, I think groups should be BCC style groups - though I think that "regular" people want this to behave like email - so we should allow for an email style CC list - so we can use Pond to organize as well as to broadcast to groups.

@bnagy - could you enumerate each of the concerns that you have? I think that the nice part about the meta revealing is that it can be done entirely inside of messages - the social graph information can be leaked internally between peers (which is the human model, not made worse but made possible securely).

@agl - what do you think of these group style messages?

It seems to me that merely allowing for peer to peer communications is a good start - though short of Onion Routing style designs, I think, we'll want group messaging from one peer to many. That requires introductions and a local petname system.

I'm certainly open to understanding how we might accomplish these things another way. Right now I've been sending identical copies of messages to multiple people manually. That is painfully slow and also annoying. For example, when I want to send a file, I send it several times, which is not ideal at all.

[burdges]

People already do introductions in Pond because PANDA makes that an intuitive use case. And they're correct to do so since people screw up PGP, etc. Adding introductions as a feature therefore improves security by (a) doing the introductions as securely as possible, (b) increasing the rate of honest introductions helps expose social engineering attacks, and (c) providing a venue for better documenting pond op sec.

There was however one big question around "leaking less metadata" while doing introductions : We must deduplicate introductions with existing contacts because that's (a) intuitive and (b) helps detect social engineering attacks. So what data should be shared to deduplicate introductions with existing contacts? The public identity key and the original public key are the two obvious choices.

I selected the identity key for deduplication because :

First @agl proposed at 31c3 that introductions should eventually abandon PANDA for a manual-like key exchange, after the coming switch from group signatures to HMAC. Avoiding PANDA would obviously require sharing the identity key. Pond messages are more secure than PANDA exchanges so that's a net win.

Second Pond needs a notion of fingerprint that users tie to their real world identity by publishing it online. We cannot base the fingerprint on the identity key because identity keys are selectors in that an attacker could hack the pond server to collect message size and timing metadata. We'd also prefer that introductions not communicate this fingerprint because that protects a user who rejects an introduction from having their real world identity verified.

Is there a downside of deduplication using the identity key? Yes but it's highly theoretical. If Alice rejects Bob's introduction to Carol, and both Alice's pond server and Carol's pond client are owned by Eve, then Eve can collect message size and timing metadata on Alice. In this scenario, Eve looks remarkably talented because she already owned two very different machines, and possesses the math savvy to value timing metadata, so what exactly prevented Eve from owning Bob directly merely because Carol knows him? Alice is imho better off seeing the degree to which Pond inherently exposes her local social graph, maybe her situation demands a second Pond account or something.

[bnagy]

@ioerror I am completely fine with the idea of group messaging using BCC style groups. As far as I can see that requires no change to the core, it's all in the UI.

"Second Pond needs a notion of fingerprint that users tie to their real world identity by publishing it online. " This is the part I disagree with most violently. Pond needs the opposite of that. What is the point of building a system which promotes unlinkability by dropping all of the stupid web of trust mistakes made by PGP and then backlifting a half-baked web of trust onto it? If you want that kind of system GPG and email is already THERE and strawmanning about how it's "hard to use" isn't enough of a defence.

I'd agree that the onboarding is not completely ideal, and there are probably a few things about PANDA that could be looked at.

[grugq]

"Second Pond needs a notion of fingerprint that users tie to their real world identity by publishing it online"

Why? What COMSEC problem does it solve? Other than exposing people to additional risk, what benefit does this have? Linking identities to people is one of the serious problems with PGP.

@ioerror providing BCC functionality is certainly fine, and seems like a straightforward change to the UI/UX. I am not convinced on groups.

[burdges]

Introductions record exactly the information your client sees anyways. There is no "web of trust" in that records are never sent elsewhere. No metadata is "leaked" because users make a conscious choice to tell someone they know someone else.

We need a safe fingerprint that does not create risks when publish online, sent via email, etc. because users expect one. If no safe fingerprint exists then some users will publish unsafe values, like their public identity key, which makes the server a target. I'll submit a separate pull for that.

[grugq]

I’m not seeing what the benefit of publishing a fingerprint is. Either the key exchange works, and you are speaking to the correct person, or it fails and you aren’t speaking to anyone. Where is there a need to verify a fingerprint?

A strong point in favor of Pond mailboxes is that they are anonymous. Having a fingerprint that you publish makes them as dangerous as using PGP. For examples of how bad this is, see Tom Ritter’s talk “Deanonymizing alt.anonymous.messages”:

video: www.youtube.com/watch?v=l5JBMyxvuH8

slides: https://www.defcon.org/images/defcon-21/dc-21-presentations/Ritter/DEFCON-21-Ritter-De-Anonymizing-Alt.Anonymous-Messages-Updated.pdf

Adding features that make Pond more dangerous to use strikes me as a bad idea. If people want to play with dangerous communications systems they can use PGP + email. =

[bnagy]

What I'm seeing here is a fundamental disconnect. Pond, used correctly as part of an overall comsec regime provides benefits which are not available in any other tool, and it goes as far as it possibly can to stop users from cutting themselves. The changes you propose make it easier for users to cut themselves.

Specifially:

• Organisations that want strong security should be avoiding group communications anyway
• transitive trust ( introductions and the like ) is the leading source of penetration
• Linking identities to people is a huge future risk, and it's not just the crypto. At some point someone will flip or be compromised, so the fact that this information is 'crypto protected' is worthless
• You're NOT just talking about information the client sees already because right now the only way to send a group message is via ersatz-BCC, which leaks no information about others the message may have been sent to. You're EXPLICITLY proposing adding new metadata leaks,

For onboarding Pond already provides two strong methods. PANDA with a strong shared secret ( the window in time of possible compromise is vanishingly small ) and manual KEX using the PEM blocks over a bootstrap channel like a verified IM session or GPG email. These are IMHO more than sufficient for genuine operational needs. Submitting changes to make those more usable is great, but changing the fundamental and carefully designed properties of the system is not.

Finally, who is this "we" business, Kemosabe? Which user base are you claiming to represent here and what is your threat model?

I get that you want to write code, but it seems like there's not enough research / thought being invested into fundamental properties of how secure communication supports real requirements.

[burdges]

I should look into how this interacts with detachments at some point.