Muxer selection in TLS handshake

[julian88110]

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:

1. 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**
}

2. Extend the Transport data type of multistream-muxer and add method to expose the muxer strings that are stored here.
3. Introduce some coupling between the Multistream-muxer and security layer in the upgrader-code, to pass the supported muxers into security protocols.
4. After security handshake is down, the early data result will be available by the method added in step 1.
5. Upgrader logic is revised to use the early data, if available, to select muxer.

[marten-seemann]

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.

[julian88110]

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!

[BigLep]

@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).

[julian88110]

@BigLep yes, the discussion results were posted in the spec issue #454

[p-shahi]

Closed by #1772