That's a valid answer for an audience familiar with computer networking concepts. It's a silly suggestion for consumer IoT customers, who do not understand those concepts. They don't know what is or is not 'on the open internet'; they buy a product at the store and plug it in.
> We should have certifications that devices create no outbound TCP/UDP flows.
This is the "bury your head in the sand" method of solving the problem. If you design your requirement so that zero consumer accessible devices are capable of meeting them, then what's the point? As long as people (1) want to watch their camera away from home, and (2) don't have the networking expertise to configure a remote access VPN tunnel, the devices are going to have to reach outbound to traverse home router firewalls.
IoT customers by default would not have devices exposed to the Internet. This has been the status quo for decades ever since wifi and NAT became popular. If they don't understand it, it will be secure by default.
It would be technically quite easy for either a dedicated home-access box or just the router-AP combo box to have some auto-config wireguard setup (e.g. scan a QR code or install an app that looks for the box on the local network or through bluetooth). This would be far more secure than the current setup, which is for devices to constantly connect to generally malicious C&C servers. If regulations pushed for actual security (no-cloud), this would be the obvious solution to guide to market toward. Then you only have to trust your gateway device, which also would have no reason to ever create outgoing Internet connections, though it would need outgoing/forwarded LAN connections.
With SLAAC to generate a random initial IPv6 address that it never rotates combined with UDP so there's no indication that you talked to anything if your wireguard keys are wrong, there's basically no way to find such a box if you didn't have the correct config.
> IoT customers by default would not have devices exposed to the Internet. This has been the status quo for decades ever since wifi and NAT became popular. If they don't understand it, it will be secure by default.
Because IoT devices have historically been known as secure? Definitely not. Devices that presume someone else has already configured a firewall correctly often presume wrong. Consumers are not networking professionals.
> It would be technically quite easy for either a dedicated home-access box or just the router-AP combo box to have some auto-config wireguard setup
Well yeah, if everything about home networks was different, then the situation would be different. The problem is, that isn't the reality in which IoT devices are manufactured.
> If regulations pushed for actual security (no-cloud), this would be the obvious solution to market.
If they pushed for this, the only solutions with the sticker would be ones that are commercial failures because they won't work out of the box with the router people actually have at their house. You may be 'right' but your labelling program will have failed. A labelling program has to be realistically achievable within the current reality to have any effect, otherwise it'll just be ignored by manufacturers.
Incremental improvements, such as this, are not bad, even if not perfect. People are going to buy doorbell cameras that connect outbound to the internet, because the technology works out of the box.
That's a valid answer for an audience familiar with computer networking concepts. It's a silly suggestion for consumer IoT customers, who do not understand those concepts. They don't know what is or is not 'on the open internet'; they buy a product at the store and plug it in.
> We should have certifications that devices create no outbound TCP/UDP flows.
This is the "bury your head in the sand" method of solving the problem. If you design your requirement so that zero consumer accessible devices are capable of meeting them, then what's the point? As long as people (1) want to watch their camera away from home, and (2) don't have the networking expertise to configure a remote access VPN tunnel, the devices are going to have to reach outbound to traverse home router firewalls.