Re: "secure Dropbox clone"

Phillip Hallam-Baker <hallam@gmail.com> Fri, 08 November 2013 14:29 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9981011E8128 for <ietf@ietfa.amsl.com>; Fri, 8 Nov 2013 06:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level:
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 tYuuuNyhQJwv for <ietf@ietfa.amsl.com>; Fri, 8 Nov 2013 06:29:27 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 28E5211E8153 for <ietf@ietf.org>; Fri, 8 Nov 2013 06:29:23 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id ev20so1783021lab.39 for <ietf@ietf.org>; Fri, 08 Nov 2013 06:29:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6grj59qnMmj4XvyIF7PUk82Ts9vsKC3/IfL1JxD7vAg=; b=uMmn6Ng0VrAxwdh+7TXf8d7UuZHbvFJYBI3rowDFKItOzJBwTQWM7/8dO6EjA3W+Vn HDbjq0JF2JO4JGelVwTuTtcbJm1pycATwTuuirCKyhcVhLxvzGdf6Vip+TY4Epm8SMN5 wC+YBGusQQXRWsWmfEAxkYyxinSbET84B2g9gNOVyDWlvvko7EkBKkQhTyo5d7leXWOG U8A2/Xx4omk5iHfFvDxMsBFq6oPaAb8HxhVVSSVQwOvDeI46BRbcWw9z+Yr/cB/ryrUR 1gty3I5glpTA7pp2unHzbkiQ01X/oAIJFboeCfTitD/L2qh3AtccpMonJGYd69JKhOAb kp+g==
MIME-Version: 1.0
X-Received: by 10.152.36.170 with SMTP id r10mr94340laj.48.1383920963154; Fri, 08 Nov 2013 06:29:23 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Fri, 8 Nov 2013 06:29:23 -0800 (PST)
In-Reply-To: <527B918F.2030000@firsthand.net>
References: <D1A50FE6-2A1E-47C9-A440-3A0655B9E188@isoc.org> <50B4387E-8E32-4E73-91F8-44268C5F5865@vigilsec.com> <559FCA81-CC65-437D-AD91-6693E219A991@netapp.com> <527B918F.2030000@firsthand.net>
Date: Fri, 8 Nov 2013 06:29:23 -0800
Message-ID: <CAMm+Lwj-yd=XrWv9tQDxmOGY07_1GCHsHSbtN6BeF-0Dj5YMCA@mail.gmail.com>
Subject: Re: "secure Dropbox clone"
From: Phillip Hallam-Baker <hallam@gmail.com>
To: IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary=089e0160bb0467f92004eaab356b
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2013 14:29:27 -0000

The IETF is the wrong place to go about design, so here goes.


It seems to me that S/MIME already has the functionality of a dropbox
scheme. What is lacking is what the usability folk call the 'affordance' of
being used in a dropbox fashion and well, usability.

Further, for such a scheme to become widely used it will be better if the
scheme is a protocol that can be supported by existing service providers as
an extension to their current offerings rather than a completely new scheme
that attempts to disintermediate them.


There are two separable forms of authentication required in such a scheme.
First we have the the access controls to the remote mailbox, second we have
the cryptographic controls on the data. My bits may b encrypted but that
does not mean that I want just anyone to view them. And even encrypted bits
typically leak some metadata.

* The recipient will need a public key against which senders can encrypt
their data.

* Senders will require a mechanism that assures them they are using the
correct key. If the parties know each other, a 'strong email address' would
be sufficient, that is a fingerprint of the public key combined with the
destination email address. If the parties do not know each other, a Trusted
Third Party (or parties) will be required to provide an introduction.

* The mailbox provider can map the key identifier to the public key if
necessary.