Subject: [Endymail] Secure universal message addressing

From: Natanael <[email-masked]>
Date: Mon, 4 Apr 2016 16:55:58 +0200

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?

---

From: Sean Leonard <[email-masked]>
Date: Mon, 4 Apr 2016 14:23:52 -0300

I think it’s called a URI.

Any “universal” address is going to have to have embedded info about the protocol or system that it is addressing. See URI.

Sean

> On Apr 4, 2016, at 11:55 AM, Natanael <[email-masked]> wrote:
> 
> 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://www.metzdowd.com/pipermail/cryptography/>
> http://lists.randombit.net/pipermail/cryptography/ <http://lists.randombit.net/pipermail/cryptography/>
> http://www.ietf.org/mail-archive/web/endymail/current/maillist.html <http://www.ietf.org/mail-archive/web/endymail/current/maillist.html>
> https://moderncrypto.org/mail-archive/messaging/2014/thread.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/ <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 <http://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.
> 
> #
> 
> * 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. 
> * 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?
> 
> _______________________________________________
> Endymail mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/endymail

---

From: Natanael <[email-masked]>
Date: Mon, 4 Apr 2016 20:11:15 +0200

Den 4 apr. 2016 19:23 skrev "Sean Leonard" <[email-masked]>:
> Any “universal” address is going to have to have embedded info about the
protocol or system that it is addressing. See URI.

People see URL:s and think websites, they see email addresses and think
people.

OpenID essentially died. So did Mozilla's Personas. A bunch of RDF based
protocols too. And many many more. They all shared the URI. It was
*something extra* people has to remember and share besides their email.

If we're going with an URI, what do we put in the protocol field? Do we go
for a magnet link type address where you encode an URL in the URI if you're
using a server, and otherwise specify a protocol and public key, etc? Next
question, the more serious one; who'll even try to share that URI? Who's
gonna read it over the phone? Exactly nobody. It will be forgotten.

Or do we go with HTTP + special HTML tags on websites like OpenID did and
go for standard URL:s? Besides the tendency of HTML tags to get broken in
website redesigns, the total lack of an enforceable standard for how
transparency logs could be implemented (how will you even know where these
tags can be found on arbitary domains, since few will accept using your
page naming conventions?), HTML parsers tend to have bugs.

Also, that situation would also practically by default lead to developers
forgetting about other lookup/connectivity protocols, like Namecoin and
I2P, where their addresses won't even be recognized.

That's why I stick to email addresses here. We can actually enforce a
secure way to implement the lookups if we use them.

---

From: Natanael <[email-masked]>
Date: Tue, 5 Apr 2016 11:09:20 +0200

- Sent from my phone
Den 5 apr. 2016 09:17 skrev "John Gilmore" <[email-masked]>:
> > under your control, that you can use everywhere, securely.
>
> The key idea here is a bad idea.
>
> I don't want everyone I interact with to have the same identifier for
> me.  That's the problem with Social Security Numbers.  With a single
> identifier, all the interactions with me can be cross-correlated to
> track me everywhere I go.  Typically this is done NOT for my
> benefit, but to give some third party an advantage over me.

No problem. This is a per-nickname identifier. Use temporary disposable /
throwaway accounts or context specific accounts if you wish. Then you won't
have everything linked to the same account.

> > protocols too. And many many more.
>
> And, from my point of view, this is why they died.  I had zero
> interest in helping third parties keep track of me everywhere, using
> the same identifier on widely varying sites.  It's already hard enough
> work to keep Google out of my underwear when I don't even have an
> account with them.  If I had the same account everywhere?  Let's not
> go there.  "Login with your Facebook account?"  No thanks!!!

The type of tech Mozilla Personas (or U2F) was using to anonymize the
original account you connected with can be reused, although that would
break the universal addressing aspect.

Or how about this - you can link multiple profiles / personas / nicknames
to your account, including creating throwaways, and get to chose which one
to link third party services too when you register with them.

---

From: Harlan Lieberman-Berg <[email-masked]>
Date: Mon, 04 Apr 2016 23:31:49 -0400

> *something extra* people has to remember and share besides their email.

Persona used email addresses, actually, for the explicit reason that it
was easier to remember than a URI, and more familiar to end-users.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

---

From: John Gilmore <[email-masked]>
Date: Tue, 05 Apr 2016 00:17:11 -0700

Every online service that I interact with gets a different identifier
for me.  Every one gets a different email address for me.  If you send
email to one, they mostly lead to the same mailbox, though that's not
obvious from the addresses, and is under my later control.  (Some of the
email addresses that websites demand of me lead to places like
mailinator.com, which offers free disposable email addresses that will
let you read the one email message that "verifies" that this is a "real"
email address, and then quietly file and discard all the spam that the
websites send there subsequently.)

Provider A has no idea that I'm the same guy as Provider B's customer Joe.
They don't need to know, and I prefer that they not know.  

ssh public key authentication has this problem too.  Its default is to
assume that you want to use your same local identification to identify
you to every remote site that you try to access.  What a clueless
idea.  Luckily, ssh has survived despite this.  If you avoid its whole
public-key-per-user aspect, you can use it reliably with usernames and
passwords, different on every site.

	John

---

From: aestetix <[email-masked]>
Date: Wed, 6 Apr 2016 07:26:02 +0200

>have everything linked to the same account.

The problem with "nick-name" is it assumes all the names are tied to a "real" name.

Another problem with having a single root or key identifier: who decides what it is? Being able to pick your name has a lot of power to it, and handing that agency over to a third party also hands that power to them. This is one of the reasons that prisoners are often assigned a number they are required to use instead of their names.

If I am going to interact with multiple services, I want control over how I do that interaction. Forcing me to use names that branch off a single origin point defeats the entire purpose.

>The type of tech Mozilla Personas (or U2F) was using to anonymize the original
>account you connected with can be reused, although that would break the
>universal addressing aspect.
>
>Or how about this - you can link multiple profiles / personas / nicknames to
>your account, including creating throwaways, and get to chose which one to link
>third party services too when you register with them.
>

>The cryptography mailing list
>[email-masked]
>http://www.metzdowd.com/mailman/listinfo/cryptography

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Wed, 6 Apr 2016 11:41:15 +0000

A root (the person) uses multiple systems on which possibly 
multiple core identifiers are created and from each of those
potentially many *contact* identifiers are created and then 
associated with the communications service points to which the
person wishes them to be established.  

a.k.a: A tree: a person, with multiple devices, with multiple 
"core" identifiers yealding multiple end-point identifiers which 
are bound to selected communications services.

So long as the person gets to choose how one end-point identifier
leads to others, you're on the right track.  I suggest that as a 
minimum, no end-point identifier should every be able to be found
to lead to another which originates from a different "core"
identifier (traffic analysis and general op-sec notwithstanding).

/Hugo