[messaging] Autocrypt 1.0

[Daniel Kahn Gillmor]

Hi Trevor--

Thanks for your review of the Autocrypt Level 1 spec!

I completely agree with you on the goal of better multi-device
interaction, and i expect that to be one of the main focuses of the next
revision of the spec.  We're hoping that Level 1 will be easy enough to
implement that we can get many different MUA developers onboard, so that
we can have a decent-sized cohort that can move to the next level.

On Fri 2017-12-22 17:29:06 +0000, Trevor Perrin wrote:
> But the gossip mechanism isn't aware of replies, it accepts gossiped
> keys from anyone.

We've discussed having the gossip mechanism only kick in when a reply is
in action, but for Level 1 it's simpler to keep the key evaluation on a
per-message basis (some message composition interfaces can't easily
remember whether they're replying to a message or not, once they've been
invoked).

> Example:  A group of users are in an email thread.  They are all able
> to send encrypted replies to each other, because all keys have been
> gossiped within the thread.  Now a malicious user OUTSIDE the group
> sends a message to a user INSIDE the group, gossiping incorrect keys
> for the group users.  The recipient of this message will accept and
> use the incorrect gossiped keys for group replies, thus sending
> unreadable messages.

yes, this is a risk of the current design.  However, it's not fatal, and
there's a pretty natural recovery from it: as soon as one member of the
group receives an unreadable mail, they can reply to the group
(e.g. saying "wtf i can't read this!").  At that point, the entire group
will get a direct (non-gossip) key from the person in question, which
puts them out of reach of any malicious gossiper.

> Stepping back, I'd worry about the "available" and "discourage" states
> confusing users.  In particular, "discourage" will appear due to
> different and hard-to-understand reasons, and will sometimes get
> overridden (in encrypted replies), so sometimes Autocrypt will want to
> automatically encrypt to a "discourage" recipient and sometimes not,
> depending on the reply context and gossip history.
>
> The simplest design would have Autocrypt automatically encrypt if it's
> received a recent Autocrypt header from all recipients, with no
> concept of replies, "prefer-encrypt" policies, or gossip.  I'm unsure
> these add enough value to justify the UI complexity.

This is certainly a simpler design!  The problem with it is that it
means a user has to fully opt into Autocrypt to even experiment with it.
That is, if i decide to experiment with an Autocrypt-enabled mail
program, everyone else will *always* send me encrypted mail all the
time.  this makes my other mail programs (which might not yet be
autocrypt-enabled) really frustrating to use because many messages will
now be unreadable there.

The concern is that this kind of pain point will keep people from even
experimenting with Autocrypt.  We don't want the zeitgeist to be "don't
try out anything that is Autocrypt-enabled, because it will break the
other ways you use e-mail".

This is maddeningly conservative to some of us who've been involved in
the project, but i've worked with many people who feel burned in a very
similar way by having once set up OpenPGP and then discovered it didn't
work for them at the most inconvenient of times.

The goal in the short-term here is to flood-fill key discovery, to
*enable* encryption, not to enforce encryption on every message.

> If both devices are present, I'm not sure why a roundtrip is that
> hard, or why you couldn't just enter (or scan) a public key from the
> recipient device into the source device, before sending the setup
> message.
>
> At minimum you'll need to advise users to be very careful with the
> secret code, since there's a fragile combination of design choices
> here (no forward secrecy; user-visible secret "code" that decrypts the
> private key).

Agreed, tools should encourage the user to treat the secret code with as
much caution as they would treat the most sensitive message they ever
send.

> It seems like striving for backwards-compatibility here makes the
> design significantly worse (adding several KB to every message would
> be a real cost if this was deployed at large scale, and on mobile
> devices).

I look forward to reducing this overhead when the toolkits people have
actively integrated into their MUAs already better support the modern
crypto.  We're not there yet, unfortunately, but I hope we will be soon
:)

And while the cost isn't insignificant, many MTAs add comparable amounts
of data to every e-mail message already (hello DKIM signatures and
MS Exchange Diagnostics and Forefront Antispam!)

> I'm not even sure how much backwards compatibility you're achieving?
>
> If you want to support the existing PGP userbase, don't lots of PGP
> users have keys which aren't 2048 or 3072 RSA, thus couldn't use
> Autocrypt?

Most active PGP e-mail users i interact with actually do have either
2048-bit or 3072-bit RSA keys, since one or the other has been the
default key generation for many implementations for years.  Existing PGP
users can still encrypt messages to their Autocrypt-using peers.  MTAs
that support PGP today can trivially add outbound Autocrypt headers that
match, and (with a bit more work) treat incoming messages as a new
source of peer certificates.

Anyone who is working on an MUA should look at Level 1 as a relatively
straightforward implementation step.  And it's also a stepping stone to
even better future mechanisms, as Trevor suggests.  If you work on an
MUA, please join the discussion over on the Autocrypt mailing list and
let us know what is working for you and what you think the next steps
should be.

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171222/7be67ae0/attachment.sig>