Proposed text to permit work on adapting stream multiplexing to secure, reliable, and bidirectional byte stream substrates

[LPardue]

... as discussed and drafted during the June 2025 interim.

[nibanks]

It's not clear if this means defining QMUX + TLS (like we have in QUIC) is out of scope. I believe we'd need that for QMUX over RDMA and possibly TCP.

[kazuho]

While I'm uncertain if RDMA needs transport-layer encryption, we definitely need TLS when running QMux over TCP.

That said, IMO, how TLS should be used is a technical matter that the WG can discuss post recharter. All we need to state in the charter is that the specification(s) should cover not only TCP but also transports that are secure by their nature (e.g., Unix domain socket, RoCE v2 over IPsec).

I would not mind seeing the charter text being changed from "work over a secure, reliable, and bidirectional byte stream substrate" to "work with secure, reliable, and bidirectional byte stream substrates."

[nibanks]

I'm glad we're having this discussion here and now, because I disagree. 😄

I agree that the QMUX solution needs to be secure end-to-end (no cleartext goals), but I think that just like we did with QUIC, QMUX should include the TLS usage as clearly in scope and not push that to something later. From an implementation side, I'd like to see QUIC stacks support TCP/RDMA without having to build entirely new TLS logic.

We are actively building this over RDMA (MsQuic PR) and I'd like to be able to work towards a standard instead of a one-off protocol.

[kazuho]

I think that just like we did with QUIC, QMUX should include the TLS usage as clearly in scope and not push that to something later.

If what you want is a charter explicitly calling out TLS as the dependency when running QMux on top of insecure networks, then I would be fine. However, use of TLS must not be mandated for every QMux connection; it should be required only when the path is untrusted.

QUIC v1 was designed for the Internet, a network that is lossy and insecure. That is why it has built-in loss recovery and encryption. What remained outside its design scope are the paths that are already reliable (so loss recovery becomes pure cost) or already secure at another layer (encryption becomes pure cost). These are precisely the scenarios QMux sets out to serve.

That is why multiple vendors are asking for QMux to have a cleartext mode (recall those wanting to run QMux on Unix domain sockets), similarly to those asking for QMux without loss recovery.

FWIW, I think that one does not need to argue for putting cleartext support out of scope just because they desire using a QUIC-packet-like (or TLS-record-like) structure when encryption is necessary. If we are to adopt such a design, all we need to do for supporting cleartext is define how the frames would be conveyed in a packet-like structure without encryption (recall the null-null-null cipher of TLS/1.2) and define how the Transport Parameters are exchanged.

[guhetier]

However, use of TLS must not be mandated for every QMux connection; it should be required only when the path is untrusted.

I think we agree on that, and cleartext support is fine by us.

To clarify what @nibanks says, with the current wording ("No
effort will be made to enable insecure substrates."), it seems that efforts to specify how to create a secure QMux connection over an insecure network would be out of the working group scope.

We are building such a solution (secure QMux over an insecure RDMA transport). We think it would be better to work toward a standard way to optionally use TLS as part of QMux (if the underlying transport is insecure and a secure connection is needed). QUIC implementations already have TLS logic, and it would allow to re-use it rather than building a new TLS layer between an insecure transport and QMux.

[kazuho]

Thanks, so maybe something along the lines of "〜 can be adapted to work over a secure, reliable, and bidirectional byte stream substrate. When the substrate is insecure, TLS will be used for providing security; no effort will be made to enable unprotected communication insecure substrates."

I would be fine with that.

[LPardue]

There are lots of technical upsides to relying on TLS to provide security,when security is required. ECH and post-quantum spring to mind, but there are many other facets.

From a process perspective, focusing on one protocol to provide security, especially one that is maintained by the IETF, helps minimise the total scope of work and ongoing maintenance. For instance, we don't need to later spend QUIC WG trying to gather consensus on whether to use TLS or something else.

From my perspective, stating usebif TLS now does not preclude other options in the future. Much like QUIC allows for pluggability but doesn't define it all.

It's interesting to go and look at old charter versions. From instance in https://datatracker.ietf.org/doc/charter-ietf-quic/01/ we said

Providing always-secure transport, using TLS 1.3 by default.

Back then stating TLS 1.3 was important. Today, I think using TLS is fine since version 1.3 is the canonical version of "TLs". But perhaps we can steal the phrasing. Adapting Kazho's suggestion then, how about something like

"〜 can be adapted to work over a reliable and bidirectional byte stream substrate. When the substrate is insecure, TLS will be the default security provider; no effort will be made to enable unprotected communication without a security provider."

[guhetier]

Thanks, I think that both these wordings work for us.

[LPardue]

I've pushed two commits that address feedback by: talking about security providers and an explicity TLS default, moving the new text as a fourth work area bullet

[LPardue]

@gorryfair this charter text has now reached the point several WG members and proponents are happy with

[ianswett]

There's part of me that would like this to be a bit wider scoped, but I don't have any specific suggestions, so LGTM