[Endymail] Modular Mathematical Mesh

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 29 June 2015 17:44 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8D31B2C05; Mon, 29 Jun 2015 10:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 5.623
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.623 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FM_IS_IT_OUR_ACCOUNT=4.2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 PbjVqhIhC8Xu; Mon, 29 Jun 2015 10:44:25 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (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 75F8B1B2BFA; Mon, 29 Jun 2015 10:44:25 -0700 (PDT)
Received: by lagx9 with SMTP id x9so134653742lag.1; Mon, 29 Jun 2015 10:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=uFRIPgMmD+u4zotKGJ7mNj+TZ3RYPMXjGifXREmH53E=; b=pXkx7yMtL7NsaydxclYddDxg90A9cyF8vqiIgg/BOyRq//a/ASHtc95Av4dRT9cgxo ksDp59HDPpcB+3GALehd4XfbE1Qrydjgag6ueBssJEnDyvNx9DbKCJYvm+6piL9wGrSl q4iU3S48a4gPvy+5kKeHLuyHsgIEY9kSJo12jE3R/Ywma173Y9JqWa7zAK/i9kk5SJl2 o8G1b62MluFr60cnDlNiqlyQNXMKV818g8/n38GUXkVbKkpsvmnGbu5Z0FbBfQqfJS/T yz2WhM2SFgqBw0bZLFVSotWw1zO64eoq3oOB/czJAMBmLpaAXOVwhNTTLF7CcRftNbV0 iP0A==
MIME-Version: 1.0
X-Received: by 10.152.36.65 with SMTP id o1mr15657709laj.55.1435599863948; Mon, 29 Jun 2015 10:44:23 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Mon, 29 Jun 2015 10:44:23 -0700 (PDT)
Date: Mon, 29 Jun 2015 13:44:23 -0400
X-Google-Sender-Auth: V9fW8lBX84tX7PoRfWaeM8JwKQc
Message-ID: <CAMm+LwiV76SDMeVjr11=Vjk44nr-LbBSe1AL6aZpq3h-B4Yzpw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: perpass <perpass@ietf.org>, "therightkey@ietf.org" <therightkey@ietf.org>, "saag@ietf.org" <saag@ietf.org>, endymail <endymail@ietf.org>
Content-Type: multipart/alternative; boundary="089e0158b6c2ee2ef90519aba349"
Archived-At: <http://mailarchive.ietf.org/arch/msg/endymail/SPbFy5Lddied7ciQSQzhf--W6Qo>
Subject: [Endymail] Modular Mathematical Mesh
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2015 17:44:27 -0000

Announcement only: Please direct followups to endymail

Draft at:
https://tools.ietf.org/html/draft-hallambaker-cryptomesh-00


After working on the problem of securing end-to-end email for quite some
time. I now have a scheme that really does meet my design goal of being
just as easy to use as regular mail.

If you are on a Windows box using Windows LiveMail (nee Outlook Express)
and you run the mesh profile manager it will automatically create and
register your S/MIME keys in the Mesh, apply for certificates and configure
your client to use them. The only thing the user has to do is to select
which accounts to enable for use with endymail. Once the keys are
registered, use is totally automatic.

If you then want to enable endymail on a second machine, all you have to do
is to go to that machine, run the profile manager, give it your account
name, request that it enable that machine, then go back to your first
machine (or another machine you have approved for admin access) and approve
the request. Job done.

Behind the scenes, the necessary private keys are being encrypted and
shared through the mesh. Unlike systems such as LastPass, the mesh is not a
trusted service, the keys used to exchange the configuration for endymail
in the public PKI (e.g. CA based, OpenPGP, something new) are managed using
a personal PKI.


There is some cleanup work to be done. The code does not support OpenPGP
yet but that is just a matter of some code. Getting the code so it will
work outside my lab is taking some time.

Before working on that, there is another, much more important problem to
solve - deployment. And to do that I need to think about deployment
engineering as a separate problem. The value of a scheme in which anyone
can send endymail is in the $billions ($1 per email recipient times 3
billion users ~= 300 billion). The current value my system adds to email is
$0 ($1 per email user times 0 recipients times 1 user).

And S/MIME and OpenPGP face the same problem. They have never achieved
critical mass and so all the potential of 'network effects' and 'viral
marketing' become the 'chicken and egg' problem.


So here is how I propose to address deployment. Endymail isn't very
valuable to the individual user until widely deployed. So instead provide a
system that addresses their biggest pain point - remembering the usernames
at all the 100s of Web sites they use that require username&passwords.
Remembering passwords is easy because you just use the same one everywhere.
Unless they have a password manager, that is.

Systems like LastPass have appeared to meet a real user need. But they
don't use end to end security and they aren't built on open, widely
reviewed standards. So the user is putting themselves in the hands of a
third party who demands way too much trust.


The mesh is designed be an untrusted service that can support secure
exchange of any sort of data through end to end encryption. It is sort of
like NNTP for cryptographic keys. To prevent abuse there will have to be
admission control or else we will have idiots trying to stream 4k video
over it. Denial of Service by people trying to wreck the mesh is a bigger
problem, any system that claims it can't be breached will have people
trying to attack it regardless of the fact that the breach claim only
covers confidentiality and integrity, not service.

In the short term that will probably mean requiring some form of proof of
work scheme so that the cost of an attack to an attacker is less than the
value. But once we get the email scheme built out, an introductions model
could offer the same degree of protection without the overhead.


Right now I am reworking the code and specs to make the scheme as
application neutral as possible and to stand up a test mesh.