Re: "secure Dropbox clone"

Phillip Hallam-Baker <> Fri, 08 November 2013 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9981011E8128 for <>; Fri, 8 Nov 2013 06:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tYuuuNyhQJwv for <>; Fri, 8 Nov 2013 06:29:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::234]) by (Postfix) with ESMTP id 28E5211E8153 for <>; Fri, 8 Nov 2013 06:29:23 -0800 (PST)
Received: by with SMTP id ev20so1783021lab.39 for <>; Fri, 08 Nov 2013 06:29:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id r10mr94340laj.48.1383920963154; Fri, 08 Nov 2013 06:29:23 -0800 (PST)
Received: by with HTTP; Fri, 8 Nov 2013 06:29:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 08 Nov 2013 06:29:23 -0800
Message-ID: <>
Subject: Re: "secure Dropbox clone"
From: Phillip Hallam-Baker <>
To: IETF <>
Content-Type: multipart/alternative; boundary="089e0160bb0467f92004eaab356b"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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