[messaging] Autocrypt 1.0

[Trevor Perrin]

On Fri, Dec 22, 2017 at 6:40 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
>
>> 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.

I guess, but since the goal of this mechanism is to support encrypted
threads, it seems odd that gossip messages OUTSIDE the thread affect
what happens inside it; and that gossiped keys INSIDE the thread bleed
out of it, and show up in other contexts (as "discourage" keys when
sending a new message; or get automatically used in other threads).

Could you not scope the keys gossiped within a thread to only be used
in that thread?


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

A trial/test period for Autocrypt makes sense, but I'm less convinced
that advertising "prefer-encrypt: nopreference", causing an
"available" UI mode, is the best way to do it.

Advertising "prefer-encrypt: nopreference" doesn't give the advertiser
control over whether to receive encrypted messages, it just makes it
discretionary for senders, for the next 35 days.  If lots of senders
always encrypt when "available", then you won't get much of a test
period.

Alternatively you could advertise an expiration time in an Autocrypt
header, by default set to 5 minutes after sending time.  This would
make it easy to test and turn off, and to scale up as you gain
confidence, without needing the "available" UI state.


Trevor