Subject: [perpass] (Possibly Dumb) EMail Security Idea

From: "Russ White" <[email-masked]>
Date: Wed, 4 Sep 2013 04:43:49 -0400

Y'all:

This entire issue with email security has been rattling around in my head
ever since it's been discussed on list. I keep wondering why we can't do
something TORRENT like with email... This is just a bare bones silly idea,
but bear with me for a moment.

Assume each person has more than one email address. Or at least they should
--there are a number of "free" email services out there (yahoo, Hotmail,
google, etc.), and everyone should have at least one email service through
their local "residence" provider, then maybe one through their mobile phone
provider, etc. Let's say you have a couple of new MIME types available, one
for breaking a single message up into multiple pieces and transmitting it in
parallel across many different SMTP services, and another that advertises
all the services you have available to you (treating each email address in
the traditional sense as a single service). What could happen is this:

-- Your email client recognizes not only all your existing email services,
but adds a new "unified identity service (UIS)."
-- Your email client can send a "services supported" MIME type to any other
client that supports this new UIS.
-- Someone hands you a business card with their UIS address.

What happens?

-- You send them an email. There is a hitch here because there must be a
single common channel known at this point, but let's leave this aside for a
moment.
-- Instead of sending them the email on the first shot, the enabled email
client sends a list of all the services this UIS supports.
-- The client on the other end gets this list, and compares to a local list
of supported services, and sends back a "valid list."
-- Your client now breaks each email up into multiple actual emails, sending
each piece as MIME attachment on an actual underlying email service. The
number of pieces depends on the number of overlapping services you have
available.
-- The receiving client gets all the different MIME attachments, one through
each service, reconstructs the original email, and delivers it to the UIS
inbox.

A couple of interesting things:

-- Once we introduce the idea of negotiating parameters through a MIME type,
it might actually be possible to do some sort of KIK thing to encrypt each
piece separately.
-- Large files can be sent more efficiently between UIS' by spreading the
load over multiple services.
-- As each "service" (a complete email service in today's terms) only gets
part of the message, anyone eavesdropping must now collate all the different
pieces to get a complete conversation.
-- You're introducing the idea of a unified identity that doesn't change
even if you change your email providers.

Maybe the client could even choose a different underlying SMTP service for
shorter messages, so that a single conversation is spread out among a lot of
different services, etc. 

Anyway, this is really bare bones, and I don't know enough about email to
put all the pieces together, or if this would even work, but it seemed like
throwing it out there just for discussion (even if it's to be shot down!).

Russ

---

From: Brian Trammell <[email-masked]>
Date: Wed, 4 Sep 2013 11:14:26 +0200

hi Russ,

Intriguing idea; the approach of striping content across multiple points at rest for eavesdropping resistance - spread-spectrum messaging, if you will - is definitely worth considering as a tool in the toolbox here.

A unified identity pushes us in the other direction, though, unless it's done very carefully... Comments inline.

> pieces to get a complete conversation.

I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise you have the problem that the information density and interesting-information-density in most email messages is unevenly distributed, and then you only really need some subset of the content to get the interesting information out.

> even if you change your email providers.

If each of the chunks contains the source identity and the destination identity, then you're essentially scattering the fact of the association between the source and the destination across multiple observation points. While it makes content recovery harder, it may make massive-scale association recovery easier. For pervasive surveillance, one could argue the associations are more interesting than the content. They're certainly easier to store and analyse en masse. 

Cheers,

Brian

---

From: "Russ White" <[email-masked]>
Date: Wed, 4 Sep 2013 08:20:43 -0400

> Intriguing idea; the approach of striping content across multiple points
at rest
> for eavesdropping resistance - spread-spectrum messaging, if you will - is
> definitely worth considering as a tool in the toolbox here.
> 
> A unified identity pushes us in the other direction, though, unless it's
done
> very carefully... Comments inline.

Very true... I was thinking of what could be done with existing tools,
rather than creating new ones. What would be ideal would be a real TORRENT
like email service, with its own port number and servers. There would still
be the problem of solving "open servers," which could be used to mass email
(spam) folks, but we might be able to think of other controls in that space.
If we can't to an entirely new system, though, what can we do with what we
already have given some modifications?

> > -- Once we introduce the idea of negotiating parameters through a MIME
> > type, it might actually be possible to do some sort of KIK thing to
> > encrypt each piece separately.
> > -- Large files can be sent more efficiently between UIS' by spreading
> > the load over multiple services.
> > -- As each "service" (a complete email service in today's terms) only
> > gets part of the message, anyone eavesdropping must now collate all
> > the different pieces to get a complete conversation.
> 
> I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise
> you have the problem that the information density and interesting-
> information-density in most email messages is unevenly distributed, and
> then you only really need some subset of the content to get the
interesting
> information out.

Hadn't thought of the noncontiguous piece... It's a fair point. As for
encrypted, I think that unless you build something new from the ground up,
encryption is still going to be up to the user. 

> > -- You're introducing the idea of a unified identity that doesn't
> > change even if you change your email providers.
> 
> If each of the chunks contains the source identity and the destination
> identity, then you're essentially scattering the fact of the association
> between the source and the destination across multiple observation points.
> While it makes content recovery harder, it may make massive-scale
> association recovery easier. For pervasive surveillance, one could argue
the
> associations are more interesting than the content. They're certainly
easier
> to store and analyse en masse.

Yes, this is the side effect... Again, short of creating a new system from
the ground up, I don't see any way around this side effect.

So... Maybe a new TORRENT like email system is in order, with encryption on
as a default? If it could use the same SMTP protocol for sending, that would
be cool, but I don't see how to do IMAP like functionality in a distributed
system of this type, unless you could use an encrypted online store that did
the gathering --but then you risk that online store being compromised, of
course. 

Russ

---

From: Patrick Pelletier <[email-masked]>
Date: Wed, 04 Sep 2013 12:40:51 -0700

> I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise you have the problem that the information density and interesting-information-density in most email messages is unevenly dist…

This reminds me a little bit of what Tahoe-LAFS is doing, since they 
encrypt, then do erasure coding, and send the pieces out to different 
servers.  The only difference is that you're doing it with email instead 
of files.

On the other hand, if you don't want to encrypt, then you could solve 
the information density problem by using an AONT:

https://en.wikipedia.org/wiki/All-or-nothing_transform

Then each piece would mean nothing unless you had all the pieces.

--Patrick

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Sep 2013 07:55:49 +0900

> servers.  The only difference is that you're doing it with email instead 

in berlin, jean lorchat, one of my fellow iij researchers demoed
  an app layer (calendar, but could be anything)
  on top of a layer of a strong identity, sharing, capabilities system
  on top of a distributed (to a bunch of volunteers homes) tahoe-lafs
think diaspora on a secure understructure with strong identity

i would also note the bittorrent sync cousin of these approaches

i like the space

randy

---

From: David Singer <[email-masked]>
Date: Wed, 04 Sep 2013 16:26:38 -0700

I fear this solution may suffer easily from the 'apparently separate channels problem'.

I recall some incident where people had bought triple-redundant links from different long-haul providers -- who all used the same underlying fiber.  One backhoe did them all in.  Similarly, if the client can easily identify which pieces go together, so can a snooper.

On Sep 4, 2013, at 12:40 , Patrick Pelletier <[email-masked]> wrote:

> This reminds me a little bit of what Tahoe-LAFS is doing, since they encrypt, then do erasure coding, and send the pieces out to different servers.  The only difference is that you're doing it with email instead of files.
> 
> On the other hand, if you don't want to encrypt, then you could solve the information density problem by using an AONT:
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: "Russ White" <[email-masked]>
Date: Wed, 4 Sep 2013 19:41:01 -0400

> I recall some incident where people had bought triple-redundant links from
> different long-haul providers -- who all used the same underlying fiber.
One
> backhoe did them all in.  Similarly, if the client can easily identify
which pieces
> go together, so can a snooper.

Shared common fate --but that's a different thing, I think. If you
specifically use a shared secret or something along those lines to break the
chunks up, then I think it might be pretty hard to put the pieces back
together. In this case, you might be able to use something like a "side
channel" to send a one time pad that's used as a hash to break the messiage
up, send each piece along a separate channel, and then put it all back
together on the other end... 

Of course, this all assumes a completely new email transport system, and it
assumes the server where the pieces are put back together is secure, or you
use a more POP-like system, where there is no storage of the complete
message on anything other than a local system...

I think this is all possible/doable. The question is --is the world ready
for a new email transport? Do we try and build it, to see if they will come?

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Sep 2013 11:40:58 +0100

Hi Randy,

> i would also note the bittorrent sync cousin of these approaches

Agreed. What's not clear to me though, is whether and how the
IETF could help with such efforts. (Same for Tor related work.)
If there are specific things the IETF could do to help make
those kinds of things better then that'd be very interesting to
know about.

If there are folks on here who're working on those technologies
who figure that the IETF could help, then having 'em say how
they think we could help would be great. I'd love to see a
bunch of threads like that on this list.

S.

---

From: "Russ White" <[email-masked]>
Date: Thu, 5 Sep 2013 07:10:32 -0400

> Agreed. What's not clear to me though, is whether and how the IETF could
> help with such efforts. (Same for Tor related work.) If there are specific
> things the IETF could do to help make those kinds of things better then
that'd
> be very interesting to know about.

Building a new bitorrent like protocol as an email transport? 

Russ