New section with Verified group and onion-key verify protocols

[hpk42]

new section which talks about active attack mitigation through introducing new UI flows and messages

• fleshed out "verified group" protocol
• contains the mostly unchanged onion-key verify protocol
• also fixes to the Makefile, authors, and boilerplate
• bump the doc version to 0.8

[r10s]

some minor comments:

• I think steps 1.-6. (without 7.-9.) can also be used for "securing" a normal 1:1 chat. Maybe this should be mentioned somewhere.
• Asynchrony might also be useful when several joiners scan the inviter's QR code the at the same time. This might be a very common situation when a number of people in the same room want to join the same group.

[azul]

@hpk42 Your changes address the attack scenario i was describing.

I have two remarks that could be addressed now or after a merge.

• [x] The statement 'You are under attack by your provider' in Step 5a. is scary and we do not have conclusive evidence for it at that point:
  • Maybe it's not bobs provider but alices provider.
  • Maybe it's someone who got hold of bobs password and is altering the imap folder from a different device.
  • Maybe it's just a different email address then expected because of strange thing changing the from address.
• [ ] We should have a notion of Autocrypt Keys locked to a verified state (maybe i just overread it). Otherwise later Autocrypt headers might still replace keys. We should lock the key the moment oob verification succeeds (i.e. in 5) - otherwise a crafted message in the Inbox that alters Alices key after the verification but before the delivery could be imagined.

Sorry for nitpicking. Trying to make sure we specify precisely so implementers have good advice. And if the provider is the attacker we have a pretty powerful attacker in that it can observe our access to the mailbox and alter it.

[hpk42]

i think the "locked autocrypt key" is an independent issue IMHO. As soon as the AC key changes you are out of the group -- but other (non-secure-verified) chats remain operable under normal autocrypt semantics.

[azul]

@hpk42 - I was thinking about the situation where i see a new autocrypt key for someone whom i am also sharing a group with.

Autocrypt so far uses the last key seen. I'm fine with locking the keys only for the group - so people who have new keys but performed no oob cannot read the group mails anymore. That kind of makes sense. But I have not seen this spelled out in a way i would be confident it gets implemented correctly.

Basically what each client needs to do per group is keep a list of (recipient address, key fingerprint) pairs. This list gets updated through the notifications about new or removed keys to the entire group.