[messaging] RFC: (n+1)sec secure group chat - security properties and UX design
ruud at equalit.ie
Tue Oct 11 17:28:55 PDT 2016
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
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 
> 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
> 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
> "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
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.
More information about the Messaging