So, are you suggesting to buy domains even for isolated networks? And then for this to work you need to connect to the internet just for DNS lookup?

In order to be assured of something's identity, it needs an actual identity to be assured of. For things on the network, this will usually be a DNS name, so we should give them a DNS name.

You don't need to buy "domains", but certainly for a commercial project that makes loads of things which need names it would make sense to own a sub-domain to put all the names in.

You also don't need to "connect to the internet just for DNS lookup" unless you really want to. The point of using DNS names isn't that you can look them up in DNS, it's that they're are a unique hierarchy with a central authority.

There _are_ alternatives to DNS names but none of them have a trustworthy and working PKI today so you can't use them to secure anything you build. Maybe building a trustworthy PKI is hard?

If you insist upon using Let's Encrypt (which is a charitable purpose and so charges $0 for certificates) perhaps because it's actually a hobby project then yes, somebody would need to control DNS records in order to periodically prove control over each name and get issued a certificate, because that's how ACME (the protocol Let's Encrypt use) decides whether to issue.

Many other public CAs are for-profit companies and several already have _active_ commercial deals in which they issue certificates for devices in bulk to the name owner. If you're EXA Metal Poles Europe and you're making 50 000 devices named in the range pole0000.foo.example.com through poleFFFF.foo.example.com they are quite happy to issue you, the legitimate owners of example.com with 50 000 certificates for those devices in exchange for money.

At some level, a certificate is an identity. If I’ve trusted a cert then I know that anyone using it has the private key, no matter their IP or dns name. Being able to do that for a local device would be very nice—I could connect to whatever up it dhcp-ed to and be sure I was talking to the right thing.

That deserves a hard stare. If I trust the certificate on my chat server to be _the certificate for my chat server_ that doesn't suddenly make it OK to present that certificate if you're claiming to be my bank, or my operating system vendor, or Hacker News.

The local device should have a _name_ and then we can issue it a certificate for that _name_ and know we're really talking to the same thing as last time. DHCP and other address allocation protocols don't (needn't) change the name.

I think we should just take the same approach that I2P and Tor take for naming, and base the domain name on the public key. Local devices automatically get a domain like gmaf2cgbn3q2be3vaaytrev3qyxcksemkdxtzefq5bl3542uyf3q.local, which they can advertise via mDNS, and the browser accepts a self-signed certificate for a public key which matches this fingerprint just as if it were "domain validated".

The domain stays the same so long as the key does, so the user can bookmark the page for their own device and be sure that when they navigate back to that domain they're getting the same device and not some imposter—effectively making this equivalent to "trust on first use".

Edit: Changed "on the certificate" to "on the public key". It might be necessary to regenerate the certificate periodically, e.g. to update the expiration date, and that shouldn't affect the domain name.

No, you can use a local DNS server or put the DNS entries in your host file. No need to use the internet for DNS lookup.