Certificates for subdomains of LAN IP addresses using embedded asymmetric keys?

Feature Requests
1

One of the big problems with HTTPS is that it's inherently tied to either the public domain name system, or to manual configuration.

This becomes a problem for the internet in general, because things like local network IoT automation controllers for consumers can really only work via some kind of cloud service, or through an app, generally using some kind of proprietary protocol. Many things that are technically possible, just aren't convenient enough, and as a result, there's a huge barrier to self-hosting anything.

One obvious way to solve the "Nobody uniquely owns a LAN or localhost IP" problem, would be to create subdomains that work like blockchain addresses, which CAN be uniquely owned, just without the blockchain.

Suppose a URL could be created based on the hash of a public key. The "owner" of the address is the person who generated the private key, and they can prove it with a simple challenge-response. If you own the key that is embedded in the domain somewhere as a base64, you're almost certainly the one who generated that domain.

After this, they can print a QR code, and invite visitors to a purely local URL like "cafemessageboard.KFmKmryaRbSL1SYhPCD7Jw.192.168.5.6", with all the HTML5 awesomeness, right on the local machine.

The same process applies to subdomains using dynamic DNS services, or static addresses on mesh VPNs like Yggdrasil and CJDNS, greatly expanding the usability of self-hosted software, and it also allows for true localhost cerrificates, should there be a need for something like that to simplify testing.

Since there is essentially no possibility of collisions, it would seem the only big security risks are the same user error issues you get with any web tech(or any tech at all!).

Another benefit is that, were the feature to ever be widely used, browsers could eventually trust self-signed certificates using the format, without any load at all on Let's Encrypt's servers, and devices could generate their own keys, certificates, and domains, fully offline.

With more and more things just dropping support entirely for unencrypted traffic, I think the time is now to start the conversation on the question of securing the local network, without limiting people's capabilities, and I'm sure there are still way too many internal systems out there that should probably be secure, but aren't.

Thanks guys!

2 Likes
2

cafemessageboard.KFmKmryaRbSL1SYhPCD7Jw.192.168.5.6

DNS explicit forbid all numberic TLD, that's not a valid address. Browsers won't go anywhere. you will need to make a gtld for safe lan use first.
while that kind of addressing works it has additional problem for free certificate context. it's not rate-limitable.
Because you can create as many private key as you want, those addresses will overload LE infra quickly. same problem as onion addresses

2 Likes
3

Welcome to the Let's Encrypt Community, Daniel :slightly_smiling_face:

Firstly, let me thank you for contributing to the discussion here. Whether we agree, disagree, or somewhere in between, open discourse is valuable.

You present an interesting argument. I might have a roundabout addition to it. I know that URLs are possible as SAN identities. Rather than owning subdomains of IP addresses, what if you owned a complete URL of an IP address? So long as the public IP address is certified (which is already on the Let's Encrypt todo list), a simple extension would be a certified URL at that IP address. Your LAN devices could then be mapped internally as you will using rewrites.

For example:
a.b.c.d has an IP SAN certificate
a.b.c.d/mydevice has a URL SAN certificate
a.b.c.d/mydevice -> w.x.y.z internally

This could also work with a certified domain name instead of an IP address. Both still place the burden on Let's Encrypt, but could feasibly be rate-limited.

4

You are right, the essence of OP's post sounds a lot like Tor or i2p addressing, but weaker (unauthenticated label and IP). Let's Encrypt plans/had planned to eventually issue certificates for onion addresses, rate limits notwithstanding.

I hope that cryptographic addressing does not become commonplace in browsers. It has too many rough edges as a mainstream replacement for DNS and WebPKI. I don't reckon that avoiding the problem by saying "I'm not participating in public DNS anymore" would serve the ecosystem well in the long term.

DANE is another established technology which can provide a partial solution by creating a binding from public DNS to e.g. the public key of a self-signed certificate (TLSA 3 1 1), which cuts CAs out of the picture entirely while allowing secure communications. It is just a pity that it's really only widely supported for SMTP and browser buy-in is not there.

3 Likes
5

A topic on DANE and the upcoming roots:

6

Thank you for the warm welcome!

It seems there are some real concerns about LEs capacity to keep up with this stuff over time.

Perhaps a proof-of-work scheme could be used for rate limiting? As certificates only rarely need to be renewed, even something that takes multiple minutes is perfectly fine once every few months.

It wouldn't help if billions of products suddenly starting issuing automated requests, but I find it very hard to imagine that would ever occur, because if there was that level of industry demand, we would probably see web browsers just natively supporting crypto URLs.

As for DANE and the issue of crypto URLs in general, I definitely agree that public DNS names are the way to go 99% of the time, but ultimately, they cost money and require some level of manual configuration, and can't be set up in airgapped networks as one might find in developing nations.

We do already have a TLD for LANs, .local, it just isn't properly supported by Android for some unknown reason (Even Win10 supports it!), if you wanted to go the "Own the entire domain" route and only focus on the smaller scope of LAN-only functions.

2 Likes
7

@jsha

If you're still around, this topic may be of interest to you. :slightly_smiling_face:

2 Likes
8

I think @_az had a very good take on this - this scheme exists in Tor, in the form of onion addresses, but it's not a great fit for the public Internet. Also, if a scheme were truly self-authenticating, no certificate authority would be needed at all - just browser support.

I agree with you @EternityForest that we need a better system for authenticating and encrypting communications on the local network. No one has found a really great solution for this yet.

You might be interested to read about Zooko's Triangle, which says that network names can be at most two of [human-meaningful, decentralized, secure].

PS: Welcome to the forum!

2 Likes
9

I never knew about this! :astonished:

It reminds me of the CIA triad of [confidentiality, integrity, availability].

We call these triangular simplexes in the linear programming/optimization world.

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.