use TLS as default security, and secio as a fallback

[marten-seemann]

Not sure if this is premature, but I don't see any more blocking issues in go-libp2p-tls.

I considered adding TLS as a fallback to secio, but that effectively guarantees that TLS is never used, since every node now supports secio.

[Stebalien]

So, the downside is a round-trip (thanks multistream). However, I really want this.

[vyzo]

this is fine by me!

[bigs]

love it :)

[Stebalien]

Blocked on questions around transmitting keys: libp2p/go-libp2p-quic-transport#40. Also, support for non RSA keys: libp2p/go-libp2p-tls#6.

[marten-seemann]

I updated the PR with the new release of go-libp2p-tls, which now implements the spec.

[Stebalien]

In go-ipfs, at least, I'd prefer to make this available for a release before making it the default (although we can add an option to make it the default, experimentally).

[marten-seemann]

I created ipfs/kubo#6229 with the experiment for IPFS.

We should be able to merge this PR here independently of what we're doing in IPFS. Could you please add your review, @Stebalien and @raulk?

[raulk]

PR looks good, but before merging the default, I’d like us to conduct proper tests to characterise:

1. How many round trips we introduce in Multistream if one party supports both, and the other supports one. Characterising this twofold: when we’re the client and the server.
2. Smoke test it live with several daemon instances.
3. Characterise end-to-end performance SecIO vs TLS (once we’ve agreed via Multistream).
4. Maybe test it out in with several IPFS nodes.

The data we gather will be useful for when we make the feature announcement (in the forums and elsewhere).

[marten-seemann]

The IPFS experiment is already on its way: ipfs/kubo#6229 was merged today. Please remember to turn on the experiment when you update your node (once 0.4.21 is released) :)

While I’m generally in favor of collecting data, running all these measurements will be a lot of work, and I’m not sure if it will produce any actionable data in this case. We decided to switch to TLS 1.3 a long time ago, for multiple reasons:

1. We believe that using a formally proven protocol, as well as a well-reviewed implementation will give us higher confidence in the security of the protocol than we have in secio.
2. We know that TLS saves us one roundtrip during the handshake.

Even if CPU performance of secio was significantly better than for TLS (I highly doubt it, but I don’t have any data), we wouldn’t change our minds and abandon TLS, would we?

[raulk]

Not all libp2p implementations support TLS. This would introduce a round trip penalty on interoperability, by default. The new lightweight libp2p handshake is Noise, which is widely supported by all implementations. Once that matures and we have a full suite, it will become the primary handshake, with SecIO being relegated to a fallback handshake, to be later removed altogether.