From nobody Mon Apr 4 07:56:32 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C31012D744 for ; Mon, 4 Apr 2016 07:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o89UcctlPGlg for ; Mon, 4 Apr 2016 07:56:26 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7110112D78A for ; Mon, 4 Apr 2016 07:56:00 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id c6so24156200qga.1 for ; Mon, 04 Apr 2016 07:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=2BkG328G0gBYhTXpqxCxZQKz6cv2FmRv0W3zVqi5Ka4=; b=GmIsKd6mFssRiE/zUYsYzQ1XedH2+1f/IJ+vCycV3ACu5OLnhteiyvcvvsNF0z7giR /5KL1ZtPJS5IjbbwCImI4w+KcCvHlRGV9WPeIoQ+jWW2Y/FFmjL1XjGC+mOQTeOySa4F kmR/07pBgqkOwL5OwzW5aJe4xeWZKyPrI8se/m08BEFI3n1W9vhbFkEMxUDPPoY6qwg6 DyniWxSt+tI588jCHUWuWBh5k0RBqwII00SuAyokThovGxYSqZrkd43XU/Ar6qQivWfa dnsUpAkONGTcXdq+QQTBigNAeY0GFx4qmxCc7KtxdbiJA7UXPXs8uV0sBv3boKPbPoHD qDaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=2BkG328G0gBYhTXpqxCxZQKz6cv2FmRv0W3zVqi5Ka4=; b=JT2JD42TmAVbJ0qY70Nujj+bqU5CEHlmRT5+zvm8wZb03SAPz6JZVh/dh9BpjhAGID 3G+l6rIsvv1ICBvTfelCQQmKVYWi0HoATs+QwbyAISk/fiZRbo40iyc1201RU54JsQoQ g9Ria6GXAFhgLI+V3m3kBVImtyj+sYUQ2hc594+Nl5w5L8QKy+krqQb9iLqzb3LGmYb/ qDhjTBKCKJjx313HcSJKD3BUkEcDKbcpDSgRsMWEk3vCpDGfCuc39WF5XWtIxFWNvEL1 Otd2NpFF0ju22aEp4yiDm8c7oH9ibXCku6gngH++i3hWC4aqXeZ6U0B9eb2COKoBgBMV d6tQ== X-Gm-Message-State: AD7BkJLPT909SHMEOIrnaY+bKQieA5cKQWGXUV2SDuEpD3otsfDyzkSi2Vbx2M9sWmpJOvhdFkc9w7050ngw5Q== MIME-Version: 1.0 X-Received: by 10.194.174.39 with SMTP id bp7mr13617602wjc.28.1459781759326; Mon, 04 Apr 2016 07:55:59 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Mon, 4 Apr 2016 07:55:58 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Mon, 4 Apr 2016 07:55:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 16:55:58 +0200 Message-ID: From: Natanael To: endymail , Cryptography Mailing List , Crypto List , messaging , Cryptographers List Content-Type: multipart/alternative; boundary=089e0149371c36e458052fa9ed9e Archived-At: Subject: [Endymail] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:56:30 -0000 --089e0149371c36e458052fa9ed9e Content-Type: text/plain; charset=UTF-8 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? --089e0149371c36e458052fa9ed9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm crossposting this to a few lists, a few of the relev= ant 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 desig= n 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 ver= sion 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 buildi= ng 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 glob= al identifier which can be used to find out which communication protocols e= ach other user supports and how to connect to them.

Email address type identifiers are already familiar and won&= #39;t go away. We are practically already heading this way with email too;<= /p>

Given that we have the combo of protocols like DMARC, DKIM, = SPF, TLS, DNSSEC+DANE and of course the very relevant WebFinger for user pr= ofile data (https://webfinger.net/),= and that we have companies like Google, Yahoo and Microsoft working on SMT= P STS, we are already building much of the infrastructure necessary for sec= ure addressing. Every server / node would continously check which one's= the strongest protocol supported by each other server / node they've c= ommunicated 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 sudd= enly 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 h= ide if the sending client / server / node always logs the recipient's s= erver's responses (making forged replies trivially provable, hurting th= e server's reputation in seconds by publishing the conflicting log entr= ies). 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 us= ers will be using (fixed) servers (or even IPv4/6 addresses), so perhaps th= e domain part of email type addresses could be a domain name format that sp= ecifies that it identifies a P2P node and its protocol (like a Namecoin pro= file or an I2P node holding your profile data, or a CJDNS node). Including = public key identifiers in the addresses would most likely be necessary, unl= ess you're dealing with protocols like Namecoin for fetching profile da= ta.

Those who wants to place their own P2P nodes in the domain f= ield 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 communi= cate with can connect to your P2P node), instead of using a third party ser= ver. 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 trans= lating proxies for P2P protocols (kind of like i2= p.to and the Tor equivalent, "inproxies") without any loss of= security.

#

The user experience would end up looking like Keybase.io, bu= t with their account ownership proof process looking more like the OAuth pr= ocess (usually initiated via the third party service/client by entering you= r email to register after logging in), where most likely it would be your e= xisting email provider offering this addressing service.

Every messaging system you add would be linked to your accou= nt, both server based ones and P2P ones (with their respective unique user = identifiers), allowing anybody who want to message you securely to detect t= hat you support protocols with better security than the arcane SMTP. If bot= h 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 ov= er SMTP. As more email servers upgrade they would quickly start to detect t= hat the rest of them also supports stronger security, and upgrade the secur= ity 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 st= arted using wouldn't be getting an invite email (invite emails are gett= ing boring, aren't they?) telling them to register to see the message -= instead that service would see which compatible service the friend is usin= g and connect to it, and pass it on.

#

We need secure push messaging, IM, mail and much more, and i= f we can tap into the existing infrastructure through email and make the us= er experience both easier AND more secure, we are much more likely to see s= ecure versions of all these protocols implemented. If connecting secure pro= tocols to your account is easy and transparent for everybody involved, ther= e 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 t= oday, 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 sing= le username for every service a person uses separately. Opening the contact= details for a person would simply show you which protocols you both alread= y 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 add= resses) and switch servers, they could set a redirect to the new address th= at 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. The= re's no clear standard for how to achieve this with them. One could bui= ld 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 blockc= hain per user for something resembling transparency logs, and uses identify= ing 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. <= /p>

The key idea here is that you get to have *one* identifier f= or yourself under your control, that you can use everywhere, securely. Know= ing that people have your real address should provide a strong guarantee th= at messages from them to you will go only to you. And you shouldn't nee= d to change address because you changed messaging services.

How would you guys go about designing a system like what I d= escribe? How would you get it to play nice with P2P nodes?

--089e0149371c36e458052fa9ed9e-- From nobody Mon Apr 4 10:24:01 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2CD12D158 for ; Mon, 4 Apr 2016 10:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_dGS-P3jXym for ; Mon, 4 Apr 2016 10:23:57 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC05112D766 for ; Mon, 4 Apr 2016 10:23:56 -0700 (PDT) Received: from dhcp-aa67.meeting.ietf.org (unknown [31.133.170.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A7FE050A86; Mon, 4 Apr 2016 13:23:53 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EE3AF882-7552-4C8D-8EB1-AEDB1408432D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Mon, 4 Apr 2016 14:23:52 -0300 Message-Id: <9FC3BDD6-5246-4842-A6A4-FE272B0BACA3@seantek.com> References: To: Natanael X-Mailer: Apple Mail (2.3124) Archived-At: Cc: messaging , Cryptographers List , Cryptography Mailing List , Crypto List , endymail Subject: Re: [Endymail] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:23:59 -0000 --Apple-Mail=_EE3AF882-7552-4C8D-8EB1-AEDB1408432D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think it=E2=80=99s called a URI. Any =E2=80=9Cuniversal=E2=80=9D 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 wrote: >=20 > 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; >=20 > 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 = > ##### >=20 > 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. >=20 > 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. >=20 > Email address type identifiers are already familiar and won't go away. = We are practically already heading this way with email too; >=20 > 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. >=20 > # >=20 > 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. >=20 > # >=20 > 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. >=20 > 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. >=20 > 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. >=20 > # >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > # >=20 > 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. >=20 > 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. >=20 > 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. >=20 > # >=20 > Here's the existing systems I know of which comes close, with = comments; >=20 > * 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?=20 > * Namecoin. A public P2P blockchain system, not universal. Requires a = full node or connecting to a trusted third party node for lookups.=20 > * Keybase.io. Not designed for addressing, URL identifiers.=20 > * 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. >=20 > 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. >=20 > How would you guys go about designing a system like what I describe? = How would you get it to play nice with P2P nodes? >=20 > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail --Apple-Mail=_EE3AF882-7552-4C8D-8EB1-AEDB1408432D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think it=E2=80=99s called a URI.

Any =E2=80=9Cuniversal=E2=80=9D 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 <natanael.l@gmail.com> 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://lists.randombit.net/pipermail/cryptography/
http://www.ietf.org/mail-archive/web/endymail/current/maillist.= html
https://moderncrypto.org/mail-archive/messaging/2014/thread.htm= l

#####

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?

_______________________________________________
Endymail = mailing list
Endymail@ietf.org
https://www.ietf.org/mailman/listinfo/endymail

= --Apple-Mail=_EE3AF882-7552-4C8D-8EB1-AEDB1408432D-- From nobody Mon Apr 4 11:11:26 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0636812D768 for ; Mon, 4 Apr 2016 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCdZ0DdkkR38 for ; Mon, 4 Apr 2016 11:11:18 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C5012D134 for ; Mon, 4 Apr 2016 11:11:17 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id e190so5091492lfe.1 for ; Mon, 04 Apr 2016 11:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=w5cWuWjsr8JLTgsBbTy/lmJxMdTqHusEeSTTAvTXWtI=; b=fcXsKBwfti0RU9/F/i1o4jrsCk+48XjF5xH4Uq+BfPiEpNgABwWQgFNY1NwCiY6cbf nCE55B6US/k2ZKw8VgB2ogiq2Fej4fItjuSfcIoe2iV3/qEY/HP27PIkX/6PrE92rjBg LDx5NBwwUsy4JUvJ7okJudpiYPEDKUPVYazFItdCMvTUS0J9DOBTC6acVCKwbWqCVr6L bdQsMqjN46eLuLKz1RLgoIXwzfF1Ip3Pl7ss46vr79RJ6HdZcjrMCw93PI5ybt6GetpR owDEQsZV8gLWJghYt4dDaZ8ZPzy+I/rbDeCfAtawnFsDEXfJ795pMM4a/9FWE/m03c5I 5IhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=w5cWuWjsr8JLTgsBbTy/lmJxMdTqHusEeSTTAvTXWtI=; b=k9l4lDRbM+jqe6ukk/1L1OdGDIyS3SxIGuK+nW6JNdpAREkxG6Y+5/M5N5ArSHJnWF uoB3FE2rFSRaoZmt7Yl1CUm/h1ctDoM80o10rwSnW5aeksRFPiOG4DHCm60haqUvkOjC l/dhD1279+7UelLl5NUZbfsLdPED/vI/FNw9o2UiunNWt4KrFDwwcY4JAB4npI6TRLTe x0768ohl6ANieqheG8uq2xJY85MbSGW5cmut4NmUkVjzHAWXGU8k74FAN0zYIhZ0Kknb 4E2SoHaphDD0z6a0pEH/nCuqjFsiNtJAvyTSKmzgyoEWOuacWRJ9vEgEKY6LlRhoi3D7 qa3w== X-Gm-Message-State: AD7BkJJmQaNP7V9riKArCs/JL1WMWnWbYZoxxzTQE7J1WqqGczvPLu1K7BHgaFF+R3I8SK/YrheXM+l0GWT2vA== MIME-Version: 1.0 X-Received: by 10.194.171.130 with SMTP id au2mr14060728wjc.99.1459793475989; Mon, 04 Apr 2016 11:11:15 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Mon, 4 Apr 2016 11:11:15 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Mon, 4 Apr 2016 11:11:15 -0700 (PDT) In-Reply-To: <9FC3BDD6-5246-4842-A6A4-FE272B0BACA3@seantek.com> References: <9FC3BDD6-5246-4842-A6A4-FE272B0BACA3@seantek.com> Date: Mon, 4 Apr 2016 20:11:15 +0200 Message-ID: From: Natanael To: Sean Leonard Content-Type: multipart/alternative; boundary=089e011773ef94fab6052faca7f8 Archived-At: Cc: messaging , Cryptographers List , Cryptography Mailing List , Crypto List , endymail Subject: Re: [Endymail] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:11:25 -0000 --089e011773ef94fab6052faca7f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Den 4 apr. 2016 19:23 skrev "Sean Leonard" : > > I think it=E2=80=99s called a URI. > > Any =E2=80=9Cuniversal=E2=80=9D 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. --089e011773ef94fab6052faca7f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Den 4 apr. 2016 19:23 skrev "Sean Leonard" <dev+ietf@seantek.com>:
>
> I think it=E2=80=99s called a URI.
>
> Any =E2=80=9Cuniversal=E2=80=9D address is going to have to have embed= ded info about the protocol or system that it is addressing. See URI.

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

OpenID essentially died. So did Mozilla's Personas. A bu= nch 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 e= mail.

If we're going with an URI, what do we put in the protoc= ol field? Do we go for a magnet link type address where you encode an URL i= n the URI if you're using a server, and otherwise specify a protocol an= d 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 O= penID did and go for standard URL:s? Besides the tendency of HTML tags to g= et broken in website redesigns, the total lack of an enforceable standard f= or 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 y= our 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 Na= mecoin and I2P, where their addresses won't even be recognized.

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

--089e011773ef94fab6052faca7f8-- From nobody Tue Apr 5 02:09:27 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA59A12D10A for ; Tue, 5 Apr 2016 02:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXWuUg0z0--j for ; Tue, 5 Apr 2016 02:09:22 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E5912D13F for ; Tue, 5 Apr 2016 02:09:22 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id 20so2393729wmh.3 for ; Tue, 05 Apr 2016 02:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7mN8YKPKbZYn/FfqyRxnjVuQUA0ElTiKWOYLocpG5NQ=; b=uVQB9ZmP5E2WPb7Rq2yuztNXNyqmn0iIvxmZv8Q4cwC6JD1JksC1pj+2zfAqFoSuiB XRqv3UIdmPve7R0zo8bGSXsAaOa9cmZHViF/bjrCV2eFHEPH9ZwUJWQ5gF5iOPiz5cUA 9/R4vcVbQ0B7+NqMo4+HMnaA/x4lETEcgy3w24/UR37zNlWnN595U0eRlYyhNjgmsB97 YBbGm/1N0nxYYKAnF+XCQEj8ipnpX6srFlW+v+bwHF7BBtvgbWG2GViAwvHyDeqKiTtw Hupi1ij94Rcv+2hc86Fu64xfURVkqAViBDp6EVYYDu8sijJY+65fWAP5NjqPifm8LNOz 7sVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7mN8YKPKbZYn/FfqyRxnjVuQUA0ElTiKWOYLocpG5NQ=; b=NGTzLqjKHMDRB9mnE3CT6K6T5Ubw0UjEZkyYvnNR4ccsr8NvonUlfC6VQetPFw0Vc1 OlgVlX26MZ3JA4Aa70hhYXUl8SLJMmXAl4F8lZjb7qce1CbRx/wydig/uKYr1xdIojmn TrvEs+gRRdUXdflUKiNkmhPIeL6U1Ex/BjCXr/noP2pVZ1iPLp6RNNSG9VnQdPU1Yfre TWprD0j0nPgSzQ8lXGf+VM5WlCuFsQBQwRHz9FfW9Y+xU0Qk4UCqsA0KiOPwslqlXON2 3G75KWWKjNkzOv90xvWBBvbfiy3Pz2iETwtXBporMm1tAZAkaplk2Rl64s3ggAkB5zc4 7I8g== X-Gm-Message-State: AD7BkJIF3cOLsZjlScRRqSORUBON20wFT5eOBwMsWTwEukbS06u4zVuDZGuHgYKwiqik1pyhdHbD0JclJSktwA== MIME-Version: 1.0 X-Received: by 10.194.174.39 with SMTP id bp7mr17737423wjc.28.1459847360699; Tue, 05 Apr 2016 02:09:20 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Tue, 5 Apr 2016 02:09:20 -0700 (PDT) Received: by 10.194.23.195 with HTTP; Tue, 5 Apr 2016 02:09:20 -0700 (PDT) In-Reply-To: <201604050717.u357HBfc014889@new.toad.com> References: <201604050717.u357HBfc014889@new.toad.com> Date: Tue, 5 Apr 2016 11:09:20 +0200 Message-ID: From: Natanael To: John Gilmore Content-Type: multipart/alternative; boundary=089e0149371c5c6a92052fb93324 Archived-At: Cc: messaging , Cryptographers List , Cryptography Mailing List , Crypto List , endymail Subject: Re: [Endymail] [Cryptography] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 09:09:26 -0000 --089e0149371c5c6a92052fb93324 Content-Type: text/plain; charset=UTF-8 - Sent from my phone Den 5 apr. 2016 09:17 skrev "John Gilmore" : > > > The key idea here is that you get to have *one* identifier for yourself > > 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. > > OpenID essentially died. So did Mozilla's Personas. A bunch of RDF based > > 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. --089e0149371c5c6a92052fb93324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

- Sent from my phone
Den 5 apr. 2016 09:17 skrev "John Gilmore" <gnu@toad.com>:
>
> > The key idea here is that you get to have *one* identifier for yo= urself
> > 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.=C2=A0 That's the problem with Social Security Numbers.=C2=A0 W= ith a single
> identifier, all the interactions with me can be cross-correlated to > track me everywhere I go.=C2=A0 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.

> > OpenID essentially died. So did Mozilla's Pers= onas. A bunch of RDF based
> > protocols too. And many many more.
>
> And, from my point of view, this is why they died.=C2=A0 I had zero > interest in helping third parties keep track of me everywhere, using > the same identifier on widely varying sites.=C2=A0 It's already ha= rd enough
> work to keep Google out of my underwear when I don't even have an<= br> > account with them.=C2=A0 If I had the same account everywhere?=C2=A0 L= et's not
> go there.=C2=A0 "Login with your Facebook account?"=C2=A0 No= thanks!!!

The type of tech Mozilla Personas (or U2F) was using to anon= ymize 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 / persona= s / nicknames to your account, including creating throwaways, and get to ch= ose which one to link third party services too when you register with them.=

--089e0149371c5c6a92052fb93324-- From nobody Tue Apr 5 04:39:30 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9091B12D1CA for ; Mon, 4 Apr 2016 20:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=setec.io header.b=YcRGhBGt; dkim=pass (1024-bit key) header.d=setec.io header.b=XdlK+agC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efmRJmgK4zb6 for ; Mon, 4 Apr 2016 20:31:51 -0700 (PDT) Received: from xmenrevolution.com (xmenrevolution.com [97.107.134.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1791112D183 for ; Mon, 4 Apr 2016 20:31:51 -0700 (PDT) Received: by xmenrevolution.com (Postfix, from userid 113) id 28E6F16A9E; Mon, 4 Apr 2016 23:31:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1459827110; bh=jXLE9jbHDuAoVqVblQySkA0k1xGRHV7PzxoacOnfFxI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YcRGhBGtjQKaxKAOdZru6DHAXiuB59BXpq1D0U0L1gaiwoTNgvbTyg85CEo2S3Ovy qulNwOLwO/+BBMXJSN4FnK+iZrmqiNeTJE/3mn4K3b9FF/A0RZ40jukNpi6dlcEAaW kKLAhnMUYOAKQrf9sWiY1opfKsHDDD2y21GV0ihA= Received: from agartha (209-6-40-250.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.40.250]) by xmenrevolution.com (Postfix) with ESMTPSA id 86E8516A8B; Mon, 4 Apr 2016 23:31:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1459827109; bh=jXLE9jbHDuAoVqVblQySkA0k1xGRHV7PzxoacOnfFxI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XdlK+agCL8MqNZVSMCOWn0PeKCB0jFiUKjens2r/7a1YWW0ZWR1ohQTbWsABAY7hu wbQMTbSwsNE0BHHNOYM02R7DDHe69vRJn8Gea0OKDGfJwGXfiWFdjUMM+TFGlbP0C1 RnHb0WD0Bw+U5hGrJjhd2nbtiZgW5a+VFVUIhAKg= From: Harlan Lieberman-Berg To: Natanael , Sean Leonard In-Reply-To: References: <9FC3BDD6-5246-4842-A6A4-FE272B0BACA3@seantek.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 04 Apr 2016 23:31:49 -0400 Message-ID: <87egakg28q.fsf@setec.io> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Tue, 05 Apr 2016 04:39:28 -0700 Cc: messaging , Cryptographers List , Cryptography Mailing List , Crypto List , endymail Subject: Re: [Endymail] [messaging] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 03:31:52 -0000 Natanael writes: > 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. 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 nobody Tue Apr 5 04:39:32 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29D512D954 for ; Tue, 5 Apr 2016 00:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.585 X-Spam-Level: *** X-Spam-Status: No, score=3.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_PSBL=2.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzQteGpTSorc for ; Tue, 5 Apr 2016 00:17:17 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE5712D125 for ; Tue, 5 Apr 2016 00:17:16 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id u357HBfc014889; Tue, 5 Apr 2016 00:17:11 -0700 Message-Id: <201604050717.u357HBfc014889@new.toad.com> To: Natanael In-reply-to: References: Comments: In-reply-to Natanael message dated "Mon, 04 Apr 2016 16:55:58 +0200." Date: Tue, 05 Apr 2016 00:17:11 -0700 From: John Gilmore Archived-At: X-Mailman-Approved-At: Tue, 05 Apr 2016 04:39:28 -0700 Cc: messaging , Cryptographers List , Cryptography Mailing List , Crypto List , endymail Subject: Re: [Endymail] [Cryptography] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 07:17:19 -0000 > The key idea here is that you get to have *one* identifier for yourself > 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. 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. > OpenID essentially died. So did Mozilla's Personas. A bunch of RDF based > 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!!! 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@aestetix.com Tue Apr 5 22:26:54 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6112D7F9 for ; Tue, 5 Apr 2016 22:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kQynwc64gZV for ; Tue, 5 Apr 2016 22:26:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E274A12D788 for ; Tue, 5 Apr 2016 22:26:51 -0700 (PDT) Received: from dan ([79.197.107.54]) by mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id 0MW9l9-1bL1b73xAv-00XOLt; Wed, 06 Apr 2016 07:26:09 +0200 Date: Wed, 6 Apr 2016 07:26:02 +0200 From: aestetix To: Natanael Message-ID: <20160406052601.GC6265@dan> References: <201604050717.u357HBfc014889@new.toad.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RIYY1s2vRbPFwWeW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:T6GrYniCzBF+Al/0550ugM1SqN+tCC86TpIokh0pTp+x6cDASHn dWGtLunO5XU+AgKUf7afDjlxZMUqHMDKhfVanFWQ6AwKe1jIsF9kVn5SzMwDMY7wW3iA6MX Abb4245vFQ5FHc+/Uqi0l9hUhD1cExxSlLDWBJPjGsGyQEGnJQ5QRxbsO5z97IuiIl+VOKM /BRGjISJ9Owg1K38+9uuQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:0QANEXUmuSg=:4KwnkYKlUsJEgHcCnb1rYp Z2L/lvRRp2UDwSve1tscEOI1vDRT2DNuYeSNHNl+jcrcRGN7gOCjEeutlT7vp62yrSfcv2bAO 16yYXyx9YUqgx+21dXlONIjxh4jAjgDSvUnf8s9UexmGvFyoph/QXEa0q4GKQYyIZILyj21Fq mOoG6aT2QQndCXomptIocSypbhFNbwtE3fdh6Ta15ElKNDVh5zw3OYSyq00EQCFZZv4UwB5G6 o0yNDSF+WVoFDN8TwH6CDbgWQGmvESldTI8w+oUrRR+fmw9XR9G1zsAE87ABPSrRSCAAoMZ5N s6UzvuE3GcJxiheZ3o5galn4MtZJrWNltWh8lGF6nSIx7P/THaBBmcJlUuH/kr0xPXXVWzHX1 NR4Z+dl4cQzqo6CCywJ7EzZrUaz3nJ1QKziRoNwfwzii09Wf5DBzjRppFCJ9Fgu5Jj+yorIG0 nrfvwYpaoNioO9r8daW+T7uOrPVVpzMd3i9Ji30Dklj8F1qQCKRlvnUyweAunmzuak7E7+fWX mypNt0hhH1eiaLwDeJpdztt5CF6JtSD0h7E2CRLewo7mm5xvNM1YUfQq0rRx5kK56yJGPAo0U w7DeHXZ4J5lVeeHxYCXeBaL4MUaBnhXyHTF0GdtETr+9SbKArNY0FCX+eqzFSXWV6uArV4wBY TbSZSxY8Td4rBpaOWofjev4/DKjp2qHswl9GQplbOikkG36ofBxLl2vbtjxKYReouR0U= Archived-At: X-Mailman-Approved-At: Wed, 06 Apr 2016 04:31:19 -0700 Cc: Cryptography Mailing List , Crypto List , John Gilmore , endymail , messaging , Cryptographers List Subject: Re: [Endymail] [Cryptography] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 05:28:47 -0000 --RIYY1s2vRbPFwWeW Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 05, 2016 at 11:09:20AM +0200, Natanael wrote: >- Sent from my phone >Den 5 apr. 2016 09:17 skrev "John Gilmore" : >> >> > The key idea here is that you get to have *one* identifier for yourself >> > 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.=A0 That's the problem with Social Security Numbers.=A0 With a single >> identifier, all the interactions with me can be cross-correlated to >> track me everywhere I go.=A0 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. The problem with "nick-name" is it assumes all the names are tied to a "rea= l" name. Another problem with having a single root or key identifier: who decides wh= at it is? Being able to pick your name has a lot of power to it, and handin= g 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 requ= ired 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 orig= in point defeats the entire purpose. > >> > OpenID essentially died. So did Mozilla's Personas. A bunch of RDF bas= ed >> > protocols too. And many many more. >> >> And, from my point of view, this is why they died.=A0 I had zero >> interest in helping third parties keep track of me everywhere, using >> the same identifier on widely varying sites.=A0 It's already hard enough >> work to keep Google out of my underwear when I don't even have an >> account with them.=A0 If I had the same account everywhere?=A0 Let's not >> go there.=A0 "Login with your Facebook account?"=A0 No thanks!!! > >The type of tech Mozilla Personas (or U2F) was using to anonymize the orig= inal >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 >cryptography@metzdowd.com >http://www.metzdowd.com/mailman/listinfo/cryptography --RIYY1s2vRbPFwWeW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXBJ3pAAoJEOrRfDwkjbpTITsH/i3BmEIa3aW1AroVE0Xfv7fJ hFnBkPWp4sm0YgGSz7s35uT0h6USRejjbjOJVqU4rfq/9hVUpapOgfwYXCEEb0fM QUFZaEl1W7WPtfveBgkQ+3sajZy5Ir1ndmfyYmUThvQ66ggG/OJvM3s3/T4wTnlb n26Dh+EICADRN9xj7XqMhBssImn3g4Tp5fO3b1GIMReoeAKRBu0rvk7xtfOp4AMH 91zqHES3VzzHX4Cc0pkWHB7hO5bJ7fcp8FD/PbFf37JAooGw7ln/6GJh9OvXcaYO e01vF+/NuLpFIxFfGHqbQMcJm2e9GgCxUswJaVuhGwAgWLIMrdSDO96kIOg3tAQ= =LyD5 -----END PGP SIGNATURE----- --RIYY1s2vRbPFwWeW-- From nobody Wed Apr 6 05:12:59 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDAF12D18A for ; Wed, 6 Apr 2016 04:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aXdk2TrudcL for ; Wed, 6 Apr 2016 04:41:06 -0700 (PDT) Received: from spamfilter1.dtu.dk (spamfilter1.dtu.dk [130.225.73.112]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB71512D1B2 for ; Wed, 6 Apr 2016 04:41:05 -0700 (PDT) Received: from ait-pexedg02.win.dtu.dk (ait-pexedg02.win.dtu.dk [192.38.82.192]) by spamfilter1.dtu.dk with ESMTP id u36BfFHi031503-u36BfFHk031503 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Wed, 6 Apr 2016 13:41:15 +0200 Received: from ait-pex02mbx06.win.dtu.dk (192.38.80.18) by ait-pexedg02.win.dtu.dk (192.38.82.192) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 6 Apr 2016 13:41:09 +0200 Received: from ait-pex01mbx01.win.dtu.dk ([169.254.1.158]) by ait-pex02mbx06.win.dtu.dk ([169.254.6.185]) with mapi id 14.03.0266.001; Wed, 6 Apr 2016 13:41:16 +0200 From: Hugo Maxwell Connery To: aestetix , Natanael Thread-Topic: [Endymail] [Cryptography] Secure universal message addressing Thread-Index: AQHRjxruvTX09uLspEqOhQUlWhAAf598SeEAgACIl5E= Date: Wed, 6 Apr 2016 11:41:15 +0000 Message-ID: <6CB05D82CE245B4083BBF3B97E2ED47016E56A15@ait-pex01mbx01.win.dtu.dk> References: <201604050717.u357HBfc014889@new.toad.com> , <20160406052601.GC6265@dan> In-Reply-To: <20160406052601.GC6265@dan> Accept-Language: en-AU, da-DK, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.225.73.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 06 Apr 2016 05:12:58 -0700 Cc: Cryptography Mailing List , Crypto List , John Gilmore , endymail , messaging , Cryptographers List Subject: Re: [Endymail] [Cryptography] Secure universal message addressing X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 11:41:08 -0000 A root (the person) uses multiple systems on which possibly=20 multiple core identifiers are created and from each of those potentially many *contact* identifiers are created and then=20 associated with the communications service points to which the person wishes them to be established. =20 a.k.a: A tree: a person, with multiple devices, with multiple=20 "core" identifiers yealding multiple end-point identifiers which=20 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=20 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=