Proposal for the Trusted Private Network feature

[alikic]

It's described at ipfs/kubo#2968. The issue has been closed as "not actionable", and I was advised to open an issue here.

Sorry, I'm new here, what is the procedure of making an issue "actionable"?

The proposal introduces a concept of a Trust Manager at the network level. It's not a new concept, I borrowed it from Java. In Java, as many probably know, Trust Manager is used during TLS handshake to decide if the other party is trusted; if it is, connection is allowed.

It is important to understand that the concept of a Trust Manager belongs to golang network libraries, not IPFS. The only reason it is proposed here is because IPFS uses a custom "TLS like" protocol. I know there is a plan to switch to TLS, but until then this can fill the gap for people who need private networks now.

[troyronda]

Direct link to the proposal: https://github.com/securekey/go-ipfs/blob/a2c73ac501f602a2dbbe5260ec7e7fec4d30ee60/docs/trusted-private-network.md

[whyrusleeping]

This is the current issue for this feature: ipfs/kubo#1633
Its something we're hoping to work on soon (next few months).

@troyronda thanks for that proposal, we will review soon! (ping me about it if we're taking too long on doing that)

[nothingmuch]

Reading the proposal, it's not very clear to me what specific definitions of trust or private the spec is using, IOW what is it trying to achieve with the notion of trust, so I may have jumped to conclusions.

It's implied that trust is about whether or not you are willing to communicate with a peer, in other words that cliques of trusted peers form completely independent privates IPFS networks? Or is this more of a peer to peer trust model, to configure things like access through a gateway on a private network? (Personally I'd like to see both). What does it mean, for example, for a peer with the simple trust manager trusting a peer using the default trust manager? What about things like directed cycles in this trust graph? Is the list of trusted peers considered private? (I don't mean scenarios where you control all the machines, but rather if you participate in what you think is a private network but one of the other participants is malicious, it should be clear what privacy guarantees are not being made).

At the network and host security layer, there are good reasons to only talk to trusted peers (to not expose an attack surface, to avoid denial of service, and spam). It sounds to me like this is your main goal?

At the IPFS content layer, since hash based paths allow validation of the content, it doesn't really matter where it comes from, so exchanging blocks with untrusted peers is always fine from an integrity standpoint. This leaves denial of service/censorship and privacy as the main concerns regarding the IPFS data model.

Denial of service mostly has to do with always trying to fetch IPNS data from trusted sources, which are believed to have up to date signature material. I can't really think of any other concern. Would the complex auth model be able to handle different types of trust or just a boolean notion?

Privacy breaks down into not two main aspects, disclosing the data you access on IPFS, and with witholding the kind of data you share. IMHO the former is in scope for peer trust, but that the latter should be explicitly left out and addressed in a higher level, e.g. a capability/encryption scheme.

[alikic]

In the proposal title, "Trusted Private Network", "Network" means a set of IPFS peers exchanging data over p2p channel. "Private" means a closed network, not open to all peers on the internet. "Trusted" is closely related to "Private", in a sense that the privacy is achieved by allowing connections only among peers which somehow trust each other. Peers in the private network are not necessarily controlled by a single party; if they are not, trust schema has to be agreed upon among all private network participants, which is beyond this proposal.

We need a decentralized storage with access control. IPFS has certain characteristics that make it very attractive for our use case, but it is lacking on security. We can deal with security / access control of the HTTP API (as it is accessible only from localhost) by putting an access control layer on top of it. Securing the p2p channel is more challenging, as it requires deep changes in IPFS architecture/implementation.

p2p channel is currently open to any other peer which provides its identity (public key) and proves it is in possession of the corresponding private key. This is not acceptable in our use case. We absolutely require that the other peer belongs to the group of IPFS peers which together make the decentralized storage; if it doesn't we don't want the connection to succeed. So, "trust" in this model is at the peer level. Having all peers trusting each other makes this p2p network "private".

To implement trust between peers, the proposal borrows the concept of Trust Manager from java. In java, TLS connection between communication peers is established only after the Trust Manager implementation verifies that the other party can be trusted. It's a direct analogy to what is being proposed here. In addition, the proposed IPFS TrustManager interface has a way to retrieve a list of trusted peers, to be used for IPFS peer bootstrap.

The level of trust and the overall security depends (among other factors) on the Trust Manager implementation. You rightfully pointed out that having a peer with SimpleTrustManager trust a peer with DefaultTrustManager is a problem, and this scenario is actually specified as problematic in the proposal itself. So, if one wants to use SimpleTrustManager in production, one would have to implement operational procedures that would limit the possibility of malicious configuration or misconfiguration (like circular trust definitions). SimpleTrustManager is just a reference implementation that validates the concept. We think that SimpleTrustManager may be suitable for testing (of the system using private decentralized storage), but we will never use it in production. We are implementing our own, very specific TrustManager plugin (driven by the PluginTrustManager) that requires all peers in our private network to register with the central server, and to authenticate to retrieve private network configuration. Only the registered peers are trusted; that is, the trust between peers is derived from the trust between the peers and the central server. Also, the peers will have their private keys stored in HSM (this is for another proposal). In this setup, a rogue peer configured with DefaultTrustManager won't be able to connect to any peer in the private network, provided there are appropriate operational measures for configuring access to HSM, central server, etc.

I hope this clarifies our motivation and the scope. I feel that the proposed feature is very low level (network/peer, not data) and doesn't have to be coupled with other privacy/security features in the road map. That is, it doesn't need to wait, I hope. Do you agree?

We will need few additional features (like ability to use keys from HSM), but I thought we take it step by step so we can move faster.

[bronger]

Does an IPFS daemon instance taking part in a private network be able to participate in the general IPFS network at the same time? Or is it an either–or solution?

[alikic]

@bronger This is either-or. The network is either private or it is not. An instance communicates only with the set of trusted peers. There are use cases when an instance must be in the private network, and at the same time talking to the rest of the world (or another private network). These scenarios call for gateway-like features, which are not in this proposal. I am interested in these cases too, just wanted to start with the least common denominator which, in my mind, this proposal is. The reason I am pushing this way is because I see many great ideas in the backlog waiting for a long time. So, instead going for a big bang, I am proposing an iterative approach that, hopefully, get things delivered in small independent increments, hopefully sufficient to cover simpler use cases.

[neerbada3]

I am also looking for IPFS in Private network as there are lot of good use cases to implement.

[alikic]

@neerbada3 What does "private network" mean to you? How far does this proposal go in meeting your needs?

[bronger]

@alikic I see. And you are right, sometimes, in hen-and-egg situations, one has to move forward somehow and finetune later.

[neerbada3]

@alikic Private network means to implement IPFS in an organization intranet and in above proposal "TrustManager plugin" is addressing the requirements too.

Just a question - Is there is anything which can be blocked across the Intranet firewall so that IPFS request will not go outside the Intranet network ?

[troyronda]

@neerbada3 From my PoV, a private network enables IPFS across peers (e.g., organizations, departments, individuals) that have some level of a trust relationship. This proposal is intended to work without restricting operation to an intranet but rather create private networks across the Internet.

[bronger]

I'm still slightly lost in this moving (and quickly evolving) target IPFS. So forgive me if it's OT here but I'd like to elaborate on my use case which led me to my question above: I am the research data manager of a major research facility, and IPFS seems to fit perfectly. Scientists want to share most files with everybody – no problem with IPFS. However, some things should only be shared within a trusted network. This may be the set of IPFS daemons in an institute, or that institute + project partners. Alas, and there are many projects active at the same time!

Encryption would be possible but it is difficult to make scientists to like that. “My data must not leave my institute, encrypted or not!” is what you hear. Therefore, I subscribed to this issue.

Ideally, I can define many IPFS networks, a couple of trusted ones and the Global One. And then, I can put the local directories into multiple of these networks. By configuring the daemon instance, for example.

Is this in the scope of this issue, maybe on the long run?

[troyronda]

I agree @bronger. Although encryption may be a good step and a good layer of protection, there are beliefs that just encryption is not sufficient and that the encrypted data themselves needs segregation as an additional layer of protection. The first step is to enable a private IPFS network where the encrypted files are not even accessible outside peers that know & trust each other (what I called a trusted relationship above). To do so, we need a way to plugin the logic of whom is trusted within this network (I say plugin as different networks have different ways to accomplish this). This proposal is for this first step.

I also think that there are several steps after enabling "private networks" to enable use cases (like yours) where each data needs to be shared across different networks (or even be protected using pluggable ACL mechanisms). This evolves the model for IPFS to an even more interesting space (perhaps having some properties of federated filesystems).

[alikic]

@bronger You would be able to define a couple of trusted networks you need just using this proposed feature. One node could be a member of multiple networks. The concept of a "network" here is just a set of nodes trusting each other, nothing more.

This feature enables sharing across all trusted networks, not a problem. What this proposal doesn't cover is the ability to create network hierarchies. For example, I might have networks A, B and C, and want that a node in A has access to to data from nodes in A, B and C, but I don't want nodes in B and C to have access to data outside their networks. If you need something like this that would be a new feature.

[ingokeck]

If it comes to privacy, then encryption is not a solution, as all encryption will become breakable over time, by advances in computing power and by development of "algorithmic shortcuts" that reduce the encryption strength. Therefore, one should not share private data with untrusted parties even when it is encrypted.

That means for IPFS that it will only be suitable for private data if I can restrict to which nodes my data goes to. I do not really need encryption on IPFS level, because I can encrypt my data before I let IPFS handle it, but I need access control at IPFS connection level. As we are speaking about small networks that should be fairly easy to implement using a list of trusted keys for trusted nodes or allowing all keys signed by a trusted key.

As IPFS is set up to be a file system I guess it is tempting to include a dedicated right management into IPFS that would also allow hierarchical layers of access or per file based access rights. But I fear a feature like would be far more complicated and to get it right will take far more time that having simple private networks right now.

[Kubuxu]

I created ipfs/kubo#3313 describing our first take on issue of Private Networks, it is much simpler implementation of just Pre-shared Key. If you have any comments or issues about upcoming implementation, you can ask them there.

[ajbhatia-visa]

The IPFS White Paper Section 3.8 Using IPFS lists some usecases that contain the word "encrypted". For example: 3. As an encrypted file or data sharing system. Also usecases 8 and 10. Reading this conversation, it seems that encryption is not yet supported natively on IPFS, but I got the impression (from issue 181's discussion) that it is planned to be supported in the future. However, any comments on the listed usecases in the white paper in the light of @ingokeck 's comment on Aug 30, 2016 above - specifically, that encryption is not a solution for privacy because it will become breakable over time?