Clarify onion-queries

[azul]

The onion query approach is different from what we do in the verified groups section: In a verified group all changes of keys (adding, updating, removing) are announced to the whole group. This ensures a consistent use of keys except for race conditions. The downside of this is that key updates after device loss require oob verification to arrive to the group.

The onion queries approach refers to a more flexible kind of group. One in which every user uses the keys they saw from other sources. That's where the privacy issues and inconsistencies come from. onion queries as i understand them are basically an alternative to gossip rather than an extension to verified groups.

Maybe we should use a different term than group here to avoid confusion (thread, conversation come to my mind). Or we clarify in the beginning that this is an alternative approach for opportunistic encryption. Maybe move it to the consistency section?

@carmelatroncoso @gdanezis, what do you think?

[carmelatroncoso]

I think we are referring to the same group... or maybe to an old version of the verified group.

The question is what goes in the gossip headers, i.e., how are updates communicated. If everybody sends their views of everybody's keys all the time to ensure consistency, then you have the privacy problem. This is orthogonal to the oob to arrive to the group.

The onion query helps avoiding this everybody broadcasts their view, by making concrete queries. If there is no need to make the broadcast, then the onion queries are not needed either.

[azul]

My understanding is that verified groups will only explicitly update keys when one user sends a message that a new key was added, removed or updated.

Autocrypt normally prefers directly received keys over gossip. However in verified groups the verified and announced key should be prefered over the directly received ones.

So yes. From my point of view verified groups do not need gossip or onion queries.

[carmelatroncoso]

Ok, that is different from what we were talking about when we were in Lausanne. In this case, there is no danger at all, nor risk of the provider running a MITM during the group life (no key updates), nor risk of leakage regarding latest contact with among users.

You could still sell the onion query as a way of user's verifying directly with the newly added user (or control way if you add key update), but that is it.

We can make also it a part of the deliverable but not of the document you will publish.

[azul]

@carmelatroncoso I see two use cases for the onion queries... 1) verifying plain gossip. In the absence of verified groups Autocrypt gossip does not have any of the guarantees. So if i see someone gossiping a key that is inconstent with my own assumptions it would be interesting to accomplish key consistency again. 2) verified group updates. We are still discussing what to do in case of conflicting key information in verified groups. See my latest comments in #46 for a possible scenario. In that scenario Alice would learn about a new key of Bob because Claire announces it to the group. Maybe we can use onion queries to confirm the new key with Bob.

For 1) I was suggesting moving the queries out of the chapter with verified groups to reduce the confusion between two types of groups. 2) I have not thought through at all yet.

For some time i tried to construct an algorithm that would allow deciding between conflicting keys. However now my understanding is that in the case of device loss and thus loss of the original key material the best we can achieve is consistency. That is force a possible attacker to lie to everyone about Alices new keys. If Bob is the only person who (claims to have) performed a verification and they conspire with the attacker we are lost.