OSP protocol split

[backkem]

I opened this ticket to continue the exploration of splitting the OSP protocol up into parts: a Connection spec and a Messaging spec.

OSP Connection (OSP-C) The connection spec would contain mDNS discovery and the authentication step to exchange TLS.

It may be worth exploring if the OSP-C protocol can be defined independent from OSP use. Pushing all OSP specific pieces to the OSP-M spec, such as the values used for _openscreen._udp.local mDNS queries.

OSP Messaging (OSP-M) The messaging spec would contain the CBOR message delivery, presentation, remote playback and streaming protocols. The spec should probably define a normative way of layering OSP-M on top of OSP-C + QUIC. Likewise, this spec would likely define how a potential OSP-over-Matter is wired up.

OSP stack overview I made an overview of what the stack may look like after such a split:

Local Peer-to-Peer (LP2P) considerations Since the group is exploring synergies with the Local Peer-to-Peer proposal, I wanted to quickly touch on that. One way to see the LP2P proposal is also in two pieces: A connection establishment between devices and a transport/messaging API. This is quite similar to the above. I explore this below.

Browser P2P connection I made an overview of what the stack may look like after such a split:

Browser P2P networking I made an overview of what the stack may look like after such a split:

For this overview I used the suggestion from ibelem/local-peer-to-peer#11 to use the WebTransport API and layered a simple messaging protocol on top for ease-of-use.

Sidenote: I think it would be great if the QUIC + WebTransport approach extended to WebRTC as once proposed by p2p-webtransport.

[backkem]

Here's some thoughts on making OSP-C open to other uses:

• Introduce a new agent-capability for send-data and receive-data (or just a symmetric exchange-data). To allow an agent to support only simple message passing. E.g.: ibelem/local-peer-to-peer#13.
• Introduce a new agent-capability for protocol-handoff and an accompanying message that allows the entire QUIC connection to be handed off for tunneling another protocol once agent authentication is complete, E.g.: a QuicWebTransport. Either using the same connection or opening a new one with a different ALPN (as done in p2p-webtransport). Though, the latter may not require negotiation at all.

[backkem]

Some notes on the "OSP Connection" side of things:

• TAG feedback: The protocol spec (goals, approach & definition) needs to become both more focused and more specific/detailed.
• TAG feedback: there is a recommendation to define a client and server role between agents to help structure reasoning.
• TAG feedback: An extremely high bar for security review is appropriate for this type of work, including Data Flow Diagrams and extensive thread modelling using a methodology such as STRIDE or against knowledge bases such as MITRE ATT&CK. They mention that the IETF would be a better venue for such work.
• My suggestion of the 'scope' of this protocol: A means for two peers on the same network segment to establish mutually authenticated TLS certificates, without requiring an intermediary.
• Since we're targeting the web, I would spec out peer & certificate management on user agent & origin level as well as implications of syncing beyond the user agent (e.g. on OS level or cloud assisted).
• I think it's worth exploring peer filtering, including privacy preserving techniques.

[markafoltz]

I am starting to craft a fork of the current specification according to slide #13 I presented at TPAC 2023. This new spec will be layered over QUIC, TLS 1.3, and DNS-SD, so I believe it will fill the "OSP-M" box in the diagram.

I am going to start a new issue to track work specifically around this new draft specification, since I don't know if it exactly follows the plan you have outlined.

I also would like to know the source of the "TAG feedback" you posted above. Can you please post a back-link? What was reviewed, what was the context for it?

We have discussed migrating some or all of the network layers of the protocol to the IETF. As can be seen from open issues, there are many interrelated issues in our usage of existing protocols (DNS-SD, TLS 1.3, X.509, SPAKE2, QUIC etc.), so which IETF group is the right one?

[backkem]

TAG review:

• design-reviews tracking ticket
• comment linking to minutes
• I think Martin was both the most adamant on treating the security review extremely serious and the biggest proponent of that the IETF is the best place for that work.

I'm not sure about orientation within IETF yet. Regardless, we'd probably need an initial writeup in Internet-Draft form.

[markafoltz]

Yes, I agree that the security of any new authentication scheme should be reviewed seriously.

It appears that OSP was discussed in a context which is out of scope for its intended usage, therefore, my position is that the security model, threat analysis, and mitigation tactics that were developed for OSP do not apply. It's unlikely that any of that feedback will influence our direction with OSP, other than general advice to consult with the IETF, or migrate work to the IETF as appropriate.

[backkem]

Closing in favor of the new [meta] tickets.