[messaging] Autocrypt 1.0

[Trevor Perrin]

On Thu, Dec 21, 2017 at 9:46 PM, Vincent Breitmoser
<look at my.amazin.horse> wrote:
> Hey folks,
>
> good tidings we bring, to you and your kin: The Autocrypt 1.0 spec was
> released today!
>
> See https://autocrypt.org


Hi Vincent, autocrypt folks,

Congrats on getting this out!  Of course, now that you've finalized
the spec people will start sending comments, so here's mine....


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


 (2) The "gossip" technique seems risky, since a malicious Alice could
send a message to Bob that affects how Bob communicates with Charlie.

You've taken care that gossiped keys are superceded by "real" keys
received from Charlie, so I guess the risk is only denial-of-service:
Alice gossips a bad key for Charlie, causing Bob to send undecryptable
messages if Bob's "discourage" recommendation gets overriden (either
manually or because Bob is replying to an encrypted group message).
But that still seems like a risk.


 (3) For synchronizing private keys across devices, the user is given
a "setup code" for safekeeping, and it seems users will be encouraged
to write these down.  If the setup code is observed by an attacker, it
can be used to decrypt the setup message in the user's mailbox to get
the user's private key.  Without forward secrecy this is particularly
damaging, as that key could decrypt all messages the user has sent or
received.

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.  With these methods only public info
is displayed to the user, so if someone snaps a picture over the
user's shoulder this doesn't compromise all their messages.


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

Using Curve25519 instead of RSA-3072 would be 8x smaller.  (Your FAQ
[1] lists the RSA vs ECC comparison as 2350 vs 500 bytes, maybe that's
considering a different curve or uncompressed points?).


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

I guess it's to prevent an "identity binding" / "unknown key share"
issue where I advertise someone else's master public key, then forward
encrypted messages which they incorrectly assume were intended for
them.  But the self-signature doesn't prevent me from signing and
advertising someone else's subkey.  If you addressed that by having
each encrypted message securely identify the intended recipient (maybe
via the "memoryhole" extension to PGP?) then the self-signature might
be unnecessary.


Trevor

[1] https://autocrypt.org/faq.html