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 _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
