Review Security and Privacy Considerations

[mmccool]

The security and privacy considerations section needs to be reviewed and updated.

See also similar issues for other deliverables; we need to also decide what goes where:

• Review Security and Privacy Considerations wot-architecture#672
• Review Security and Privacy Considerations wot-thing-description#1348

This was also discussed in w3c/wot-security#196 but it makes more sense to discuss this in Discovery (since this is where the document and its deadline is) and close the issue in security (although the discussion is still relevant).

[mmccool]

Additional consideration:

• A service could record and track queries by an individual, identifying that individual by their authenticated identity provided. Mitigation: users could use an anonymous identity provider, i.e. they use OAuth2 provides tokens which don't identify specific individuals, they just assert access rights proven elsewhere.
• In peer-to-peer scenarios, the scope and duration of the access may be limited. Mitigation: use a token/auth provider that provides limited duration tokens and use scopes to limit access. Scopes alone are not sufficient, depending on the information in the token only a subset of the database may be made accessible. This is not defined in the standard.

[mmccool]

See list of topics in other linked issue, where topics like access control are discussed in depth. One relevant one to individuals exposing things (Client scenario) is the use of persistent Thing IDs. Migitations: anonymous TDs (directory then creates and assigns an id), ID rotation.

Think we have a fair amount of material, I just need to put together a PR. Also need to discuss in Discovery call.

[mmccool]

See discussion under Issue 263 regarding the interaction of LAN HTTPS cert problems and self-description, which together basically defeat any privacy protections. This needs to be fixed, probably with some kind of onboarding process, which could be put into the HTTP Profile.

[mmccool]

Following point around LAN security should be added as a Security and Privacy consideration:

• On a LAN, recommend that pre-shared keys be used in place of certs. See https://datatracker.ietf.org/doc/html/rfc4279 for cipher suites that can be used with TLS 1.2.

See linked Issue #263 for discussion. The other mitigation is to NOT support self-discovery if security cannot be established.

Note that passwords etc. still need to be used since different passwords/tokens/etc. may provide different access levels to different users. The PSK should not be the only access control. In particular, do not use nosec even with PSK. Also, the PSK should be unique to the device pair and not used for any other purpose (e.g. as a password...).

The PSK may be derived from internal device identity but this is separate from the "id" used in the Thing. The Thing should NOT be revealing its internal identity. However we do need a separate recommendation somewhere (profiles? TD?) that Things should use cryptographically generated ids and UUIDs for TD to avoid collisions, etc.

[j1y3p4rk]

@mmccool , please add me as a reviewer.

[mmccool]

See #139 and Ben's comments on #263. Summary: Ben is against blanket recommendation of PSK-based TLS on local networks. One option I can see is that we EITHER require TLS or access via a public URL (e.g. via a cloud tunnel) with a cert. But I suspect Ben won't go for that either, at least not if we require it. Anyway, #139 is relevant to this discussion.

[mmccool]

@j1y3p4rk, I assigned you to this issue but github won't let me assign you to the PR I created resolving it, PR w3c/wot-discovery#264, which is what I really want to do. Can you please comment on that PR so I can add you, and/or just go ahead and review it? That is, once I fix the PR so it's complete, there is a technical problem I am working on fixing.

[mmccool]

• Probably need a generic security consideration around mitigating all OWASP Top 10 securityissues in Directory implementations - also true for all Thing implementations, so should go in TD spec as well.
• "Limited Duration Access" does not belong here - move it to the TD security considerations
• Have not yet considered replay attacks (already in OWASP Top 10? If it is...)

[mmccool]

• If there is a longer list of security concerns we can add it as well, but my thought is that mitigating the OWASP Top 10 should be a minimal requirement for implementations.

[mmccool]

Merging PR to restructure, but need additional PRs to address some additional considerations. Also, the LAN consideration needs to be moved to security; it is currently under privacy.

[mmccool]

See also issue w3c/wot-profile#397 - may want to add a consideration for this as well (use of OAuth with SSE notifications).

[mmccool]

Propose closing this, if there are no new review comments for S&P, although we might still need to upgrade these sections to normative status.

[mmccool]

so I added security-needs-resolution accidentally, then removed it, then w3cbot added it, I thought it was I who added it, so I removed it again, then noticed it was w3cbot, so put it back. Sigh.

[mmccool]

also note these sections have been updated to normative status and significantly revised since this issue was raised. The WoT Security TF has now reviewed and updated these, so I propose we can close this issue (since it was about doing the review and updating the S&P considerations, which is now complete - external Wide review is a new issue)

[mmccool]

@plehegar same bug with security-needs-resolution as was showing up in wot-architecture...

[mmccool]

These have all been reviewed at this point, will close this issue - more specific issues can be opened later if something comes up.