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 protected]> 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. > > # > > 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? > > _______________________________________________ > Endymail mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/endymail
_______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
