[Discussion] Considering the security of composing various protocols together

[Mikerah]

Since libp2p enables developers to simply pick and plug what protocols they want for their particular system, this leaves developers with a lot of leeway for potentially composing insecure libp2p stacks. So, this brings up a few questions:

• Is there an expectation that a developer who is using libp2p is intimately familiar with all of the protocols to know which compositions might result in an insecure libp2p stack?
• If there is no such expectation, then how can developers build secure libp2p stacks without being an expert in networking security?
• How can libp2p convey or help developers construct secure libp2p stacks?

This problem is a similar problem to what cryptographic engineers face with regards to securely implementing and using cryptographic APIs.

[mkg20001]

One idea that comes to my mind is having pre-made bundles of specific protocols, where users can swap one thing with another but not completely (so it stays limited to a certain mix of protocols)

That way the user never has to assemble a (possibly unsafe) bundle themselves and instead uses a "curated set/bundle" that might allow further (restricted) customizebility using options/config.

[Mikerah]

That is one way to guide developers who are building more predictable libp2p stacks. But, how can the ones who are building more experimental stacks ensure the security of their custom made stack?

[mkg20001]

I think educating the developers about trade-offs and other aspects would be a good first step.

There could be a page that depicts common pitfalls, specific advantages/disadvantages of every transport and some security related aspects (is the protocol stable? was it ever audited? how many people are actively looking into the code?)

[ghost]

@Mikerah Can you give an example of a networking construction where you see a risk for something like this so I can think about your question a bit? (I understand your cryptography analogy.)

[Mikerah]

@mgoelzer A contrived example could be combining one of the plaintext protocols that libp2p supports with some end-to-end encryption protocol like Noise. I don't have any particular realistic examples in mind.

[mkg20001]

Possibly adding a flag per transport/crypto/muxer (in the module itself) that makes the app print "This app is using transport/crypto/muxer ${name} that should NOT BE USED IN PRODUCTION"

[Mikerah]

@mkg20001 In this particular case, it's in the spec directly that the plain text protocols are not meant to be deployed into production. A flag can emphasize this though.

[ghost]

A contrived example could be combining one...

Hi @Mikerah, got it, understand better now. I wasn't considering protocols like Noise that include cryptography, was thinking only of pure networking protocols. Yes, I do see the dilemma.

[Stebalien]

A contrived example could be combining one of the plaintext protocols that libp2p supports with some end-to-end encryption protocol like Noise. I don't have any particular realistic examples in mind.

In go-libp2p, at least, you can't construct a node with both plain-text and encrypted transports. If you try, the libp2p constructor will throw an error.

However, we should probably consider printing an error to the console on start.

[mxinden]

I am closing here since this seems to be implementation specific. E.g. implementations should emphasize that the plaintext transport protocol should not be used in production like the spec does.

In case there is a cross-protocol security concern, please comment here.

In case there is a specification which does not properly communicate its security properties, please open up a separate issue.