Muxer selection in security handshake

connections/README.md

@@ -234,6 +234,11 @@ Note: In the case where both peers initially act as initiators, e.g. during NAT
 hole punching, tie-breaking is done via the [multistream-select simultaneous
 open protocol extension][simopen].
 
+### Inlining Muxer Negotiation
+
+If both peers support it, it's possible to shortcut the muxer selection by moving
+it into the security handshake. Details are specified in [inlined-muxer-negotiation].
+
 
 ## Opening New Streams Over a Connection
 
@@ -409,3 +414,4 @@ updated to incorporate the changes.
 [simopen]: ./simopen.md
 [resource-manager-issue]: https://github.com/libp2p/go-libp2p/issues/635
 [hole-punching]: ./hole-punching.md
+[inlined-muxer-selection]: ./inlined-muxer-negotiation.md

connections/inlined-muxer-negotiation.md

@@ -0,0 +1,135 @@
+# Stream multiplexer negotiation in security handshake
+
+
+| Lifecycle Stage | Maturity      | Status | Latest Revision |
+|-----------------|---------------|--------|-----------------|
+| 1A              | Working Draft | Active | r1, 2022-12-07  |
+
+Authors: [@julian88110], [@marten-seemann]
+
+Interest Group: [@marcopolo], [@mxinden]
+
+[@marten-seemann]: https://github.com/marten-seemann
+[@marcopolo]: https://github.com/marcopolo
+[@mxinden]: https://github.com/mxinden
+[@julian88110]: https://github.com/julian88110
+
+See the [lifecycle document][lifecycle-spec] for context about maturity level
+and spec status.
+
+[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
+
+## Table of Contents
+
+- [multiplexer negotiation in security handshake](#multiplexer-negotiation-in-security-handshake)
+    - [Table of Contents](#table-of-contents)
+    - [Overview](#overview)
+    - [Design](#design)
+        - [Current connection upgrade process](#current-connection-upgrade-process)
+        - [Improved multiplexer negotiation](#improved-multiplexer-negotiation)
+            - [Multiplexer negotiation over TLS](#multiplexer-negotiation-over-tls)
+            - [Multiplexer negotiation over Noise](#multiplexer-negotiation-over-noise)
+    - [Security](#security)
+    - [Alternative options considered](#alternative-options-considered)
+
+## Overview
+
+Transports that don't support native stream multiplexing (e.g. TCP, WebSocket) negotiate
+a stream multiplexer after completion of the cryptographic handshake, as described in [connections]. 
+Negotiating the stream multiplexer takes one network roundtrip.
+This document defines a backwards-compatible optimization, which allows running the
+multiplexer negotiation during the cryptographic handshake, thereby reducing the latency of
+connection establishment by one roundtrip.
+
+
+## Design
+
+### Multiplexer Negotiation over TLS
+
+When using TLS, the [ALPN] extension is used to negotiate the multiplexer.
+
+The ALPN TLS extension allows the client to send a list of supported application
+protocols as part of the TLS ClientHello message.  The server chooses
+a protocol and sends the selected protocol as part of the TLS
+ServerHello message.
+
+For the purpose of multiplexer negotiation, the protocol IDs of the stream 
+multiplexers are sent, followed by "libp2p". The multiplexer list is ordered by
+the client's preference, with the most preferred multiplexer at the beginning.
+The server SHOULD respect the client's preference and pick the first protocol
+from the list that it supports.
+
+Example for a node supporting both yamux and mplex, with a preference for yamux:
+```json
+[ "/yamux/1.0.0", "/mplex/6.7.0", "libp2p" ]
+```
+
+The "libp2p" protocol code MUST always be the last item in the multiplexer list.
+According to [tls], nodes that don't implement the optimization described in
+this document use "libp2p" for their ALPN. If "libp2p" is the result of the
+ALPN process, nodes MUST use multistream negotiation of the stream multiplexer
+as described in [connections].
+
+### Multiplexer Negotiation over Noise
+
+The libp2p Noise Specification allows Noise handshake messages to carry
+early data. [Noise-Early-Data] is carried in the second and third message of
+the XX handshake pattern as illustrated in the following message sequence chart.
+The second message carries early data in the form of a list of multiplexers
+supported by the responder.The initiator sends its supported multiplexer list 
+in the third message of the handshake process, ordered by its preference. It
+MAY choose a single multiplexer from the responder's list and only send that
+value.
+
+The multiplexer to use is determined by picking the first item from the
+initiator's list that both parties support.
+
+Example: Noise handshake two clients that both support mplex and yamux. The
+client prefers yamux, whereas the server prefers mplex. 
+
+```
+XX:
+-> e
+<- e, ee, s, es, [ "/mplex/6.7.0", "/yamux/1.0.0" ] 
+-> s, se, [ "/yamux/1.0.0", "/mplex/6.7.0" ] 
+```
+
+The result of this negotiation is "/mplex/6.7.0".
+
+If there is no overlap between the multiplexers support by client and server,
+the handshake MUST fail.
+
+The format of the early data is specified in [Noise-handshake-payload].
+
+
+## Privacy
+
+The list of multiplexers carried in the TLS ALPN extension field is part of the
+ClientHello message which is not encrypted. Using this optimiziation therefore
+exposes the list of supported multiplexers to an on-path observer. This leak can
+be considered insignificant, since a libp2p node reveals its list of supported
+multiplexers to any node that connects to it.
+
+The NoiseExtensions sent in the Noise handshake is sent after the peers have 
+established a shared key, so an on-path observer won't be able to obtain the
+list of multiplexers.
+
+
+## Alternative options considered
+
+Instead of ALPN for multiplexer selection to reduce RTT, other options such as
+TLS extension and X.509 extension were considered. The pros and cons are explored
+and the discussion details can be found at [#454].
+
+
+
+[#426]: https://github.com/libp2p/specs/issues/426
+[connections]: https://github.com/libp2p/specs/tree/master/connections
+[sequence-chart]: https://github.com/libp2p/specs/tree/master/connections#upgrading-connections
+[ALPN]: https://datatracker.ietf.org/doc/html/rfc7301
+[Noise-Early-Data]: https://github.com/libp2p/specs/tree/master/noise#the-libp2p-handshake-payload
+[ECH]: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
+[handshake-payload]: https://github.com/libp2p/specs/tree/master/noise#the-libp2p-handshake-payload
+[#454]: https://github.com/libp2p/specs/issues/454
+[Noise-handshake-payload]: https://github.com/libp2p/specs/blob/b0818fa956f9940a7cdee18198e0daf1645d8276/noise/README.md#libp2p-data-in-handshake-messages
+

noise/README.md

@@ -220,6 +220,7 @@ syntax = "proto2";
 
 message NoiseExtensions {
     repeated bytes webtransport_certhashes = 1;
+    repeated string stream_muxers = 2;
 }
 
 message NoiseHandshakePayload {