DNS Based Device Name - Dynamic DNS resolution

Name syntax

The second flavour of locally resolvable name does not use an embedded physical address. This method must use some form of DynDNS for resolution:

<local-name> ::= <dev-id> "." <home-domain>

// dev-id is hash of device public key

<dev-id> ::= {}

// bound-domain is a publicly resolvable domain name, with which the device is provisioned

<bound-domain> ::= {}

Alternatively, it can announce itself with the equivalent HTTP URI, and (once contacted by a browser that has Internet connectivity on its own, even though not necessarily simultaneously) utilizes the browser to obtain such a certificate.

This needs no more cooperation from the browser than regular JavaScript execution and can result in a redirect to equivalent HTTPS URI and thus the green padlock moments later.

This is likely achievable with current browsers. For an extended version that works even in fully offline situations, this can be adapted to a domain that promises to use the web service's policy.

Some user stories, details and the first stubs of what can become a tech demo can be found at GitHub - chrysn/provisioning-demo.

The provisioning flow for the DynDNS variant is almost identical. They only difference being is that the DNS registration and the Certificate request can be made using:

[dev-id].devices.vendor.example

instead of:

*.[dev-id].devices.vendor.example

In other words, it is not necessary to register the wildcard because we are not prepending the physical address to the device name.

The provisioning can happen automatically when an unprovisioned device is connecting to the network. This would limit the used interaction for the first setup.

Name provisioning

The operational flow is trigged, every time the user initiates a browser session with the target IoT device.

The user is expected to be in possession of the in order to initiate this process.

whenever the physical address of the IOT device changes

Name resolution

Device DNS Name : operational flow - DynDNS variant

When using the DynDNS variant there are two parts to the operational flow:

1. A flow initiated by the IoT device when the physical IP address changes (including the first time it is used).
2. The flow initiated by the browser when connecting to the IOT device web server.

DynDNS resolve

The DynDNS resolution method differs from the embedded local address; the DNS server uses the "most recent" physical address supplied by the DynDNS server instead of using the local address embedded within the device name.

Name validation (security)

This method has the advantage that it can piggy back on top of existing HTTPS certificate semantics and certificate issuing methods.

The issued certificates could make use of Key Usage and Extended Key Usage fields, so that local connections could be differentiated in the browser

Analysis