Placeholder section on transport security #87
Conversation
| Consider mandating HTTPs, at least for things that are used outside of a closed network. | ||
| Some other standards, such as Echonet use HTTPS only. |
There was a problem hiding this comment.
nit:
- once "HTTPs" while the second time "HTTPS" with capital S letter
- ECHONET seems to be always capitalized
There was a problem hiding this comment.
What would mandating HTTPS mean in practice and what's the definition of a closed network? Is the idea that a conforming WoT consumer would simply have to refuse to communicate with a WoT device which doesn't use TLS? This seems a bit heavy-handed to me given there may be valid use cases where plain HTTP may be unavoidable (e.g. for local domains or constrained devices lacking the processing power for cryptography algorithms).
Perhaps a more balanced approach would be to strongly recommend the use of TLS and encourage user agents to inform users of insecure connections like web browsers do.
|
Note that one of the changes proposed in #78 is to add a security section to the Core Profile which defines security schemes which conformant Web Things MAY support and conformant Consumers MUST support. That goes beyond just transport security. |
The text in #78 is basically just a heading and a one liner. You could create a dedicated PR for that. |
mlagally
changed the title
|
See also w3c/wot-security-best-practices#13 which captures some discussions we have been having in the Security TF about local transport security (e.g. https on the local network) which is the hard problem here. Summary: it's hard to mandate use of https in use cases like local networks in the home, unfortunately. (Unless you assume a tunnel through a cloud service or use of externally visible URLs via DyDNS or whatever, both of which are not ideal for other reasons). |
There was a problem hiding this comment.
I don't think mandating HTTPS is feasible in a local environment, unfortunately. The situation is quite complicated, and I would recommend instead that we mandate "best practices" for security and defer to the WoT Security Best Practices document.
Generally: Security is important but does not directly impact interoperability, which should be our focus in profiles.
|
Don't think we can mandate HTTPS, so... I think we should simply defer to the security best practices document (which we are working on actively right now, and want to publish in the fall.) Note however it is informative, so the reference in "profiles" should be an informative recommendation. Do we have anything around security that affects interop? We do need to specify a specific set of security schemes. We probably do want to review the list and perhaps constrain them a bit. APIkey in particular is quite open-ended. But even OAuth2 has some variations e.g. on where the token is embedded. We should also perhaps disallow certain things like "in": "url" which is generally a bad idea, but is there for compatibility reasons (certain brownfield devices). |
|
Re mandating "HTTP-over-TLS - yes/no/maybe?": it should be considered that NETCONF (resp. RESTCONF) probably is a closer "neighbor" of WoT than HTTP with its origins and majority usage in IT ecosystems NETCONF mandates security in RFC 6241 (see https://datatracker.ietf.org/doc/html/rfc6241#section-2.2). NETCONF applies a security-always-on paradigm while Web applies a security-as-an-option paradigm From my perspective WoT security should make an explicit decision about the designated security paradigm in e.g. {security-as-an-option (opt-in), security-by-default (opt-out), security-always-on (no opt-out)} |
|
See #124 |
Preview | Diff
Preview | Diff