go-libp2p
go-libp2p copied to clipboard
libp2p
Muxer selection in TLS handshake
This enhancement is the go/TLS implementation of the spec#446; which is tracked by #426.
The core idea is to perform muxer selection in the security protocol handshake process, rather than selecting muxer in a separate multistream-selection round.
In order to implement this enhancement, I am planning to do the following:
- Extend the ConnSecurity interface by adding a method for retrieving early data negotiated by the security protocol. This interface is implemented by several security layer data types, including TLS, Noise, and Insecure.
type ConnSecurity interface {
// LocalPeer returns our peer ID
LocalPeer() peer.ID
type ConnSecurity interface {
// LocalPeer returns our peer ID
LocalPeer() peer.ID
// LocalPrivateKey returns our private key
LocalPrivateKey() ic.PrivKey
// RemotePeer returns the peer ID of the remote peer.
RemotePeer() peer.ID
// RemotePublicKey returns the public key of the remote peer.
RemotePublicKey() ic.PubKey
**// Early data negotiated by the security protocol. Empty if not supported.
EarlyData() string**
}
- Extend the Transport data type of multistream-muxer and add method to expose the muxer strings that are stored here.
- Introduce some coupling between the Multistream-muxer and security layer in the upgrader-code, to pass the supported muxers into security protocols.
- After security handshake is down, the early data result will be available by the method added in step 1.
- Upgrader logic is revised to use the early data, if available, to select muxer.
Thank you for writing this up @julian88110! This sounds like a good plan.
I'm wondering if instead of an EarlyData method we should instead expose a ConnectionState, similar to what the tls.Conn in the standard library exposes: https://pkg.go.dev/crypto/tls#Conn.ConnectionState. One of the fields (and the only one for now) would of the returned ConnectionState struct would be NegotiatedProtocol string, but this would allow us to add more fields in the future.
The ConnectionState idea is a good point, it makes it easier to extend. Yes we can definitely adopt this approach. Thanks for bringing that up!
@julian88110 : if there are updates/changes to the plan in light of 2022-09-19 conversations, please update. here (or in the libp2p/specs issue if that makes more sense).
