[messaging] evolving Autocrypt effort: e-mail encryption for everyone

Fri Dec 23 07:30:48 PST 2016

I really don't want to appear to be running the proposal down. I think that
putting fingerprints of keys in email headers is a really good idea. I
proposed it at a SAAG three years ago.

I am not wanting to say 'my idea' here but some of you know I have been
working on this area. I might not have the answer but I do have a map with
bits labelled 'there be dragons'.

Modifying email clients is one approach. Redirect through a mail server
proxy with SMTP/IMAP support is another. In the short term a proxy is the
approach I have been looking at as it can support any client. I have a very
primitive prototype for SMTP.

The problem I came up with in trying to make it work is that people want to
be able to read their email on more than one device. So solving the trust
issue alone isn't enough. It is also necessary to solve the key
distribution problem which is what I have been working on the past two
years.

The other thing I came up with as a refinement of the idea is 'strong
email addresses'. The scheme I proposed at SAAG is not ideal. In response
to objections from DNS folk, Paul Hoffman and others, I now have a DNS
address format that contains a fingerprint:

alice at example.com.mm-MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

Try to send email to that address through an unaware email server and it
will simply bounce back. So this is an email address that you can use to
force the use of encryption and get 'send secure or not at all' semantics.

One lesson I learned from TimBL and the Web is that 404 not found is
genius. That fingerprint might or might not map to a security policy you
can resolve. And that is OK. If you can't resolve the security policy, you
can't use the address properly. You can guess but you will probably fail.
And that is OK because you might not have the security policy because the
address isn't meant for you.

The reason that I designed the UDF fingerprint format the way I did was so
that I can support different security policy semantics. So for example we
might have the fingerprint of a DNS root key and key through DANE or we
might have a PKIX rood and do S/MIME.

For email, there are cases where I want to use disposable addresses and
other cases where I want the fingerprint to be permanent.

The other relevant technical capability I came across while doing this work
is proxy re-encryption which is very powerful. I am currently working on
end-to-end encrypted Web. As in, the pages on the Web server are encrypted
and even though there is a key server, you can put Robert Snowden in charge
of both and he can't decrypt anything.

All my code is MIT license. (Some) Details are at

http://prismproof.org/

I am currently developing in C# but the protocol compiler I am using can
also target C.

On Thu, Dec 22, 2016 at 6:04 PM, holger krekel <holger at merlinux.eu> wrote:

>
> Since last Sunday there is a new e-mail encryption effort called
> Autocrypt. It is an evolving project, with the general aim to replace
> cleartext mail with encrypted mail. The effort focuses on opportunistic
> approaches, convenience, incremental deployability, interoperability,
> and well-thought-out (and minimal) user experience.
>
> The project was born during the Automatic Mail Encryption meetup last
> week in Berlin.  Around 20 people (MUA developers, researchers and
> encryption enthusiasts) worked for 5 days in several sessions, hacking
> activities and plenaries and happily agreed to continue the effort. Here
> is a list of features which distinguish it from previous efforts:
>
>     https://autocrypt.readthedocs.io/en/latest/features.html
>
> You'll see that early 2017 we'd like to settle on what we call "Level 0"
> support, i.e. support for mail encryption on a single app.  There is
> active development in Enigmail, K-9 Mail, Mailpile, Bitmask and a
> reference bot implementation to get to a first fully Level 0 compliant
> implementation.
>
> Autocrypt "Level 1" will include, among other things, multi-device
> support; we made good progress on that during the meeting, but decided
> incremental adoption will be easier if we start simpler.  And you don't
> even want to know what crazy things people have proposed for "Level 2" :P
>
> The overall index of docs (some very drafty still) can be found here:
>
>     https://autocrypt.readthedocs.io/en/latest/index.html
>
> If you'd like to help, have questions or comments you
> don't need to tweet about it but rather join us here:
>
>     https://lists.mayfirst.org/mailman/listinfo/autocrypt
>     #autocrypt on freenode or #autocrypt:matrix.org[1]
>
> As to meetings and further sessions, likely something will
> happen at: 33c3, RWC, IFF and lastly we plan for another
> fun multi-day meetup April/May 2017.
>
> so much, enjoy the rest of the year!
> holger, dkg and Vincent
>
>
> [1]: https://riot.im/app/#/room/#autocrypt:matrix.org
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20161223/c909b9d6/attachment.html>