SUIB problem Summary

Users who want to provision or manage an IoT device or router using a browser, will have to do this over untrusted or unencrypted connections. Within the domestic environment this means passwords and activities are exposed, to competent attacker on the internal network. It's good practice to communicate securely, but to establish an encrypted connection the browser expects a signed certificate. The certificate of a the device must have a unique address or hostname, before a certificate can be signed. A signed certificate requires devices to be dependably discovered, identified and addressed. Either the local network connection is not encrypted, or the devices serve a self-signed certificate which a user has to accept, which is a poor and for the user worrying experience.

Consumers are trained to accept certificate exceptions without explaining the difference in context between certificates used on the internet and self-signed certificates within a home environment. Device manufacturers have to work around this problem. This prevents HTTPS from effectively being used in household and industrial environments.

A browser can trust certificates when they are signed by a trusted authority. A certificate ties the public key to a unique DNS or IP address. Most devices do not have a globally unique address, instead they rely on private or link local IP addresses and generic Multicast DNS names. Without domain name infrastructure there is no unique address and certification authorities can not sign the certificate.

IoTSF is principally concerned with IoT. The SUIB (Secure Usable Intranet Browser) initiative has been formed to address this problem as it will exponentially grow as devices are added to local networks.

In order to meaningfully address this problem we need to consider the following dimensions:

• Addressing: How is a device connected to the network (e.g. ethernet), how is it addressable (e.g. IPv4) and how does it do name resolution (e.g. DNS or mDNS) The physical and logical addressing are a means for a browser to identify the local scope. The IP and DNS names are relevant because they are used by the browser to locate the device and in TLS certificates these are used as identifiers for the device. CA/Browser Forum uses the term "internal names" for IP and DNS names used in a local scope.
• Browser: Current browsers following CA/Browser Forum requirements show a padlock icon for certificates that are signed by a Root CA and generic security warnings are displayed for certificates that are not verified. How can a secure connection be established to local web servers and does this require a change in the browser?
• Certificates: For public internet certificate the browser behaviour has clearly defined TLS certificate management principles. For the local web server scenario, what changes are needed to make the certificate chain work.
• Device Onboading: how do the IOT devices get onboarded on the network and how does the browser discover connectable IOT devices

In the next few background sections, we outline critical techniccal knowledge which is needed to fully understand the outlined solutions.