Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
LPardue wants to merge 5 commits into
base: main
Choose a base branch
from
Open

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

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
83201d2
Proposed text to permit work on adapting stream multiplexing elsewhere
LPardue Jun 9, 2025
fc168ff
small edits
LPardue Jun 9, 2025
af7a591
Refine text on security providers and TLS
LPardue Jun 16, 2025
ea13d78
Move text to fourth area
LPardue Jun 16, 2025
a213d6c
Proposed congestion control requirement to recharter (#241)
LPardue Jul 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions charter/charter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,3 +54,8 @@ Defining new congestion control schemes is explicitly out of scope for
the WG. However, new QUIC extensions that support development and
experimentation with new congestion control schemes may fall under the
third work area.

The working group will specify how QUIC stream multiplexing and other
application-oriented extensions (e.g. Datagram) can be adapted to work
over a secure, reliable, and bidirectional byte stream substrate. No
effort will be made to enable insecure substrates.
Copy link
Member

@nibanks nibanks Jun 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@kazuho kazuho Jun 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Copy link
Member

@nibanks nibanks Jun 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@kazuho kazuho Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

@guhetier guhetier Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@kazuho kazuho Jun 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@LPardue LPardue Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Copy link

@guhetier guhetier Jun 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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