[messaging] Secure universal message addressing

[Natanael]

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;

http://www.metzdowd.com/pipermail/cryptography/
http://lists.randombit.net/pipermail/cryptography/
http://www.ietf.org/mail-archive/web/endymail/current/maillist.html
https://moderncrypto.org/mail-archive/messaging/2014/thread.html

#####

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
(https://webfinger.net/), 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 i2p.to 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160404/14a9d6a2/attachment.html>