Spitballing IoT Security

Wed Oct 26 15:45:11 UTC 2016

Eric,

I agree that the home router is a viable choke point, and even though we can’t quickly roll out new firmware, if we had started this ten years ago we’d be done by now! So this is the ten-year plan, but still worth doing.

I also really like the idea of offering open source options to vendors, many of whom seem to illegally take that privilege anyway. A key fast-path component, though, is in my opinion a new RFC for IoT security best practices, and probably some revisions to UPNP. 

The IoT RFC would spell out basic rules for safe devices: no back doors, no default passwords, no gratuitous inbound connections, etc. It would also make encryption a requirement, and limit how existing UPNP is deployed to prevent unnecessarily exposing vulnerable TCP/UDP ports to the wild. With this RFC in hand, and an appropriate splashy icon for vendor packaging (“RFC 9999 ThingSafe!”), vendors will have a competitive reason for compliance as a market differentiator, whether they deploy with open-source or proprietary code. 

This need not add a lot to R&D costs either, as enterprising embedded system designers will now be motivated to delivering packaged ThingSafe! solutions, such as embedded wireless controllers, cellular modems, etc. 

Your open-source approach seems to me something that could be started today, and that has no downside. The RFC could give it the imprimatur of a standard, which makes the plan easier for vendors to sell to their thrift-minded management.

 -mel

> On Oct 26, 2016, at 5:30 AM, Eric S. Raymond <esr at thyrsus.com> wrote:
> 
> Rich Kulawiec <rsk at gsp.org>:
>> I think our working assumption should be that there will be zero cooperation
>> from the IoT vendors.  (Yeah, once in a while one might actually step up,
>> but that will merely be a happy anomaly.)
> 
> I agree.
> 
> There is, however, a chokepoint we have more hope of getting decent software
> deployed to.  I refer to home and small-business routers.  OpenWRT and kin
> are already minor but significant players here. And there's an NRE-minimization
> aregument we can make for router manufacturers to use rebranded versions
> rather than rolling their own crappy firmware.
> 
> I think the anti-IoT-flood strategy that makes the most sense is:
> 
> 1. Push open-source firmware that doesn't suck to the vendors with a
>   cost- and risk-minimization pitch.
> 
> 2. Ship it with egress filters.  (And telnet blocked.)
> 
> It wouldn't be technically very difficult to make the firmware
> rate-limit outbound connections.  Cute trick: if we unlimit any 
> local IP address that is a port-forwarding target, most users
> will never notice because their browser sessions won't be effected.
> -- 
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>