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

"Russ White" <russw@riw.us> Wed, 04 September 2013 12:20 UTC

Return-Path: <russw@riw.us>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A5511E819B for <perpass@ietfa.amsl.com>; Wed, 4 Sep 2013 05:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level:
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QghTkBkHQWb3 for <perpass@ietfa.amsl.com>; Wed, 4 Sep 2013 05:20:33 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id DA27511E816F for <perpass@ietf.org>; Wed, 4 Sep 2013 05:20:32 -0700 (PDT)
Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <russw@riw.us>) id 1VHC4V-0001UE-2y; Wed, 04 Sep 2013 05:20:31 -0700
From: Russ White <russw@riw.us>
To: 'Brian Trammell' <trammell@tik.ee.ethz.ch>
References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch>
In-Reply-To: <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch>
Date: Wed, 04 Sep 2013 08:20:43 -0400
Message-ID: <021601cea969$2e11c5e0$8a3551a0$@riw.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQIR6KI5VPGSlnCYcdzgGTryK4XgWAGiPwBwmSHptoA=
Content-Language: en-us
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Cc: perpass@ietf.org
Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2013 12:20:38 -0000

> 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