Subject: [perpass] Secure Dropbox is Secure Email

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Nov 2013 04:52:16 -0800

I was thinking about the secure Dropbox type application last night.

Two thoughts:

1) Dropbox is really a messaging protocol only the inbound and outbound
server is the same and without all the MIME encoding nonsense required to
get through legacy mail systems.

2) Adding flood fill routing and breaking messages into constant size
chunks makes it possible to avoid traffic analysis. Though this will
inevitably have a cost impact in higher bandwidth and longer latency.
People who want their messages to be untraceable are probably going to have
to accept that it might take some days for a message to arrive at the
intended destination.

I am rather skeptical of application layer traffic analysis protection but
would not want to foreclose the option.

The realization that Dropbox is only a variation of mail is interesting as
it suggests that rather than building a separate protocol it would be
better to consider a next generation email protocol that is capable of
handling large attachments.

The main requirement for handling large attachments would be that the
attachment is posted to the outbound mail server and is fetched by the end
receiver after they decide to accept it.

In addition we would want to require end to end encryption and signature
(for spam control). The ability to restart transfers that were previously
aborted in mid session would also be useful.

-- 
Website: http://hallambaker.com/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Nov 2013 10:59:54 +0000

On 13/11/2013 12:52, Phillip Hallam-Baker wrote:
  [...]
> In addition we would want to require end to end encryption and 
> signature (for spam control). The ability to restart transfers that 
> were previously aborted in mid session would also be useful.
Coincidently this was already done for SMTP: 
http://www.rfc-editor.org/rfc/rfc1845.txt. I even implemented it in 1999.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 09:29:46 -0500

> http://www.rfc-editor.org/rfc/rfc1845.txt. I even implemented it in 1999.

It is one of the few HTTP protocol extensions I see value in.

The other area that could be fixed in a new protocol would be to provide a
mechanism that allowed gateways to add disclaimers to messages without
breaking the message signature.