Two weeks ago we met in Prague to discuss how we should think about creating a protocol. Whether we should do so at all, and if we do it, what this would imply in terms of efforts. You can read the meeting notes here.
What would a “Status protocol” be? From my point of view: essentially a reflection of our principles but in code. More precisely, as a family of protocols (a set of a set of rules to achieve certain properties). There’s a real lack of rigorous successful security-oriented communication protocols out there. The ones that exist, generally don’t build on or with something like Ethereum. There’s an amazing opportunity here if we do things right.
A few examples of successful protocols:
- TCP/IP with application protocols like HTTP, enabling the web as we know it today
- BitTorrent which enables a plethora of different client implementations
- Of course, Bitcoin and Ethereum with their associated protocols
Progress last two weeks
1. A Status protocol proposal draft was written.
This may be extended to something closer to Nimbus proposal, either before or as part of initial team formation. We also need a better name.
2. Initial early research.
An attempt to become more aware of blindspots, and get a better understanding of the field as a whole. This is a work in progress, and ensure we aren’t myopic and learn from the decades of work and thousands of man years that has gone into the fields of secure/anon/censorship-resistance communication. See protocol reading laundry list for primary artifact of this effort.
Some exciting highlights:
- SoK Messaging - see breaking apart problem below
- Onion Routing vs Mix Networks breakdown aha moment in terms of fundamental difference (bifurcation from Chaum '81 paper in terms of anonymity research afaict)
- Loopix - mix network with better security guarantees than Tor, while still having a low latency
- The existence of Delay-tolerant Networking as a tool for censorship-resistance/sneakernet
- Briar’s beautiful problem decomposition - BTP/BSP/BQP
- Douglas Comer on protocol layering - worth thinking more about.
This effort will be continued, along with write-ups of more precise problem statements and requirements. See section below for a start.
3. Very early team scoping.
As Gmbh and Core is being restructured, right now the only person who is dedicated to this effort right now is Oskar. There are also some in-house expertise at Status that can be leveraged, but there’s a clear need for experts in this field. These are people who have designed open, battle-tested, p2p protocols, as well as people who take part in security research, or been part of RFC efforts.
A very rough list of individuals/projects worth reaching out to has been started here.
This work will continue over the coming weeks, by seeding candidate list and work with talent team to figure out how to best approach these.
Breaking apart the problem, somewhat
One of the most important things in this effort is to break down a set of problems into separate layers/efforts/protocols, that each deal with their specific subproblems. This simplifies the design, makes it easier to understand, more robust, and generally aids mental clarity.
Having clear separation of concerns enables us to attack the problem(s) separately, independently and in parallel.
Aside from classical protocol layering (see RFC793 - TCP and Comer Internetworking with TCP/IP - Principles, Protocols, and Architectures (chapter 11)) principles, one way of breaking down the problem of secure messaging is elaborated on in SoK: Secure Messaging overview.
This way of breaking things apart is in no way exhaustive, and it might be wrong in some ways (.e.g it doesn’t take transfer of value via Ethereum into account, and the role of censorship-resistance isn’t clearly outlined). Nonetheless, it’s a useful framework.
The main idea is to break secure messaging apart into three separate parts:
- Trust Establishment. Provide initial key distribution and provenance.
- Conversation Security. Provide protection of exchanged messages.
- Transport Privacy. Hiding communication metadata.
In terms of things blind spots of this framework, here are two heuristics for how to think about it:
Heuristic 1: Err on the side of extreme security, take these properties beforehand.
Notice how this goes against what the author suggests, but it’s more along the lines of don’t compromise on core principles as building blocks. This is an interesting question in terms of usability and adoption, and what the path to that looks like - is it a question of money, to what extent can less secure stuff be added on top of a secure base layer, etc.
Heuristic 2: Thing that might be missed due to focus on ‘secure messaging’ and 2015 focus.
Example: Censorship-resistance, premium on p2p solution, enabling transfer of value and contract logic, new mixnetwork stuff since 2015 (Loopix), new secure messaging advanced (Briar, e.g. see QR Introducing contact logic).
Regarding all these properties, it’s worth keeping in mind this is about trade-offs - it’s naive to think we can achieve all possible desired properties across the board.
This laundry list of properties gives us a rough design space to play around in.
Trust establishment aka key exchange
Users verifying that the entity they want to talk to is actually in possession
of a long-term key.
To do this securely likely requires making some concessions on usability and immediate adoption. See Briar QR BQP protocol, as well as their “Introduction” feature for ways to alleviate this.
Network MitM Prevented
Operator MitM Prevented
Operator MitM Detected
Key Revocation Possible
Automatic Key Initialization
Low Key Maintenance
Easy Key Discovery
Easy Key Recovery
No Shared Secrets
Alert-less Key Renewal
Inattentive User Resistant
Multiple Key Support
No Service Provider
No Auditing Required
No Name Squatting
Conversation security protocol
Once trust has been established, this protocol protects security and privacy of messages. This includes data and metadata of messages, how encryption is performed and what cryptographical protocols are used.
How trust is initially established or how data reaches recipient is explicitly out of scope.
A better term here might be w.r.t exchange of value. Secure Communication Tool. IM is one aspect, or extension.
Security and Privacy
Dropped Message Resilient
No Additional Service
Transport privacy layer
Defines how messages are exchanged. Hides message metadata, such as sender/receiver/conversation provenance.
Also, censorship-resistance here? Internet out, traffic morphing, etc.
In general, this layer is too complex. Not clear with synthesis is of p2p overlay / mixnetworks etc is.
Global Adv. Resistant
No Message Delays
No Message Drops
No Fees Required
No Additional Service
- Team formation - seeding list and outreach
- More early research - teasing out layers/subproblems
- Rough write-up up of these layers and properties / consideration (taking Prague meeting thoughts into account)
Appreciate feedback, thoughts, concerns. Especially around:
- individuals/projects worth reaching out to
- ways of simplifying the problem through layering (e.g. transport privacy)
- general approach