Re: [cryptography] [Cryptography] Secure universal message addressing

[Ron Garret]

On Apr 4, 2016, at 7:55 AM, Natanael  wrote:
> 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?

SC4 (https://github.com/Spark-Innovations/SC4) is a simple open protocol based 
on TweetNaCl which uses Curve25519 keys as a user’s identity.  I have a 
prototype chat system working that uses a server to delivery messages, but 
extending this to a P2P model is pretty easy.  The encryption is end-to-end so 
it almost doesn’t matter how messages are delivered.  You could publish them on 
github if you wanted to.  SC4 chat is currently in private beta, but if you’d 
like to try it drop me a line.

rg

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Secure universal message addressing

[Natanael]

- 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.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Secure universal message addressing

[ianG]

On 4/04/2016 15:55 pm, Natanael wrote:


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.



You're trying to build a tool.  Then when that becomes hard, you're 
switching to another tool that is more or less harder.


Instead, how about setting up a set of requirements which are driven by 
users?  Although sometimes a boring process, it can drive a real design 
much more cleanly because there is a reason for every choice - a reason 
that relates up to what the user needs.



E.g.:


We need secure push messaging, IM, mail and much more,


Like that - except much more and more written down!


... If connecting secure
protocols to your account is easy and transparent for everybody
involved, there would be much less resistance towards changing clients.


"Can use multiple secure protocols as underlying transport?"


...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.


"Has contact management for each person that does...XXX"


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.


"A person has one identifier in another person's client?"


How would you guys go about designing a system like what I describe?



Like that above - requirements driven by business/people behaviour.


iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Secure universal message addressing

[Natanael]

I'm crossposting this to a few lists, a few of the relevant mail archives
are here for those who want to follow the replies on the other lists;

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

#

After spending way too much time thinking about how to design a secure
universal message passing platform that would work for both IM, email, push
messages and much more, I just ended up with a more complex version of XMPP
that won't really ever have lower latency, be scalable or be simpler to
operate or even be secure at all. So I dropped that idea.

Then I ended up thinking about addressing instead. If building one single
universal communication protocol is too hard, why couldn't it still be
simple to have one single universal protocol for identifying recipients /
users? It would allow each user to have one single unique global identifier
which can be used to find out which communication protocols each other user
supports and how to connect to them.

Email address type identifiers are already familiar and won't go away. We
are practically already heading this way with email too;

Given that we have the combo of protocols like DMARC, DKIM, SPF, TLS,
DNSSEC+DANE and of course the very relevant WebFinger for user profile data
(https://webfinger.net/), and that we have companies like Google, Yahoo and
Microsoft working on SMTP STS, we are already building much of the
infrastructure necessary for secure addressing. Every server / node would
continously check which one's the strongest protocol supported by each
other server / node they've communicated with recently, refusing to connect
over weaker protocols.

#

Add in transparency logs (perhaps Keybase style) and you've got very strong
security for the users. Stopping downgrade attacks suddenly becomes more
than plausible when there are reliable ways to detect if a server truly
supports secure protocols or not, and MITM becomes hard to hide if the
sending client / server / node always logs the recipient's server's
responses (making forged replies trivially provable, hurting the server's
reputation in seconds by publishing the conflicting log entries). A
Perspectives / SSL observatory model would also drastically improve the
detection rate for tampering.

#

That setup just lacks one capability which I consider major - playing well
with P2P networks lacking classical domain names. Not all users will be
using (fixed) servers (or even IPv4/6 addresses), so perhaps the domain
part of email type addresses could be a domain name format that specifies
that it identifies a P2P node and its protocol (like a Namecoin profile or
an I2P node holding your profile data, or a CJDNS node). Including public
key identifiers in the addresses would most likely be necessary, unless
you're dealing with protocols like Namecoin for fetching profile data.

Those who wants to place their own P2P nodes in the domain field could do
that, having that node carry the profile data which explains how to connect
to you (which would of course require that those you communicate with can
connect to your P2P node), instead of using a third party server. Most
people probably won't opt for this, but it should be possible.

Where the users or (end user trusted) servers are identified by public keys
in the addresses, it could be possible to have public translating proxies
for P2P protocols (kind of like i2p.to and the Tor equivalent, "inproxies")
without any loss of security.

#

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

Every messaging system you add would be linked to your account, both server
based ones and P2P ones (with their respective unique user identifiers),
allowing anybody who want to message you securely to detect that you
support protocols with better security than the arcane SMTP. If both sides
supports this protocol and a hypothetical email2 protocol that's tagged as
an upgrade over SMTP, no mail between you would ever be sent over SMTP. As
more email servers upgrade they would quickly start to detect that the rest
of them also supports stronger security, and upgrade the security for all
the users silently.

It would behave like account addressing within Google's suite of protocols
such as email + IM via Hangouts + Google Cloud Messaging + Google Docs,
etc, where the same email address is the account identifier for them all,
except that this would be an open universal protocol.

The recipient of a message from a third party service you started using
wouldn't be getting an invite email (invite emails are getting