Proposal: deprecate pnet / PSK

What is pnet / PSK?

Users can configure a PSK to create a “private network”. This works by first encrypting the underlying TCP connection using Salsa20, and then running a libp2p TCP connection (i.e. TCP transport or WebSocket transport) on top of that.

Specification: https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md

What is it intended to achieve?

The spec says that nodes in different “private networks” should not be able to connect to each other.

This statement has been interpreted in different ways, see for example the discussion around QUIC and pnet: https://github.com/libp2p/go-libp2p/issues/1432. One property that one could aim for is that if a node doesn’t know the PSK, it is not able to learn that another node speaks libp2p (the way pnet works on TCP has that property). Another interpretation would be that we only care about the handshake not completing successfully,.

A lot of times, pnet is used to make sure that nodes don’t advertise to the public IPFS DHT.

What’s the problem with this?

1. It double-encrypts all data sent on TCP. This is slow.
2. Using a PSK for access control to any network (larger than a tiny number of nodes) has a lot of unappealing properties: There’s no way to revoke access, there’s no way to handle compromise of the PSK (which is virtually guaranteed given a large enough number of nodes), there’s no way to roll to a new key, etc.
3. It only works on TCP and WebSocket. It doesn’t work on QUIC, WebTransport and WebRTC (see issue linked above for our failed attempts to make it work). QUIC is the transport we’re optimizing for, and it already handles > 75% of the traffic on the IPFS network.

What are the alternatives?

• For building a private network that hides the fact that libp2p is spoken: use a VPN. VPNs are quite literally built for this.
• For making sure that the IPFS DHT is not used: use a different protocol name for Kademlia.

Start by reading the pnet/Private-Networks-PSK-V1.md specification and the linked QUIC discussion in go-libp2p issue 1432. The payload names no repository files or tests; done would require an agreed deprecation scope and corresponding project guidance.