Re: [GNU/consensus] [SocialSwarm-D] Fwd: FYI: Securing the Future of the Social Web with Open Standards

[elijah]

On 07/24/2013 11:01 AM, carlo von lynX wrote:
> On Mon, Jul 22, 2013 at 10:13:04PM +0200, Melvin Carvalho wrote:
>> They are in the church of "your email is your identity" -- let's be clear
>> this is an unnecessary restriction with will not scale.  Other projects
>> (not mentioning any names) *cough cough* are also in this religious sect.
> 
> email needs to be discontinued in the long run. it doesn't serve any of
> the purposes it was constructed for. it gives the attacker a full view
> of the social network, a view into the content by default and it also
> fails at delivering to many recipients promptly and to handle spam.

This is a straw man argument. Yes, email as currently practiced has
problems, but there is no reason email cannot be reformed. There is
enough interest in secure email these days that I am certain the
problems will be solved. The needed pieces are (1) opportunistic
encryption via automatic key discovery/validation, (2) enforced StartTLS
(3) meta-data resistant routing. There are a couple good proposals on
the table for #1, postfix already supports #2 via DANE, and there are
four good ideas for #3 (auto-alias-pairs, onion-routing-headers,
third-party-dropbox, mixmaster-with-signatures [1]).

I do want to note that email has stood the test of time when it comes to
many recipients. I remember hosting email lists with 100k subscribers
and pushing millions of messages monthly on an ancient machine from
1998. Worked like a charm.

-elijah

[1] details on ideas for meta-data resistant routing in a federated
client/server architecture

* Auto-alias-pairs: Each party auto-negotiates aliases for communicating
with each other. Behind the scenes, the client then invisibly uses these
aliases for subsequent communication. The advantage is that this is
backward compatible with existing routing. The disadvantage is that the
user's server stores a list of their aliases. As an improvement, you
could add the possibility of a third party service to maintain the alias
map.

* Onion-routing-headers: A message from user A to user B is encoded so
that the "to" routing information only contains the name of B's server.
When B's server receives the message, it unwraps (unencrypts) a
supplementary header that contains the actual user "B". Like aliases,
this provides no benefit if both users are on the same server. As an
improvement, the message could bounce around intermediary servers, like
mixmaster.

* Third-party-dropbox: To exchange messages, user A and user B negotiate
a unique "dropbox" URL for depositing messages, potentially using a
third party. To send a message, user A would post the message to the
"dropbox". To receive a message, user B would regularly polls this URL
to see if there are new messages.

* Mixmaster-with-signatures: Messages are bounced through a
mixmaster-like set of anonymization relays and then finally delivered to
the recipient's server. The user's client only displays the message if
it is encrypted, has a valid signature, and the user has previously
added the sender to a 'allow list' (perhaps automatically generated from
the list of validated public keys).