[messaging] Autocrypt 1.0

[Trevor Perrin]

On Fri, Dec 22, 2017 at 11:30 AM, Vincent Breitmoser
<look at my.amazin.horse> wrote:
>
> The main purpose of gossip is to ensure that replies to encrypted emails
> are always possible, regardless of recipients and previously known keys.
> It's a very common situation currently that a first mail to a group of
> people is encrypted, and the first reply drops to plaintext because of
> missing public keys

That motivation makes sense (handling encrypted replies to multiple
recipients, if you didn't previously have the key of those
recipients).

But the gossip mechanism isn't aware of replies, it accepts gossiped
keys from anyone.

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.

---

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.


>> There are safer possibilities for synchronizing private keys, such as
>> encrypting to a public key from the recipient device, or using a
>> "short authentication string" to authenticate a DH exchange between
>> the source and recipient devices.
>
> We're aware, and we thought through these options. However, anything SAS
> (or generally DH) based requires a communication roundtrip between
> clients, and that is actually really hard to do between MUAs.

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).


>>  (4) It looks like every message sent by an Autocrypt-supporting mail
>> client will contain >2 KB to advertise the sender's keys (two RSA-3072
>> public keys, two signatures).  If you're sending to multiple
>> recipients and you know some of them support Autocrypt, there will be
>> an additional >2 KB for each such recipient to "gossip" their info.
>
> That's correct, and we are of course aware of the dramatic gains in size
> from using ECC keys.  But so far, OpenPGP implementations kind of aren't
> there yet :(
>
> Once they are, we'll be happy to upgrade. Until then, we decided that
> something like 10kb are an overhead we're willing to accept.

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'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?

If the concern is compatibility with existing libraries like
libgcrypt, I'd question the motivation, since there are plenty of
(probably better) crypto libraries.

Trevor