CryptoName implementation overview

This document serves to organize and persist the options, variations, difficulties and partial solutions of the cryptographic-names approach. In that, it complements https://github.com/chrysn/provisioning-demo, and can provide bits and pieces that (when decided on) can migrate into the Solutions document in prose

---

• Spectrum of offline-ness

  • All on the Internet
  • UA on the Internet, device firewalled
  • All offline

• Using at- vs. dyndns

  at-${IP} is nice as it keeps things easy, but it makes the address even longer and means that "print the address on a paper slip with the device" (which is produced after the device generated its key during the initial self test) does not suffice.

  • dyndns works for both all-online and all-offline.

    (Or, more precisely, the all-offline case needs a special resolver in the browser or router anyway, and once we do "special" it can do mDNS right away and not only at- resolution).

  • dyndns does not work for the intermediate "UA on the Internet, device firewalled" case.

    Do we care enough about that case to work the at- case out in full?

  • The dyndns approach is sensitive to caching. On the authoritative side we can keep lifetimes low, but

    • this may bite users just fiddling with their network, and
    • caching DNS servers in routers may unilaterally extend short lifetimes (not sure if done, research needed).

• How to name the certifcate hex part

  • Can decide this late.

  • Options:

    • Roll our own multihash scheme as in original rdlink

    • Use something that comes out of the COSE identify-by-key discussion

    • Use what TLSA is doing right now (hash key, don't provide algorithm) -- this is currently implemented but easy to change.

• How to find the parent domain -- probably a fallback chain that should contain all of

  • Hardware vendor's preset

  • Some generally operated servers (IoTSF? EFF?)

  • Locally advertised domain

  All of these can equally use DNS-SD -- so (say) _certbyhash._tcp.vendor.com will be tried first, then _certbyhash._tcp.iotsecurityfoundation.org, then _certbyhash._tcp (inside whatever the current DNS search path is).

  This ensures that a company that doesn't want any device to phone home can just reject DNS lookups to _cerbyhash._tcp anywhere (or, more likely to be effective, block the IoT devices from reaching out altogether -- that too needs to count as failure), and then have their own _certbyhash service that gives the devices names like hexhexhex.untrusted-devices.in.company.com.

• What can go wrong?

  • In IPv4: rebind protection.

    Some local DNS servers outright refuse to forward some-name.example.com IN A 192.168.0.1 or any other private address.

    Test this at home trying to look up at-186gqso.hex-key.devices-test.amsuess.com, should be 10.13.13.115

    Mitigations:

    • Use IPv6
    • Configure DoH in the browser
      • Not quite: Firefox's "network.trr.allow-rfc1918=false" default means that the browser effectively does rebind protection internally.

    This is serious trouble, and might mean we can't reach these addresses as long as local rebind protection is on. (DoH, at least in Firefox, falls back to the local resolver).

  • In IPv6:

    Many browsers don't even try AAAA records.

    For example, in Firefox with DoH on, " network.trr.skip-AAAA-when-not-supported=true" is the default.

    (Not sure what it does outside DoH situations).

    Mitigations: Get this default out of browsers?