Require TCP

[martinthomson]

#40 establishes why QMux might need to bind more strongly to TCP than it does presently. Sure, you can run it over a Unix socket or something else. But that won't make the ALPN work for SVCB.

Binding to HTTP CONNECT is the obvious step that might need some consideration. My view is that this cannot use the same service discovery options as for raw TCP bindings. The stack is different, so it will require additional mechanisms. I realize that we cheat and reuse the ALPN for a raw TCP+TLS binding when we bind to CONNECT, but that won't work if you expect to be able to discover the thing using something like SVCB.

It might be easiest to leave bindings to other substrates as an exercise for the reader. That doesn't mean that it is easy though, due to our complete lack of consensus about what ALPN truly means.

[kazuho]

It might be easiest to leave bindings to other substrates as an exercise for the reader. That doesn't mean that it is easy though, due to our complete lack of consensus about what ALPN truly means.

Yeah, I think it would be helpful to non-TCP/TLS deployments if we provided a list of properties that they should provide. In fact, we already point out that security is a MUST. Your proposed change to #29 (https://github.com/quicwg/qmux/pull/29/changes#r2972273075) pushing us in the right direction by clairfying what "security" actually is.

I'm wondering what we need is a "Considerations for non-TLS deployments" section that points out that security (peer authentication, confidentiality, and integrity protection), and protocol negotiation need to be guaranteed, either in-band or out-of-band.

[kazuho]

How does 23c8495 of #33 look like? The commit adds application protocol negotiation as the requirement for the underlying transport (unless when needed). Other requirements are already listed there.

[martinthomson]

It almost goes in the opposite direction a little:

As in QUIC {{Section 8.1 of QUIC-TLS}}, when running an application protocol
over QMux over TLS, endpoints MUST use ALPN {{ALPN}} to agree on an application
protocol, unless another mechanism is used for agreeing on an application
protocol.

One reading of this might be to suggest that there are other options than TLS/TCP, but those don't need ALPN.

I was thinking something more definitive up front. Say that this document defines QMux over TCP/TLS and nothing else, though the same basic mechanism can be used as long as the basic transport facilities are provided somehow. Then use Unix sockets as an (imcomplete) example of that, noting that confidentiality/integrity/authentication rely on very different mechanisms to that used in TLS (host security and access controls) and the protocol choice needs to be made out-of-band.

[kazuho]

I assume you are starting to think that Section 3.1 is overly complex, in sense that it tries to be an exhaustive list of properties that are needed to be provided by the underlying substrate. I actually share the same view. If we call out TLS over TCP as the primary substrate, then all we need to say is that similar capabilities need to be provided when using a different substrate.

That said, I think the changes are going to be editorial, and prefer making such changes after we land all the non-editorial PRs that are currently open.

[afrind]

As much as possible, I want Qmux to be useable over non-TLS transports (HTTP CONNECT -- possible redo of wt/h2?, Unix domain sockets, etc). I suppose if those need to be separate documents it's ok, as long as we don't do anything here that precludes their use in those contexts.

[martinthomson]

I don't see any risk of making it harder to use. But you won't get discovery via SVCB. That's probably OK for named pipes or whatever you want to use. But there you need to have all sorts of external agreements on things like file access permissions, so maybe you are OK with "use QMux in the following way" as a specification.

BTW, HTTP CONNECT qualifies as "TCP". Extended CONNECT gets a little more complicated, but it might depend on what you are attempting to do. I can't see how Upgrade would qualify.

[afrind]

HTTP CONNECT qualifies as "TCP"

Maybe I don't understand the text you want in this draft that would bind it to TCP and how that's going to help? I can wait for a PR though.