Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Asyncronous secure messaging (Email): Why reinvent the wheel?

Fabio Pietrosanti (naif) lists at infosecurity.ch
Sat Nov 9 14:51:07 PST 2013


Il 11/9/13 11:29 PM, Tony Arcieri ha scritto:
>
>     Please, think to use that pile of standards and think to approach
>     email
>     security by improving those one.
>
>
> It would be irresponsible not to. There is a fine line to be walked
> between improving the user experience and building upon existing work.
> So far most attempts I've seen at improving the situation have
> sacrificed security for convenience. I don't think this needs to be
> the case. Perhaps some day I'll release some software which provides
> both. Working on it ;)

The design of a security system, would in that case also specify the
user interactions and interface behaviour for all actions of
authentication and key management.
In ZRTP there's also some definition on how the "security procedures"
within the respect to the user should be properly handled.

So a standard should start working on proper key management based on
existing ones, with semi-automated procedures including all the
user-interface interactions required.

If there is the need to extend some kind of signaling procedures, by
safeguarding SMTP protocol infrastructure and interoperability, those
should be done by using extension to existing data formats (like MIME
and MIME Objects).

If there is the need to protect metadata, some cryptographical solution
has to be defined, possibly by re-using existing RFC protocol stack for
key exchange, and data format for storage of those data should be
defined with some existing used extensions (it may use SMTP Headers
metadata data, to embedd encrypted metadata).

I don't have a solution in my hands as it would require some hard
protocol and crypto brainstorming job and proper community review-process.

However i really think that this should be the way to do it, and if Dark
Mail is trying to do something like that, they should drop out an IETF's
standards based internet-draft and subject it to public review and
discussion ASAP.

-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20131109/43e11b38/attachment.html>


More information about the liberationtech mailing list