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/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
