DIME project

[SafwatHalaby]

This is not a technical issue, I apologize for posting it as one, it is the only way I can transmit a message to the Pond guys.

It seems someone is working on a really similar project, perhaps merging the two projects or making them collaborate makes sense?

I don't have any technical knowledge of either Pond or DIME, and I don't know if merging is feasible, advantageous, or even possible. I will leave this for you to decide.

Info about DIME:
https://darkmail.info/

https://github.com/lavabit/libdime/

http://arstechnica.com/security/2015/01/lavabit-founder-wants-to-make-dark-e-mail-secure-by-default/

This was cross posted at lavabit/libdime#14

[agl]

Thanks. I know that I need to read the DarkMail spec at some point, although I think that the goals of the projects are sufficiently different that merging is unlikely.

[SafwatHalaby]

Alright.
Regarding the goal: Could you elaborate? From a bystander like me, the goal seems identical.

[burdges]

Pond protects more seriously against traffic analysis and does not let users void those protections. Dark Mail is full of compromises that address interoperability with email, commercial use cases, etc.

Dark Mail does improve upon encrypted email by protecting all message content, including the subject line, but their metadata projection in the DMTP (ch. 7) are (a) optional, meaning hapless users will frequently expose themselves, and (b) nowhere near as strong as pond's protections. In particular, DMTP does not protect message size, timing, etc.

As an exercise, there is no way to build a pond-to-email gateway because allowing replies makes a pond user's identity key into a "selector" in the sense of the NSA's surveillance apparatus, i.e. some machine outside the user's control connects that identity key with an email address.

[LBiv]

I would like to defend our spec, by saying that encrypting the message header is NOT optional, but a core component of DIME. A portion of this meta data, however, can be decrypted by the origin and destination servers in order to facilitate the routing of the message, so an attacker COULD recover the identities of the sender and receiver by compromising the domains of their service providers. The subject line, however, stays encrypted end to end.

[sycamoreone]

[..] so an attacker COULD recover the identities of the sender and receiver by compromising the domains of their service providers.

One point where Pond is "sufficiently different" would be that the protocol is also trying to protect users from their own service providers. Even your home server can learn who you are exchanging messages with. (Cf. https://pond.imperialviolet.org/threat.html)

[burdges]

I must've miss-read comments about using non-DMTP transport protocols like SMTP, and maybe stuff about email compatibility then, apologies.

As an aside, young people adapt their behavior to the search functionality the different social networks choose to expose : http://tech.slashdot.org/story/15/01/10/1920228/back-to-the-social-media-future Imho, we should build encrypted communications tools that expose their maximal level of information collection to the user, thereby communicating the user's exposure in an intuitive way.

In DIME's case, one should eventually build tools that run on mail servers help users profit from the traffic information DIME exposes to the server, thus providing a service to the users, and demonstrating to them what DIME servers know about their communications. A contact recommendation engine, perhaps?

In Pond's case, there is no "selector" through which you can ever search for a contact, which hopefully communicates that other systems expose social graph information. Also, I'll soon resubmit #144 which allows contacts to introduce their contacts to one another, optionally recording your local social graph as visible from introductions. We exposing that social graph information to help expose MITM attacks accomplished through social engineering, but obviously it reminds users of their exposure too.