Best Security Practices for Client/Server vs. PublishSubscribe Patterns

[OliverPfaff]

The PublishSubscribe (multiplex) communication pattern is much more complex than the Client/Server (point-to-point) communication pattern - when it is an objective to protect the information that is exchanged between a publisher and its subscribers (the current text suggests that protection of information [above/beyond the protection of transports] is regarded a goal)

For instance

• Multiplexed communications typically demands a group key management (point-to-point typically don not)
• PublishSubscribe communications typically have a legal middle entity (e.g. MQTT broker) that does more than a client/server middle entity (e.g. HTTP proxy)

The OPC-UA spec shows in its Part 14 that it's a really long way from client/server security to PubSub security

As long as WoT includes client/server and PubSub communication patterns, the security considerations should provide a signal in style of "protecting client/server interactions and publish/subscribe interactions is different; the latter comes with additional complexity..."

I think that would justify an own subsection in "6 Best Security Practices..."

[ereshetova]

Yes, I agree, we have not looked into publish/subscribe model at all yet, but we need at least to mentioned that it comes with its own challenges.

Michael, do we expect WoT to support publish/subscribe model in the foreseeable future? If yes, we better also start looking into this now.

[mmccool]

Meeting discussion:

• Best practices document was defined to limit testing... no point testing things that are known to be broken; also mostly focused on the "web" case (REST, HTTP, etc).
• Lots of material available on client/server, not so much for pub/sub or even CoAP (which is client-server)
• OPC UA is both client/server and pub/sub; also have two stacks, SOAP and REST. Pub/sub also has its own security mechanism (including application-layer object security)
• In the CoAP/CoRE, need to look at JOSE, COSE, etc.

Plan:

1. Outline the scope we want to cover; what protocols and patterns? Explicitly decide on a finite set.
2. Look at the patterns in that set: object security, tokens, access controls, etc.
3. When there is a clear standard for a best practice, cite it; if there is a broader set of best practices (eg web), provide some guidance.

[mmccool]

Summary: We will be looking at protocols that support publish/subscribe patterns (MQTT, HTTP with event/subscribe interactions, OPC-UA), so we do need to look at this.

Action: Follow the plan above. Find suitable references, eg for MQTT, OPC-UA, HTTP, etc.

Assign to Oliver not for a PR at this point, but only to come up with a more concrete plan.

[OliverPfaff]

Suggested plan:

1. Create a new subsection in "6 Best Security Practices and Mitigations for WoT Systems" e.g. "6.5 Security practices for client/server and publish/subscribe patterns"

2. In this section start by stating that security for the publish/subscribe pattern is unequal (more complex) than security for client/server

3. Then explain best security practices for the client/server pattern (new subsection on level 3) using the HTTP and CoAP protocols as a reference (note: this should also point to the end-to-end consideration)

4. Then explain best security practices for the publish/subscribe pattern (new subsection on level 3). Here it is important to distinguish 2 approaches colloqually called here "Pedestrian approach" and "Sophisticated" (this is not meant to appear as such in the document): The pedestrian approach uses client/server security between the system actors e.g. publisher/broker and broker/subscriber (does not provide end-to-end security between publisher/subscriber but typically is cheap). Example MQTT with TLS protection. The sophisticated approach uses application-level security objects plus group key management means to provide security between publisher/subscribe (the broker can do its routing tasks but can not interfere with exchange message contents). Example: OPC-UA PubSub. Note: this is not meant to say "A is bad, B is good". The message is "there are choices, be aware of their security properties, make an educated decision [not a random guess]. If A resp. B is is the result of an educated decision then everything is good)

[OliverPfaff]

Done (see above) => unassigned myself