I'm crossposting this to a few lists, a few of the relevant mail archives are here for those who want to follow the replies on the other lists; <a href="http://www.metzdowd.com/pipermail/cryptography/">http://www.metzdowd.com/pipermail/cryptography/</a> <a href="http://lists.randombit.net/pipermail/cryptography/">http://lists.randombit.net/pipermail/cryptography/</a> <a href="http://www.ietf.org/mail-archive/web/endymail/current/maillist.html">http://www.ietf.org/mail-archive/web/endymail/current/maillist.html</a> <a href="https://moderncrypto.org/mail-archive/messaging/2014/thread.html">https://moderncrypto.org/mail-archive/messaging/2014/thread.html</a> ##### After spending way too much time thinking about how to design a secure universal message passing platform that would work for both IM, email, push messages and much more, I just ended up with a more complex version of XMPP that won't really ever have lower latency, be scalable or be simpler to operate or even be secure at all. So I dropped that idea. Then I ended up thinking about addressing instead. If building one single universal communication protocol is too hard, why couldn't it still be simple to have one single universal protocol for identifying recipients / users? It would allow each user to have one single unique global identifier which can be used to find out which communication protocols each other user supports and how to connect to them. Email address type identifiers are already familiar and won't go away. We are practically already heading this way with email too; Given that we have the combo of protocols like DMARC, DKIM, SPF, TLS, DNSSEC+DANE and of course the very relevant WebFinger for user profile data (<a href="https://webfinger.net/">https://webfinger.net/</a>), and that we have companies like Google, Yahoo and Microsoft working on SMTP STS, we are already building much of the infrastructure necessary for secure addressing. Every server / node would continously check which one's the strongest protocol supported by each other server / node they've communicated with recently, refusing to connect over weaker protocols. # Add in transparency logs (perhaps Keybase style) and you've got very strong security for the users. Stopping downgrade attacks suddenly becomes more than plausible when there are reliable ways to detect if a server truly supports secure protocols or not, and MITM becomes hard to hide if the sending client / server / node always logs the recipient's server's responses (making forged replies trivially provable, hurting the server's reputation in seconds by publishing the conflicting log entries). A Perspectives / SSL observatory model would also drastically improve the detection rate for tampering. # That setup just lacks one capability which I consider major - playing well with P2P networks lacking classical domain names. Not all users will be using (fixed) servers (or even IPv4/6 addresses), so perhaps the domain part of email type addresses could be a domain name format that specifies that it identifies a P2P node and its protocol (like a Namecoin profile or an I2P node holding your profile data, or a CJDNS node). Including public key identifiers in the addresses would most likely be necessary, unless you're dealing with protocols like Namecoin for fetching profile data. Those who wants to place their own P2P nodes in the domain field could do that, having that node carry the profile data which explains how to connect to you (which would of course require that those you communicate with can connect to your P2P node), instead of using a third party server. Most people probably won't opt for this, but it should be possible. Where the users or (end user trusted) servers are identified by public keys in the addresses, it could be possible to have public translating proxies for P2P protocols (kind of like <a href="http://i2p.to">i2p.to</a> and the Tor equivalent, "inproxies") without any loss of security. # The user experience would end up looking like Keybase.io, but with their account ownership proof process looking more like the OAuth process (usually initiated via the third party service/client by entering your email to register after logging in), where most likely it would be your existing email provider offering this addressing service. Every messaging system you add would be linked to your account, both server based ones and P2P ones (with their respective unique user identifiers), allowing anybody who want to message you securely to detect that you support protocols with better security than the arcane SMTP. If both sides supports this protocol and a hypothetical email2 protocol that's tagged as an upgrade over SMTP, no mail between you would ever be sent over SMTP. As more email servers upgrade they would quickly start to detect that the rest of them also supports stronger security, and upgrade the security for all the users silently. It would behave like account addressing within Google's suite of protocols such as email + IM via Hangouts + Google Cloud Messaging + Google Docs, etc, where the same email address is the account identifier for them all, except that this would be an open universal protocol. The recipient of a message from a third party service you started using wouldn't be getting an invite email (invite emails are getting boring, aren't they?) telling them to register to see the message - instead that service would see which compatible service the friend is using and connect to it, and pass it on. # We need secure push messaging, IM, mail and much more, and if we can tap into the existing infrastructure through email and make the user experience both easier AND more secure, we are much more likely to see secure versions of all these protocols implemented. If connecting secure protocols to your account is easy and transparent for everybody involved, there would be much less resistance towards changing clients. Another big benefit is that contact management will be much easier (most likely also hosted via your mail provider like it usually is today, except now it would make sense to have a single one shared across all your services), because suddenly you no longer need to be given every single username for every service a person uses separately. Opening the contact details for a person would simply show you which protocols you both already support, and which additional ones they support that you don't. You only need one single username / address per person, and even if they were using a server addressed profile (like standard email addresses) and switch servers, they could set a redirect to the new address that notifies you about the change the moment you tried to contact them again. It would be completely effortless. # Here's the existing systems I know of which comes close, with comments; * The mix of email security protocols I mentioned above. There's no clear standard for how to achieve this with them. One could build on WebFinger, but how should it look like? * Namecoin. A public P2P blockchain system, not universal. Requires a full node or connecting to a trusted third party node for lookups. * Keybase.io. Not designed for addressing, URL identifiers. * PHB's Mathematical Mesh (under development). It uses a private blockchain per user for something resembling transparency logs, and uses identifying public keys (IIRC), but I haven't read up on the details on how it works. I don't know if it works with email address based identifiers. The key idea here is that you get to have *one* identifier for yourself under your control, that you can use everywhere, securely. Knowing that people have your real address should provide a strong guarantee that messages from them to you will go only to you. And you shouldn't need to change address because you changed messaging services. How would you guys go about designing a system like what I describe? How would you get it to play nice with P2P nodes?