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

[Ximin Luo]

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.

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.)

> 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.

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.

In chapter 4, you're missing discussion on what happens during ordinary transport failures. This has been one of my previous criticisms of np1sec's general approach, that it would fail too often in ordinary attackerless conditions.

"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.

More generally, I think that chapter 4's arguments are neither precise nor exhaustive. 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.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160912/c72f0027/attachment.sig>