Update Security and Privacy Considerations

[mmccool]

Currently a placeholder for WIP - do not merge.

• Resolves Review Security and Privacy Considerations #1348
• Resolves Split "9. Security and Privacy Considerations" into two sections? #1363

---

Preview | Diff

[sebastiankb]

please also consider #1363

[mmccool]

Updated to implement split into two sections, security and privacy considerations. Note: the id's still all contain "sec-security-considerations". I'll probably update the ids as well but only after I check that there I won't break any links (at least within the document...).

[j1y3p4rk]

I reviewed it, and the privacy part is well written.

In the security consideration part, I have minor change requests.

In 9.1 TD Interception and Tempering Security Risk- mitigation part, "mutual authenticated channels" --> "mutual authenticated secure channels" because actually mutual authentication does not help to mitigate MITM attack but secure (encrpyted) channel established after mutual authentication does.

With the same reason, I would like to ask to change in the chapter 9.2 Context Interception and Tempering Security Risk - Mitigation part, "obtained through authenticated channels" --> "obtained through secure channels established by mutual authenication" something like that..

If discussion is needed, we can do that in the security call.

[mmccool]

• Probably need a generic security consideration around mitigating all OWASP Top 10 security issues (see also Discovery). Maybe not a consideration, but a reference in the intro in the same place we reference the WoT Best Practices (and the WoT Best Practices doc should also mention it...).

[mmccool]

please also consider #1363

Done

[mmccool]

@j1y3p4rk I updated 9.1 and 9.2 to include your input. Indeed use of encryption (secure channels) was what I meant... However, upon reviewing 9.2 I'm wondering if we can add another mitigation: if a context URL uses only HTTP, we could recommend that an implementation ATTEMPT to fetch the context file (if needed) from an HTTPS URL instead and only use the HTTP one if absolutely necessary. Is that a reasonable thing to add here?

[mmccool]

I went ahead and added the following sentence to the end of 9.2:
"If it is necessary to fetch a context file, an implementation may also attempt to use HTTPS (HTTP over TLS) even when only an HTTP URL is given."
Please comment if you feel this is a bad idea and I can revert. A lot of the time use of an HTTP URL is just a convention (a standardized "name" for the context) and when actually fetching content is it expected/permitted to upgrade security measures.

[mmccool]

I wonder also if somewhere in the TD spec (need to check if the JSON-LD spec already says this) it should say that HTTP and HTTPS URLs, if otherwise the same, are assumed to describe the same context. Note the TD spec itself uses HTTPS context URLs (and really, we do want to avoid downgrading that to HTTP by accident, so a validator should reject HTTP versions, so this has to be worded that an upgrade is permitted, not that they are equivalent).

[sebastiankb]

from today's TD call:

• group decided to merge this PR and have this for the WD
• it is not completed yet, after the WD release there will be further updates
• we need to resolve the conflict before before merge, @mmccool work on this and will merge it later

[mmccool]

Please see PR #1387: same content, noise eliminated.

[danielpeintner]

Shall this PR be closed since #1387 has been merged?

[mmccool]

Closing, replaced with PR #1387