Update Secure Local Transport

[mmccool]

General issue with using HTTP on local networks, given fact that TLS doesn't work with browsers don't gracefully accept new certs. You can use TLS with preshared keys on a local network, or install a cert to use a browser, but can't just ad-hoc access dashboard.

To do: talk with Ben Francis (@benfrancis) about what best practice makes sense here. Right now they are using a password with plain HTTP and relying on network security (i.e. WEP). This is a MINIMAL solution, but obviously not ideal. Perhaps we should discuss this as an option but is not ideal. A question is whether dashboards are relevant to our specs; it should (probably) be discussed in architecture, when we talk about (smart home) hubs, where (a) users are not professionals and may not be comfortable installing a certificate (b) users/developers want to use a browser as a UI, hosted by the hub. You could also install an app that could basically just be a specialized browser with a built-in certificate.

[benfrancis]

Currently the recommended way to access WebThings Gateway is via your own custom subdomain over HTTPS. The WebThings remote tunnelling service makes this very easy for users to configure during first time setup, they just choose a subdomain and it's all set up by magic. When I say magic, I mean that it automatically registers a _.webthings.io subdomain, configures DNS, issues a TLS certificate signed by LetsEncrypt and provides a dynamic, tunneled reverse proxy to safely provide remote access to your gateway behind your firewall without needing to forward ports on your router using NAT.

The limitation of this approach is that if your internet connection goes down you can no longer access the gateway on your local network using the remote domain. This is why as a fallback the gateway also broadcasts a .local domain on the local network using mDNS, which can be accessed via plain HTTP (since serving the _.webthings.io TLS certificate via gateway.local would cause a security warning).

We have found this approach works quite well, but it does mean:

1. Having separate local and remote domains
2. Accessing the local domain over plain HTTP

We have tried many different approaches to providing TLS over the local network but unfortunately none of them have worked. See my comment at w3c/wot-security#185 (comment). We are therefore waiting to see what comes out of the HTTPS in Local Network Community Group.

You could also install an app that could basically just be a specialized browser with a built-in certificate.

We have long talked about creating a native mobile app for WebThings which acts as a general purpose WoT client in order to make discovery, first time setup and local security easier to solve. But generally speaking I'd say creating a "specialized browser" is almost certainly a bad idea. Keeping a web browser secure is not a trivial task.

[mmccool]

The tunnel approach of course works but does not solve the actual problem of secure local access, unfortunately. We discussed PR#21 on July 19 in the security call and agreed that it covers what you SHOULD do if what you want is secure local access. The problem is it still requires the user to install keys, and furthermore not all browsers (including notably, iOS Safari) currently support it (see https://docs.w3cub.com/browser_support_tables/tls1-3 for a list of status by browser). Consensus/Analysis:

1. We should recommend TLS 1.3 - when possible (which is all PR#21 says). But it only solves part of the problem; still need to distribute keys.
2. We should add some discussion around fallbacks, even if they are less secure.
3. It would be great to get some input from the "HTTPS Local" CG, but so far there is no solid recommendation.
4. We definitely need to look into this more and see if there is a way to fill the gaps. For example, the "onboarding" service could allocate keys that could be used to allow the browser on a phone to communicate with local devices onboarded into the same security domain.
5. We do some more research into other options: NETCONF/YANG; BREWSKI in CoAP; in IETF

So we'll merge the above PR, but it's only a start.

[mmccool]

Updated title to focus this issue on local transport. We may, however, want to add something for tunnelling, etc. later.

[mmccool]

See also w3c/wot-security#161 - DIDs and VCs.

[mmccool]

Discussion:

• NETCONF has a clear definition of "secure transport" which is useful. Be should not be ambiguous, for example, expectations around mutual authentication, encryption, etc. Examples: SSH tunnels, TLS 1.3, etc.
• Would be useful to distinguish "key distribution" from "secure transport" but we have to decide where certain parts go, e.g. mutual authentication.
• Also the question of managing permissions (access controls); see to review NETCONF RFCs: RFC6241: Update Secure Local Transport #13 section 2.2, have statements like "The authentication process MUST result in an authenticated client identity whose permissions are known to the server." which is not necessarily true for Web; NETCONF is however about network config, which is perhaps closer to IoT. However, there might be anonymous access scenarios for IoT also.
• There is also RESTConf...
• Original intent of @Citrullin was to support a secure PKS key distribution systems (eg. an onboarding process) and knowledge of keys owned by a token server, and then the token server is used to manage access by users.
• Want probably to be able to target the problem of a large number of users and large number of devices, and being able to manage different and dynamic permissions for different users. (requirements)
• Can't go and change devices every time a user is added or their permissions are changed.
• Are there existing best practices for key distribution? CA is one such system, but requires that servers have a public URL and also have active internet access (to check for old, cancelled certs). LDAP is another possibility (but this is just a distributed directory; CAN hold keys, but is not itself secure, information would have to use a secure schema, encryption, etc.; but could run LDAP over TLS).
• What do people actually use, e.g. in industrial use cases? LDAP is more of an IT, not an OT technology. The question as to what OT already has... well, nothing. Typically proprietary, owner explicitly manages keys. A paper: https://dl.acm.org/doi/10.1145/3372020.3391555
• Probably should define some terms/categories/modules, and then some suitable options for different "modules" e.g. for secure transport and for key distribution.
• Problem with TLS 1.2 is can't (in practice? generally?) use raw public keys... so not as modular. (@OliverPfaff will check, thought it was available earlier). Then there are various browser issues: not all support TLS 1.3, making it a non-starter for some use cases.
• Use cases for browsers: for accessing public urls. Related to how we deal with proxies, tunnels, etc. Also reverse and forward proxies. Perhaps we simply say "if you want to access a system through a browser, need to access system via a public URL secured by a certificate." Then we simply have to discuss the privacy implications.

[mmccool]

Action: add a reference to this issue to this section in the document. That should pull in this issue's description and link to this discussion. I'll do this.

[mmccool]

Will also update the opening description so it makes sense in the context of the document.

[mmccool]

SOME browsers may support import of raw public keys and/or integration with PKS systems. If one exists, then (probably without naming names) we can give this as an option in environments where putting public URLs for accessing private devices is not desirable (not just the home, but critical infrastructure, factories, etc. too).

[mmccool]

OK, I added an ednote. I wanted to add an "issue" class div but there is a bug in respec so it generates the wrong URL, so I linked this issue manually.

[mmccool]

So, in OPC-UA use-case/liaison call today we discussed the OPC-UA security key distribution system, and apparently it can be used also to distribute and manage keys for web servers. So that might be an option for factory automation use cases.

[mmccool]

Another idea: DID supports key distribution, and also multiple methods. What if there were DID methods that could use LDAP, OPC-UA, etc. under the covers for key distribution?

[Citrullin]

Another idea: DID supports key distribution, and also multiple methods. What if there were DID methods that could use LDAP, OPC-UA, etc. under the covers for key distribution?

That is a very interesting thought. So we would recommend to use only DID, and the DID spec has to define a method for all those different methods. That would keep it very flexible for us and focuses the actual security specification, implementations etc. to them. I find this an extremely good idea. Even though we would need to get in contact with the DID WG in order to figure out, if they would be interested in something like this.

[mmccool]

See also issue #14 on object security; in this case also, a crucial factor is key management. However, let's focus this specific issue on key management for transport and the other issue can focus on object security.

[mmccool]

Followup:

• DID looks like a good path, but we need to look into current implementations and how secure they are.
• It would be useful (possibly) to allow DID URLs to be used to refer to keys generally, e.g. for TD Signatures and object security. We need to investigate how appropriate this is.
• Use of DID should be for cases where regular mechanisms, i.e. CA, are not appropriate/broken. The exception might be where DID is just a wrapper for CA.
• Note that DID is a PR, and so has an implementation report: https://w3c.github.io/did-test-suite/
• We probably need to talk to some DID people to select an appropriate method for testing, some may not be appropriate for local networks.
• We/somebody may also be able to define a DID wrapper for existing local key distribution systems if no existing method is appropriate

[mmccool]

See discussion (and potential resolution) under #14