The real solution to this would be something like TLS-SRP where you can authenticate both sides of a TLS session with a zero knowledge password proof (devices could ship with a piece of paper containing the generated password, no need for central servers, remote connections to the mothership, gateways, or certificates, or exposing stuff to the internet, or even any internet connectivity at all).

In simple terms it allows you to setup a TLS session by both sides proving they know the secret password, without either side exposing it, thus MITM is unable to capture it, it is an alternative to the cert model that works very well for network local devices.

But of course Chrome and firefox both have zero interest in supporting this use case despite TLS-SRP kicking around for ages now, they'd much rather have you connect to your own devices via a mediated cloud gateway server, for your own safety of course.

Pre-shared keys are only good for bootstrapping a stronger trust relationship. You could use TLS-SRP to exchange identities and then mutually authenticate each other for the general case. X509 is not the problem. Centrally manager trust hierarchies are.

I’d rather see an ssh-style ask once and then trust forever after that.

Isn't this just key pinning? I'd like to see a P2P system. This way governments can't force CA's to allow MITM.

That's what you use the pre-shared secret to establish: longer lived identities.

I didn't see that post, but if you control the DNS for a domain you can use the DNS challenge with Let's Encrypt.

Most people dont control a domain.

Mozilla does though. So if their plan is to "offer subdomains on mozilla-iot.com" then they just need to set it up so that their infrastructure will fulfill the DNS challenge for the user's device when it requests a new cert.

Which itself raises several questions:

1. Should most people have access to a domain they control?

2. Should there be a standard for nonroutable / nonpublic domains? (.lan and .localdomain are two of which I'm generally aware)

3. How should browsers deal with hosts and/or domains which are not and can not be on the public Internet?

4. How the hell did we get into this mess?

I'm kicking around the notion of relaxing various aspects of the problem domain and seeing where we end up. It's mind-numbingly bad, though.

Also: if we don't use the domain registration system to proxy for individual sites and presence on the Internet, then what alternatives might be substituted?

Note that domains don't solve the problem of a third-party controlling your point-of-access or presence, they only move it elsewhere.

Maybe this is a problem.

I'd say that in the world we live in, getting a domain is as useful as getting a passport. It costs a bit of money to get and renew and is a bit of a hassle, but it opens a lot of doors.

Then you usually don't need a certificate from a CA. Just selfsign.

This seems like it's going in circles, but, if you selfsign modern browsers display a big scary warning. If you're making a device or software meant to live behind a firewall and to be accessed from a browser, users will either have to install your CA in their browsers, or deal with the big scary warning. Both of which are bad.

If you don't have a domain, chances are that you don't provide service to normal users. Or to users at all besides yourself.

> chances are that you don't provide service to normal users. Or to users at all besides yourself.

I think that's the point. Creating friction that scares normie users when people are using web UIs on local networks puts non-cloud based products at a disadvantage against the centralized giants.

Though there are a couple of technical options to make this work, the thing I realised many years ago is that if you want to use internet technology you need to be connected to the internet. Anything else is just an endless headache.

If you are sure that you don't want your IoT devices to be reachable from the internet, don't use the internet protocol to talk to them, don't use DNS, web browsers, etc.

Just create a new local protocol (or switch back to IPX)

It really feels like you're throwing in the towel. The internet is designed specifically to allow federation between forests of hosts. That's what routers do. Browser vendors need to get their heads out of the fucking cloud and stop coercing people into relying solely on global TLS. I think TLS is wildly misunderstood. The whole global certificate thing only works for global communication. Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships... to make informed decisions about the trust relationships you want to establish. Browsers need to facilitate this not do everything possible to prevent you from owning your trust. If your browser is only able to communicate globally that's not the internet's fault. It's not TLSs fault (TLS is designed to allow clients to choose who they trust). That a failure of your browser to support your diverse use case.

If you like tilting at windmills then go ahead. Since forever people have written software that assumes a global internet.

However today the situation is much worse. The global internet is a very hostile environment. Everybody who writes software that has to work on the internet has to assume the worst.

If there are modes in a piece of software that assume the network can be trusted, then you can be sure that some attacker will try to activate that mode.

You cannot assume that the users of a piece of software have any idea how the internet works. If they can solve an immediate problem by disabling security, they will.

So, over time just about any piece of software that wants to support secure use on the internet will come with built-in trust anchors that are very hard to change.

In browsers this trend is quite visible. But the same trend, though less visible is going on in DNS.

E-mail is a bit of a mess. But the basic features are there. Just not a lot of adoption.

To sum it up, users don't want to know about internet security. They want their devices to work securely at a random open wifi network. Devices have a hard time figuring out if they are in a trusted environment. So the best way forward is to assume all environments are untrusted and require encryption everywhere.

My issue was with you suggesting people abandon security if they don't want a public internet connection.

I think the global TLS system works great when you're in a global context. But now the internet has proliferated and it's infecting people's homes. It turns out people _don't want_ to be in that hostile global context when they're at home. They want a context that is private. They want to isolate their home from the firehouse of global bullshit out there.

I think we've passed an inflection point and we're seeing a revival of attention to home networking. Sure for the last 15 years all I connected to my wifi was my laptop and that's pretty useless without the global internet. But now people have IoT things. Door locks, ovens, toilet paper, you name it. Why the hell would anyone want those things phoning home to a remote server all the time? Why does it even need to be publicly routable? Maybe it does need limited connectivity so strong interactive controls allowing you to federate whatgoes in and out are necessary. More than ever the _integrity_ of your home is also the integrity of your network. Your network is an appliance now. It is the lifeblood of your home.

People deserve to be able to administrate their personal enclaves as they see fit and do it securely. The best way to prevent someone from remotely unlocking my doors is to eliminate the remote path to the door lock. Did you forget that we've come rather far in securing later 2? People _can_ and _should_ trust their home network. Not wrecklessly, but private networks are not a fairy tale.

Finally finally, don't patronize users. The users of today are tomorrow's grandmas. It's not unreasonable to expect we can slowly adapt user expectations and understanding surrounding the security of their software. I'm not saying you don't have a point, but I think it's a disservice to users to treat them all like idiots.

> They want a context that is private. They want to isolate their home from the firehouse of global bullshit out there.

With all due respect, over the past fifteen years of trying to secure corporate networks, we've learned the hard way that this simply isn't a realistic goal. Having a hard outer shell and a squishy center just leaves the entire network vulnerable, because it's simply not possible to isolate yourself from the badness of the outside world. As soon as you let anyone in who's ever spoken to the hostile outside world, they bring the hostile outside world in with them.

We can't keep pretending that we can keep home networks isolated from the rest of the world when many of the computers in those networks move freely between the global Internet and the private home intranet. All connected devices are part of the global Internet whether or not we want them to be, and whether or not their connections are persistent.

I think we're arguing similar things. I'm not saying we only need a hard outer shell. I'm arguing that we _need_ security in depth. And that depth should include all scopes of the internet protocol, not just global. You _should_ be able to run TLS locally so that if some global thing does get in, it now has to penetrate another security/application layer too. I should be able to tell my browser to trust these certificates for global IPs and these other ones for my home site. Why not run IPSEC in you home while you're at it too so it's even harder for a remote thing to pivot.

Fair enough, thanks for the clarification!

People can administrate their personal enclaves as they see fit. There are a number of operating systems that you can rebuild from source. You can just create your own root CA and add it to your browsers. You can run your own root DNS zone.

Most people have no clue about computer security and don't want to get one. Tomorrow's grandmas will know as little about how their computers are attacked as today's grandmas.

And they don't want to know. They want technology that is safe to use.

We know from experience that a network where devices trust each other is a disaster waiting to happen. So let's kill that model. All devices have to survive in the open internet. Because if they don't, somebody will figure a way to attack them.

I think we're talking past each other at this point. I want security both globally and locally. I want to be able to tell my browser who it should trust and what level of paranoid it should be in each context. If I go through the work of recompiling a bunch of software with custom trust anchors, I don't want it to all be for naught because in the last mile my browser says "I'm lost I only understand global TLS".

I LOVE the idea of NAT-less global internet. It's why I love IPv6. At that level anything that wants to participate should be secure and "go Chrome" for leading the charge. I even think firewalls for global IPv6 are stupid. If you're global you're global no amount of silly packet filtering rules is gonna change that.

But that's not the end all. I don't want my entire house to stop working because I got a new ISP and I have a few days of down time. Or more like because my ISP went down because they oversell bandwidth and haven't updated their routing hardware in 15 years. Maybe I don't want my file server with all my family photos globally addressable. Maybe I don't want my kids on the global internet at certain times. The point is I know what's best for my house. Im sick of the old IPv4 mindset where the only reasonable model is centralized global trust (see we agree that's been the status quo).

> Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships... to make informed decisions about the trust relationships you want to establish.

Explain more how this would work.

Part of setting up an account with a web service or iot device provider or whatever should be acquiring their certificate authority. However, instead of having a single bucket OS level root trust store, browsers empower users to whitelist the sites they trust that authority to well have authority over. You trust googles ca for google.com. Or maybe you don't.

At the application level, trust should be managed by the application provider and the user. Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. As a user you're either still using a browser or you've at this point switched to their native app or you've got their JS helpers loaded or whatever. Their application logic can manage all the certificate crap so that users are minimally encumbered by it. If you're talking to local network devices their application logic would issue certificates for whatever scope of IPv6 addresses you're using. Maybe your fancy device is running dns, their thing issues certs for your scope's site, etc.

You can even do mutual TLS now because their authority can issue installs of their app their own certificates. Browsers should support client certs too. Navigating to foo.com using a scoped IPv6 address? You're prompted to select the identity you wish to use. Your browser remembers your choice for that scope. The CA is only valid for your blessed names, scope aware.

> Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support.

But that means that other customers can get a trusted certificate for the exact same ip address, right?

> If you are sure that you don't want your IoT devices to be reachable from the internet, don't use the internet protocol to talk to them, don't use DNS, web browsers, etc.

What utter nonsense.

TCP/IP works fine on a local network

DNS works fine on a local network

HTTP(S) works fine on a local network

Web Browsers work fine on a local network

After all the internet is nothing more than a collection of connected networks.

If I have no need for anything within my local network (or subset of that network) to be routable from the internet then I put a firewall in the way, it doesn't mean I don't use the same tools and protocols.

Actually,

TCP/IP on a local network will make mobile devices think they are on a captive portal.

DNSSEC will prevent you from serving local answers for signed zones. The DNS root zone is signed. So the IETF at the moment has a hard time figuring out which zones need to stay not signed to allow these kinds of local answers.

HTTP is not secure, so that is going the way of telnet.

HTTPS is what we are discussing here. Without a valid cert, don't expect browsers to support you much longer.

Yes, you can create your own little internet island. But don't complain if any software fails to work in that environment.

> TCP/IP on a local network will make mobile devices think they are on a captive portal.

No, that's the phone doing a HTTP call to a server on the internet to try and work out if it's a captive portal, all TCP/IP still functions perfectly fine within an internal network with no WAN access.

> DNSSEC will prevent you from serving local answers for signed zones. The DNS root zone is signed. So the IETF at the moment has a hard time figuring out which zones need to stay not signed to allow these kinds of local answers.

The devices are on a local network, they're not making requests to things outside the network. Even if you do need outside access for resolution you can still happily use a DNS forwarder with your local DNS served up locally with any outside DNS (including DNSSEC) queries being forwarded where they need.

> HTTP is not secure, so that is going the way of telnet.

That's neither here nor there, it still works fine in the context of a local network.

> HTTPS is what we are discussing here. Without a valid cert, don't expect browsers to support you much longer.

A cert is as valid as my cert store thinks it is, again, still works on an internal network.

> Yes, you can create your own little internet island. But don't complain if any software fails to work in that environment.

By "own internet island" you mean a local network? Sure it's more advanced than your nan's local network but it's still a local network in which the IP part of TCP/IP still works absolutely fine. Maybe you come from the land where your mongo instance needs a public IP, or that your lightbulbs can be used to pivot onto your home network. I don't. This is basic network design. Maybe the shitty software/hardware you're running shouldn't assume it will always be connected to the internet directly.

Sure, as a power user, it can all be done. You can also manually trust a self-signed cert. I wouldn't recommend it for the masses though.

I was rebutting the blatantly wrong "don't expect IP to work". Yes it's not your mum's network, but then I never said it was.

But that's the whole point.

The goal is that you can build a device that your grandma can put at home, which never connects to a remote server, which she can connect to from her browser, which just works, never shows an annoying HTTPS warning, never requires enabling custom CAs, and provides all functionality of the browser, without being marked as "not secure".

That is the goal: All the functionality of e.g. a Nest device, without ever sending a single packet outside of your LAN.

(Disclaimer: For my own IoT projects, of course I use a special domain with DNS delegation and Let's Encrypt certificates, and HSTS preloaded)

> never connects to a remote server, which she can connect to from her browser, which just works, never shows an annoying HTTPS warning, never requires enabling custom CAs, and provides all functionality of the browser, without being marked as "not secure".

Right, do you have a proposal for how to accomplish this? If you don't want to require an internet connection, I think trusting a self-signed cert is the best way to go, otherwise owning a domain name + letsencrypt is good if you're ok connecting to the internet.

I don't think you'll be able to explain your grandma how to trust a self signed certificate.

The alternative would be HTTP, but that's "not secure" anymore.

There are situations where trust on first use or out of bands verification are the only option. This is one of them.

What I think could really do good is some browser-supported protocol specifically made for identifying devices on a LAN.

E.g., imagine some UPnP-style broadcast where a device announces a public key, human-readable name and some type/capability information. Browsers listen for broadcasts and show users a notification once they discover an unseen device. Once confirmed, they can identify the device by its public key and also use it to establish encrypted connections.

You could also define out-of-band methods to share the key, e.g. via an on-device wifi hotspot, NFC, a USB plug or a QR code printed on the device.

Mozilla's Web-of-Things spec seems to show at least a willingness to work on this. Though right now they seem to re-solve exactly all the already solved problems and tackle none of the unsolved.

...or you could simply treat HTTP in local networks as a secure origin and be done with it.

I agree, though instead of "public key" I would just say "self-signed cert".

> ...or you could simply treat HTTP in local networks as a secure origin and be done with it.

I think this is a lot harder than it sounds. What's a "local network". Is a coffee shop or public wifi a local network? How does the browser know? How do you know a rogue IoT device isn't doing ip spoofing?

Right, yeah, browsers are not guaranteeing any security on the local network.

If self-signed is not an option, then I think an internet connection and domain name are required. (Which seems to me is totally fine. That's the whole point of IoT)

I totally agree. Either have it securely connected to the internet, or not at all. The fact that something is on your LAN is just an implementation detail and shouldn’t be relied upon for security.

Is the fact that your physical door locks and keys are only unique to your local region very much an implementation detail? No it's not. It's conceptually the same, but keys and locks are not globally secure. They're only locally secure.

Also IPv6: everything gets a globally routable address. Great so why do we need anything else? Well it turns out that in order to support all the different modes of network operation and all the different topologies and use cases, the Internet Protocol needs to support non-global scopes too. Arguing you can't have e.g. link-local security is absurd and rally quite green, from a networking professionals perspective.

Oh also IPSEC is part of IPv6 not just an afterthought like it was for IPv4. This makes it even more likely we'll see trusted network scopes sooner rather than never.

> It's conceptually the same, but keys and locks are not globally secure. They're only locally secure

Criminals in Hong Kong can’t teleport to my door. Local security for locks is fine because the threat is always local.

> Criminals in Hong Kong can’t teleport to my door.

They might be able to hijack a different IoT device on the network. The more IoT devices, the greater the attack surface.

What if you have guests over and they happen to have a bad virus on their computer or their phone?

That is basically my point. People need to have ways to create local enclaves so it's impossible for packets to ever make their way into your zone. And wonxe you do that, local security is perfectly reasonable and desirable.

HTTPS only protects data in transit from the server to your device. A local network work just fine for providing the same protection. It's not like an internet attacker can spoof a 192.168.x.x address on my LAN, or sniff the traffic to or from my server.

Possibly a rogue IoT device could spoof an ip address. But that's probably not going to happen to someone who knows what they're doing. Browsers don't know if the network is trusted and can't assume that LAN IPs are safe.

It seems to me the best options are either trusting a self-signed cert (on every computer that needs access) or pay for a domain name and use letsencrypt to get a cert. I do think it's unfortunate that you now need to pay money just to do things like this on your own network, but I don't see a better way. It's either paying for a domain name or needing to explicitly trust the device.