Send messages to multiple recipients, optionally introducing some of them to all the others #161
Conversation
…protobuf. Avoids screwing around with directories or editing files now. Find gogoprotobuf at https://code.google.com/p/gogoprotobuf/
…eful for various planned features, including contat invitations, messages with multiple recipants, and editable notes fields for contacts. In fact, I considered moving inputTextBlock to cli-inout.go, but it wouldn't save many imports in cli.go to do so.
Rebased so newKeyExchange now outside beginPandaKeyExchange
These create and parse the pond-introduce-panda urls Rebased so newKeyExchange now outside beginPandaKeyExchange Also rebased to use a counter rather than a random character, but maybe it's worth abstracting the cliId code for this.
…because we save their proposed identity there.
Rebased with newKeyExchange now outside beginPandaKeyExchange
Joint effort between Jeff Burdges <[email protected]>, Alan Fay <[email protected]>, and Ramnarayan Vedam <[email protected]>
Aka the Dark Web of Trust data
Simplifies creating messages to specific recipients and makes the code more readable.
We replace the to uint64 field in the Draft struct in client.go with two fields of type []uint64 called toNormal and toIntroduce. We clean up these fields when a contact is deleted in client.go as well. Introduction messages get their size approximated in usageString() as well. We modify sendDraft in netwrok.go to send the messages to every user id listed in either toNormal and toIntroduce. All contacts listed in toIntroduce are introduced to all contacts listed in either toNormal or toIntroduce in the sent messages. We make extensive changes to composeUI in gui.go for composing drafts to multiple recipients, optionally introducing some by listing them in toIntroduce instead of toNormal. We display multiple names on the ride hand sidebar whenever possible too. We modify cli.go to correcttly report information about drafts with multiple recipients. We have however deffered adding the ability to edit drafts tor multiple recipients until afer the functionality has been debugged more thuroughly. We leave the introduction functionality in both gui.go and cli.go in tact, but eventually this should be phased into the compose interfaces, which includes editing drafts with no recipients in cli.go. We modify disk.go to support the new Draft struct without changing the existing protobuf, meaning drafts currently lose information about their multiple recipientsr when saved. We address this in a subsequent patch, but seperating any changes to protobufs seems desirable.
There was an inconsistency in what Draft.inReplyTo meant between the GUI and CLI, a minor bug for people who used both the CLI and GUI, which led me to break testReplyACKs when adding more homogenious code.
Adds an information button to explain how introductions work to composeUI too.
We allow users to disable collecting the social graph data for a specific contact. If *all* contacts have collecting social graph data disabled then any new contacts begin with collecting social graph data disabled as well. We now avoid calling fixProposedContactName in parsePandaURLsText on existing contacts too.
In particular, we never create the to-box-add combobox if no valid contacts exist now, while our old to combobox was created empty, so TestSendToPendingContact cannot check the ok value anymore.
We removed the rough estimation in Draft.usageString(), replacing it with client.usageString(Draft). Ideally, we should avoid marshalling the entire message including attachments with every keypress, but hey.
Rough test for introductions and necessarily multirecipient message, maybe should test more, like message contents.
We fix a bug where fixProposedContactName didn't actually rename the ProposedContact too. Ideally we should use a fuzzy test for name similarity, maybe based on n-grams or maybe a fast fuzzy spelling suggestion algorithm : https://github.com/sajari/fuzzy or even JaroWinkler or Levenshtein from "github.com/antzucaro/matchr".
Repalce the pond-introduce-panda://NAME/SECRET/IDENTITY/ URI format with the opaque URI format pond-introduce:NAME?pandaSecret=SECRET&identity=IDENTITY
We need NewSimpleMeetingPlace to avoid hitting the PANDA server when testing, but an intermitent race condition is created here. I disabled the two calls to clients[1].ReloadWithMeetingPlace(mp) in TestIntroductions because they break the client.gui.events channel preventing the uiStatePANDAComplete message from arriving. Appears ReloadWithMeetingPlace helps TestPANDA avoid a data race, but the issue haasn't arisen for me. If we ReloadWithMeetingPlace then doGreet should be split into two seperate functions to actually press greet and create the goroutine to wait for it. I suspect however that launching the listening goroutine before doing the greet on the other side avoids this data race better.
We handled introduction in the message protobuf itself, creating with type pond.Message_Introduction. We retain the ability to build greets based upon introductions that arrive as opaque URIs because that might prove useful for compatibility with older clients.
We probably won't use this code for a human readable introduction trick because InboxMessage keeps the raw pond.Message marshaled, Imho it's worth disabling or removing it in a seperate commit though.
|
For the record, I can't support this. It's needlessly leaking metadata and I can't see any upside whatsoever. |
|
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. |
|
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. |
|
@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. " I'd agree that the onboarding is not completely ideal, and there are probably a few things about PANDA that could be looked at. |
|
"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. |
|
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. |
VerifiedBy was a poor choice for many reasons, including the fact that introductions are not a web of trust.
|
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: 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. = |
|
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:
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. |
Add support for multiple contacts with the same identity key. Allow greets to contacts who revoked us too.
We've always had protoVersion==1 so Contact.supportedVersion==0 means we've never recieved any messages and do not know their client vesion.
|
I should look into how this interacts with detachments at some point. |
This pull supersedes #144 incorporating suggestions by @agl Check #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 #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 :
Rename verifiedBy to reintroducedBy.Our longer-term TODO list :