[Autocrypt] autocrypt comments

Ángel angel at 16bits.net
Wed Dec 20 20:01:31 EST 2017

Hello all

I only discovered about this initiative a few hours ago, from a message
on a different mailing list, so the following is a not-too-organised
dump of comments and thoughts after knowing about autocrypt.

First of all, I have to agree with Jan Simon regarding the website. I
guess the questions I had when I got there were "What is this? What are
they doing?" I shouldn't have to read the spec for that (the spec itself
is relatively simple, but still).

About the specification:
When reading it with no previous knowledge, I found that it starts
defining variables and algorithms, that only later you can put into
place. Some introductory text would be nice.

I found myself thinking about a number of impersonation issues while
reading, like 'Wait, they are just replacing the previous key with a new
one?' and then, I found the section about Gossip headers, which allow
providing the keys of _other_ users. :(
(directly received ones have priority, though)

Yes, those are active attacks. But even if not being really resistant to
active attacks, the spec could help avoid some shortcomings.

The MUA SHOULD allow logging the key changes, so that if there was an
attack, it could be detected later.

Mention in the Gossip section that keys received directly from the user
have priority over gossip keys (it's already implicit in the earlier
algorithm, but at that point you don't know what they are).

When dealing with BCC, mention how the PGP encryption could be leaking
those recipients, so that implementers can prefer to send a single mail
to them (or at least, could use --hidden-recipient).

Clarify what should be done with an Autocrypt-Gossip header not in an
encrypted email.
It makes sense to ignore it, since "an Autocrypt-Gossip header SHOULD
NOT be added outside an encrypted MIME part." it shouldn't appear
otherwise. That also means that only autocrypt emails could load data
there (an email intended to pollute your gossip db disguised as a normal
spam would not work, it would need to be an autocrypt spam email).

OTOH, I see how it would make sense for a cleartext email to use a
gossip to communicate the key of its reply-to address.
At least, I would like that the gossips are signed somehow before being
accepted, so you could blame some key (even if ephemeral).

Something that I thought of when the specification was what was being
done with the subject. It is an important missing point in the openpgp
model. Including that with support for a new spec like this seemed the
perfect fit. (I have later seen the September thread about
memoryhole/protected headers)

Of course, there's the issue of verifying the other side of the
conversation. autocrypt is similar to a TOFU approach, except that the
recipient key can change at any time (so, why are messages signed?).
As a user, I would be interested in knowing that the six-months-old key
used by the other side was changed to a new one first-seen yesterday,
and then changed back. Given the random access nature of a mailbox, this
seems tricky without tracking all keys seen.

Defining key rotation is obviously an issue, although specifying that
can be left for next version.

As you are using RFC 2119 keywords, add the paragraph mentioned on 

A recommendation for clients also compatible with usual PGP would be
nice. I guess they will find themselves having to decide if a message
should be treated as a pgp or autocrypt one.

Best regards

More information about the Autocrypt mailing list