Skip to main content

DNS Based Device Name - Embedded Physical Address

This method avoids changes to the current browser and CA/Browser Forum policies. The Device DNS Name provides an approach to globally resolve a DNS name for each provisioned IoT device that resolves to a local address. Because this gives the device a global name, it is possible for a Certification Authority to sign the certificate under the current CA/Browser Forum rules. A pre-condition is that the browser recognises the signing CA and the device domain name can be validated by the signing authority.

It is designed to be extensible to fully-offline versions, which may not need CA/Browser Forum alterations.

This method requires encoding enough data in the name that both the address and the device's cryptographic identity are expressed in the URL.

The device can build the name it announces based on the local network situation. A web service between the device and any ACME compatible CA (like Let's Encrypt) can verify the identity, and thus have a valid global certificate issued.

Names can be issued under the domain from the web service. In the example below vendor.example is used as a domain name. A device has a cryptographic identity and forms an identifier from it (in examples we are using f0ocrypto1d; actual names are longer).

The device then prepends it's assigned IP address. This might be a global IPv6 address, but IPv6 ULAs and IPv4 local addresses work as well. The IP address is used as a second identifier, say c0a80001; actual identifiers for IPv4 will be shorter and for IPv6 longer.

The first option creates a device name as a concatenation of the physical address of the device and a bound domain, where the bound domain will resolve using normal global DNS resolutions methods.

Name Syntax​

The BNF (Backus-Naur Form) syntax representing such a name is as follows

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

// local address is IPV6 ULA or IP4 Private network address
<local-address> ::= {fc00::/7} |{172.16.0.0/12} | {10.0.0.0/8} | {192.168.0.0/16}

// 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> ::=  {}

This produces example device names of the form:

https://c0a80001.f0ocrypto1d.devices.vendor.example

Where in this instance:

  • c0a80001- is the physical address of the device.
  • f0ocrypto1d- is the device ID - or more specifically the hash of the public key for the device.
  • devices.vendor.example - is the bound domain - a publicly resolvable IP address.

Name Provisioning​

For the above approach to work, there needs to be a provisioning event, where the <dev-id> is bound to the <bound-domain>

The pre-condition therefore is that a device is provisioned with a bound domain and a credential when the device is in the factory. Ideally the system would also cater for multiple bound domains, where device identities can be hosted in the DNS infrastructure of multiple parties. e.g.: original manufacturer, redundant resolver, distributor or another intermediary.

There are a number of scenarios to consider:

  1. Manufacturer provisioning: the device is provisioned in factory within the administrative domain of the original manufacturer.
  2. Service provider provisioning: the device is provisioned before point of sale within the administrative domain of the service provide (for example an ISPs address).
  3. Intermediate provider provisioning: the device is provisioned at some point in the sales cycle with a manufacturer/service provider independent domain (for example a CA).
  4. User defined provisioning: the device is provisioned past point of sale within a home domain defined by the end user.

In order to assure continued functioning of a device in the situation where the manufacturer or server provider no longer operates the bound domain service, manufacturers should be encouraged to create models which allow for simple user provisioning or back-up provisioning flows.

In the examples that follows, we will use devices.vendor.example as a concrete instance of bound domain.

Assuming the bound-domain has been provisioned, in order to make use of the "Device DNS Name" solution, the IoT device must undergo a one-off onboarding provisioning flow. This may occur in the facturer or could occur upon device first power on if some other credential has been provisioned.

sequenceDiagram IoT Device->>IoT Device: 1:Create key pair IoT Device->>IoT Device: 2:Create common name Note right of IoT Device: [local-address].[dev-id].devices.vendor.example# Note right of vendor.example authoritative DNS Server: *.[dev-id].devices.vendor.example# IoT Device->>vendor.example authoritative DNS Server: 3:Register wildcard but device specific record on the DNS IoT Device->>CA Processor : 4:Generate CSR (using *.[dev-id].devices.vendor.example) CA Processor->>CA Issuer : 5:Send CSR CA Issuer->>CA Processor : 6:Return certificate CA Processor->>IoT Device : 7:Return to device IoT Device->>IoT Device: 8:install certificate on local webserver

Security Considerations

In this provisioning flow, steps 3 and 4 need to be protected. The device has to be provisioned in the factory with some kind of credential that it can use to authenticate to each system. As both services can be run by the manufacturer, this can in the degenerate case be done by the manufacturer. For other situations, some other credential is necessary to be added during an onboarding process, such as BRSKI/RFC8995.

Name Resolution​

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

The user is expected to be in possession of the <local-name> (discovery) in order to initiate this process.

sequenceDiagram Browser->>recursive DNS: Request IP using device URI recursive DNS->>authoritative DNS: DNS request across Internet Note right of authoritative DNS: Device URI: [local-address].[dev-id].devices.vendor.example Note right of authoritative DNS: DNS server resolves address by using the embedded [local-address] authoritative DNS->>recursive DNS: name mapped to local IP recursive DNS->>Browser: IP resolved in browser Browser->> IoT Device: HTTPS request created target IP address, using device URI as common name IoT Device->> IoT Device: pre provisioned cert used to negotiate IoT Device->>Browser: Certificate is validated in normal way, using browser root CA's

Name Validation (Security)​

This approach has the advantage that it can piggyback 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, but that of course will require some changes to the browser to implement.

Rebinding Attacks (Security)​

The IP address which is returned through this process may appear to be a rebinding attack by a recursive DNS server. At the time of writing in early 2022, IPv6 ULAs not typically filtered by rescursive DNS servers. It is unclear if this is a bug that will get fixed, or a feature that we can count upon.

Current DNS over HTTPS (DoH) do not appear to filter any local addresses out of DNS replies, but this may also be a bug.

If there is IPv6 GUA present in the home network, then the device can use IPv6 GUAs which should never get filtered.

DNSSEC​

This solution leverages the use of a wildcard on the leftmost side of the QNAME. This is compatible with DNSSEC signing, the records can be updated and signed when the name is provisioned by the operator.

IPv6 support​

This solution works for IPv6 as well as IPv4, but the names for IPv6 are significantly longer. Many bits could be elided for IPv6-Link-Local addresses, but not for ULAs or GUAs.

Implementation Notes​

This approach has undergone some initial prototyping, see:

https://github.com/chrysn/provisioning-demo

Some implementation notes have been documented here SUIB-solution-cryptoname-details

Interim Analysis​

Draft comments
  • PLUS: uses existing certificate and DNS mechanism
  • PLUS: requires no change to browser
  • NEGATIVE: rebind problem discovered in trial means it does not work on some current routers
  • NEGATIVE: requires manufacturer to create new DNS services and CA services
  • NEGATIVE: it could create long term commercial binding between the device and the manufacturer (the additional manufacturer hosted servers will need paying for)
  • NEGATIVE: if the manufacturer's authoritative DNS is temporarily unavailable, then communication may fail. But long time to lives are possible, and DNS caching should deal with most issues.
  • TODO: think carefully though the provisioning, both technically and commercially
  • TODO: think carefully though the security needed to issue the certificate
  • TODO: how does the user know what link to click in. How does local name discovery work? Could be problematic for roaming IP addresses.