[messaging] Autocrypt 1.0

[Vincent Breitmoser]

Hey Trevor,

thanks for your feedback!

>  (1) The "discourage" UI recommendation seems confusing:
>   * It conflates two different cases (the recipient's key was last
> seen a while ago; the recipient's key was received via the unreliable
> "gossip" method).

I see your point. I think we didn't want to have too fine granularity
for these states, to keep the intention clear. The difference is mostly
in "why" something is happening, but not "what" is happening, i.e. it
will be a similar UI flow but maybe with different messages displayed to
the user.

(see below for more thoughts on gossip)

>   * If it's a bad idea to use this key, I'm not sure why you'd give
> the user the option to do so.

This is a tough one in terms of UX. If a key worked yesterday, straight
up disallowing the user to use it today might be irritating. It's very
unlikely the user will go through a (social) roundtrip to get a fresh
key, or just not send the message. This leads to a tradeoff between
sending plaintext, and risk of unreadable mail.

>   * The "discourage" recommendation gets overridden in the case that
> you're responding to an encrypted message to a group of recipients.
> Since this case doesn't change the fact that the key is old or was
> received via gossip, I'm not sure why it's OK to override "discourage"
> and use the key here.

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 (this happened multiple times even in our own
working group!). In a reply, the responsibility kind of chains back to
the first sender - using the same key that was used in the message being
replied to optimizes for consistency.

A scenario that actually gave us a hard time is replying to an encrypted
message, when the gossip key from that message differs from a
(non-stale) one we have locally. Do we encrypt to the gossip key? Or the
one we have? One of these choices will likely lead to unreadable mail,
either consistent with the original message, or consistent with other
encrypted messages sent to that recipient. The thought to include a
freshness criteria in gossip headers to improve this situation was
dropped because it leaks just too much metadata.

This is one of the places where we hope to offer better answers in the
future from experience after rollout.

> 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 you
have a good idea how to do this unilaterally, we'd be all ears.

It was important to us that clients have *some* well-defined method of
transferring secret keys, to avoid lock-in of generated secret keys. But
the complexity we can actually afford is just really low. We feared that
if we have a complicated method of transfer, clients might simply omit
it, reducing coherency of the ecosystem and user experience. In the
worst case they'll offer to just export to file, in which case the
chance of those keys ending up in the cloud is extremely high
(particularly on mobile clients).

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

>  (5) It's not clear what the "self signature" from master key over the
> user id accomplishes.

It achieves compliance with the OpenPGP spec and gnupg de facto standard :)

We actually considered 1) simply breaking the OpenPGP spec and drop this
packet or even user ids entirely, or 2) just going with something else
("25519 in json") entirely.

But legacy is important. We want to pick up people where they are, by
providing relief from known pain points (e.g. manual key search and
group reply) while allowing them to stick to their toolchain, get a foot
on the ground and then work from there. From the autocrypt perspective,
User IDs are purely decorative, and we really don't have a good idea
what to put in there (address?  UUIDs?  fixed string?), so we decided to
stick to a way that is compatible with existing software, e.g.
`gpg --list-public-keys user at domain.example`.

That said, onboarding for new users should ideally be as free of this
baggage as possible.

Thanks again for your feedback :)

 - V