Browser background
TODO
Not reviewed yet
The fundamental challenge we are trying to address in this initiative is how can we use the browser to connect to, administer and configure endpoint devices (including the router itself). This is already and established pattern of behaviour in the market, however most implementations use unencrypted connections or are hard to use.
The solutions to this problem come in two major variants:
- No browser changes: Use the existing DNS and CA infrastructure and well-understood security semantics, creating new flows and behaviours, that address our problem requirements without any changes to existing browser behaviour.
- Customised browser: more substantive innovation in addressing methods and the negotiation of trust relationships that will inevitably require browser changes.
The alterative to using the browser for the administration functions is, of course, for device manufacturers to develop and maintain custom applications, which the user would need to add to their smartphone, along with apps from every other manufacturer or ecosystem.
Pragmatically, however, any innovation that requires significant changes to existing browser behaviours will initially need to be demonstrated on dedicated customer browsers to show the benefits of innovation. Impacted browser behaviour at scale, and in an interoperable way, will inevitably require coordination with the relevant standards body, in this case the CA/Browser Forum.
No browser changes
Solutions which require no change to existing browser behaviour are desirable because these have minimal impact on the end user. Drawbacks to this class of solution include:
The user cannot easily distinguish between local connections and internet connections (that would require UI changes to the browser). This is potentially significant to the security semantics of IoT end point devices.
Because Multicast DNS does not always work reliably, additional infrastructure would be needed to locally address an endpoint device. This means any solution which has no change to the browser will have at least a partial dependency on DNS resolution, at least in the bootstrap binding phase.
Changing browser behaviour
An alternative and/or complementary solution could be the development of a dedicated IoT browser, which would be independent from the CAB Forum infrastructure. This would leave the internet certificates unaffected and would introduce similar certificate processing semantics for the IoT use case.
Vendors often offer mobile apps because they implement their own certificate validation independent of the Root CAs. This approach requires an application for every device or service. A dedicated IoT application can bundle these services for a simplified user experience.
- It requires different user behaviour. The user will have to explicitly download and use a new class of browser in order to benefit from these new features.
- Needs to be designed from the ground up.