[messaging] RFC: (n+1)sec secure group chat - security properties and UX design

[Ruud Koolen]

Thanks for the comments, Ximin.

On Monday 12 September 2016 19:25:00 Ximin Luo wrote:
> Ruud Koolen:
> > [..]
> > security without sacrificing too much usability, and thus to avoid
> > designing a beautiful system that nobody will use because of its
> > complexity. [..]
>
> I think these types of remarks are logical fallacies that harm security
> research and the internet freedom community.
>
> 1. A beautiful system is simple (for what it achieves), not complex. I'm
> not sure why you imply that a beautiful system would be complex. Do you
> have a concrete example in mind? Also, history has shown that beautiful
> systems are worthy goals to pursue, even if specific reasons are not clear
> initially.

I fully agree. Let me rephrase, then: I want to avoid designing a system that 
accomplishes excellent security properties from a mathematical standpoint at 
the cost of unwieldy complexity.

> 2. Good "usable security" work, is to hide complex achievements
> (implementations, security properties) behind simple interfaces (either
> APIs or UIs). Many people use WebRTC because its API is relatively simple,
> but its internal protocols (such as ICE NAT traversal) are very complex in
> absolute terms. (And as in (1) I'd argue it's *relatively* quite simple,
> given what it achieves.)

That is my ideal as well, and this is exactly the form us usable security that 
I have been aiming for here. My goal for the (n+1)sec system is to design a 
system that can support such a simple interface. Unfortunately, this is not a 
given; if the security properties guaranteed by a protocol are subtle, the 
interface must be rich (and thus, complex) enough to represent that subtlety. 
This applies in particular to the participant-state discussion, below.

> > To this end, we have written a specification [3]
>
> Specific comments regarding your document:
>
> In chapter 3, you should mention which types of attack your security
> properties should be preserved under.

Good point. I tried to approximately describe this, but in hindsight the API 
documentation should specify this in formal detail. I will add this to the 
API specification.

> I'd argue that distinguishing between the 4 states is an internal
> implementation detail that you don't need to expose externally. As a
> participant, I only care who can read messages in the session. I don't care
> if "they could hypothetically send to me"; I only care when I actually
> *get* messages, and then I already know who sent them.

I disagree. These four states are explicitly part of the interface that a UI 
may (or may not) want to display.

The distinction between authenticated and unauthenticated participants is one 
that is relevant for a user interface. The user interface should be able to 
display the fact that a user is not yet accepted by all participants, and in 
particular display the exact list of participants that have yet to accept a 
newcomer. If Alice is the only current participant that has yet to accept 
newcomer Charlie, other participants should be able to complain at Alice.

As for authenticated participants, different security properties apply to the 
three different states that such participants can be in, and a sufficiently 
paranoid user interface may want to distinguish between these states. When an 
authenticated member is Joining but not yet Active, they are not yet reliably 
able to receive channel messages; but channel messages are not reliably 
*secret* from those participants either. Colloquially, the moment where an 
unauthenticated participant Alice reaches the Joining state is the point 
where participants should stop discussing topics that should remain secret 
from Alice, and the moment where reaches the Active state is the point where 
participants can start talking to Alice.

Certainly this last distinction in particular is one that many "casual" 
clients may wish to hide from the user. But it is also one that the more 
paranoid type of client may very well wish to make explicit, which requires 
it to be part of the API.

For obvious reasons, the same distinction applies in reverse for the 
distinction between Active and Leaving members.

> In chapter 4, you're missing discussion on what happens during ordinary
> transport failures.

I agree that chapter 4 is far too light on this issue. The topic is mentioned 
to some degree, but it deserves a considerably more in-depth coverage. I 
shall remedy this in the next iteration of the document.

> This has been one of my previous criticisms of np1sec's general approach,
> that it would fail too often in ordinary attackerless conditions.

I fully agree. Indeed, this concern has been the main motivation for this 
revision of the (n+1)sec protocol. The ambition is that the new protocol (for 
which I hope to publish a proper specification Real Soon Now (tm)) remedies 
these shortcomings.

> "Because client agreement is an equivalence relation" - this is not true in
> the normal human intuitive interpretation of what "agreement" means. Your
> protocol might achieve "for a fixed T, each participant will either verify
> T is the history, or fail this verification". However, it is not possible
> to achieve "Alice believes T is the history, if and only if Bob believes T
> is the history" - the attacker can just drop the last packet Alice sends to
> Bob (or whatever). Any protocol is susceptible to this; it is what makes
> the byzantine consensus problem hard.

I wondered whether this phrasing was clear enough. Apparently it is not.

The property the protocol achieves is that, if Alice and Bob ever come to 
disagree about a piece of history of the channel, the channel wil split into 
at least two disjoint chunks containing Alice and Bob, respectively. A 
certain bounded amount of time may pass before this split happens, or it may 
happen immediately when an inconsistency is detected; parties sending invalid 
communications will generally trigger an immediate channel split, but when 
messages are selectively dropped, a timeout mechanism will eventually cause a 
split to happen.

This timeout aspect avoids the Byzantine consensus problem, for a weaker form 
of Byzantine consensus problem is *not* impossible when time delays are 
acceptable. In particular, the property "if Alice believes T is the history, 
then either Bob believes T is the history, or Alice will consider Bob 
timed-out-with-unknown-status after a certain time interval" can be achieved.

> More generally, I think that chapter 4's arguments are neither precise nor
> exhaustive.

I fear that you are right. I will try to provide a more exact coverage of the 
consistency properties based on a formal description of the attacker model.

> I don't think it's possible to provide a precise and exhaustive argument
> from np1sec's current design; the reasoning needed would be too complex.
> However, simpler reasoning is possible, if you divide up the internal
> protocol design into several layered concerns that each achieve distinct
> security properties. These components would also then be reusable for future
> other protocols, as well as being easier to reason about. 

I may not have been clear enough about this, but the security properties 
described in the conceptual API specification do not apply to the present 
iteration of the (n+1)sec protocol specification. Rather, it describes the 
design goal of a new version of the (n+1)sec protocol that we are working on.

-- Ruud