-
Notifications
You must be signed in to change notification settings - Fork 22
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.
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
OSP protocol split #321
Comments
This comment was marked as outdated.
This comment was marked as outdated.
Some notes on the "OSP Connection" side of things:
|
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? |
TAG review:
I'm not sure about orientation within IETF yet. Regardless, we'd probably need an initial writeup in Internet-Draft form. |
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. |
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.
The text was updated successfully, but these errors were encountered: