Deprecate & remove Secio security transport

[jacobheun]

Now that IPFS has support for TLS and Noise, it's time to complete the process of deprecating and removing support for Secio. This issue is for tracking the rollout.

Please upgrade IPFS ASAP to stay connected! If you are having issues upgrading please let us know here.

Planned releases

Target version of Secio removal: 0.7

History of security support changes

Each update contains the security protocol listed by default priority.

Go IPFS
<0.4.21: Secio
0.4.21: Secio > TLS1.3 (May 31, 2019)
0.5.0: TLS1.3 > Secio (April 28, 2020)
0.6.0: TLS1.3 > Secio > Noise (June 20, 2020)

JS IPFS
<0.47.0: Secio
0.47.0: Secio > Noise (June 24, 2020)

BREAKING CHANGES

Removal of Secio will result in the following:

• Go IPFS nodes older than 0.4.21 will not be able to communicate with Go IPFS nodes >= 0.7.
• Go IPFS nodes older than 0.5.0 with TLS support will require an additional round trip when creating a connection with GO IPFS nodes >= 0.7 (this is due to failing to negotiate Secio and falling back to TLS1.3)
• JS IPFS nodes older than 0.47 will not be able to communicate with GO IPFS nodes >= 0.7.

Testing

• Prior to removing support for Secio we will do thorough testing of the DHT to ensure we are maintaining performance added in 0.5.

References

• https://blog.ipfs.io/2020-08-07-deprecating-secio/

[aschmahmann]

@jacobheun it looks from @petar's testing that dropping secio from go-ipfs should not adversely effect DHT queries.

Noting for posterity that the dynamics here are a bit complicated and depend on things like relative churn rates between secio-only nodes and others, as well as relative publish publishing, bandwidth and DHT storage capacity between the secio-only nodes and others. Nonetheless, this change seems like a great step forward for the network as we'll not have to worry about secio support any more and will likely encourage people with older nodes to upgrade and therefore improve overall DHT + Bitswap performance.

@petar if you could drop any of your network observations here that would be great.

[petar]

I ran experiment where a "provider" node with/out secio provides a file, then goes offline. Then a "finder" node with/out finds the key. Both operations are timed. The code: https://github.com/protocol/metrics/pull/58

The results (latencies in seconds):

provide_with_secio=True find_with_secio=True avg_provide_latency=82.68211948871613 avg_find_latency=1.6082610845565797 samples=10
provide_with_secio=True find_with_secio=False avg_provide_latency=73.89061946868897 avg_find_latency=0.9889777898788452 samples=10
provide_with_secio=False find_with_secio=True avg_provide_latency=59.50378656387329 avg_find_latency=1.1638094186782837 samples=10
provide_with_secio=False find_with_secio=False avg_provide_latency=64.3090191602707 avg_find_latency=1.5224241018295288 samples=10

The results suggest that the latency of a provide-find roundtrip is not affected much by whether the provider and finder support secio or not.