This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.
Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.
We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:
-
Shaming.
-
Attempting to 'build consensus' or enforce ideological conformity.
-
Making sweeping generalizations to vilify a group you dislike.
-
Recruiting for a cause.
-
Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.
In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:
-
Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.
-
Be as precise and charitable as you can. Don't paraphrase unflatteringly.
-
Don't imply that someone said something they did not say, even if you think it follows from what they said.
-
Write like everyone is reading and you want them to be included in the discussion.
On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.
Jump in the discussion.
No email address required.
Notes -
Maybe, but so does CMOS RAM, and that's a central example of where you probably do want this rule to apply, and it's (usually) more volatile than FRAM. 5.4-1 to my read isn't about access modes or media type, but about storage volatility, and that makes some amount of sense for certain attack vectors -- you don't want someone reading cloud passwords by probing random SPI flash, as weird as that particular threat is.
But it also makes a lot of design spaces for low-power devices goofy, in ways that don't make sense. There's probably a class of low-power device where it's a really critical security problem is someone delid the main processors and inspects individual FRAM cells during a toggle-off state, but 99% of the time even if someone could hijack a session id from that it's less big of a deal than having access to the board to start with.
Yeah, but the condition is only that applies where ever "a hard-coded unique per device identity is used for security purposes". I think that includes virtually every LoRaWan (DevEUI) and probably every LoRa device, for one common example, but also technically at least most Bluetooth implementations. There's other places where it's a good idea to use hard-coded unique identities per device for security purposes even where it doesn't 'matter', and that's largely going to result in people just dealing with stupid hacks instead to avoid triggering the requirement whenever possible.
Yeah, but the conditions for 5.3-4 is "an update mechanism is implemented", 5.3-6 "an update mechanism is implemented" and "the device supports automatic updates and/or update notifications", and 5.3-10 that "updates are delivered over a network interface" and "an update mechanism is implemented". These are fine when you're talking a full web-UI/app-equipped device, but twenty sensors on a LIN line that can be updated still hit the requirement for 5.3-4, which is on its own a requirement for automatic updates so you now hit 5.3-6. Then you're trying to figure out how 5.3-10 works for devices that don't have user interfaces (and may not have user physical access!), and now you're either stuck tossing an authentication layer on your LIN, implementing a cryptographic security function for comms on said LIN, or spamming users with update notifications like they were running Arch Linux.
Eh...
Let's take the example of a lightning switches attached to a base station, as a fairly common home automation setup where the switches and adapters are... not actually a central case of the constrained device model (they have wall power!) but are at least arguably close. If you build one of these, you're probably going to support a wide variety of light bulb sockets and switch types, but not all of those are going to make sense over the longer term -- maybe a socket type falls out of popularity, or a new lightbulb tech drops that doesn't play well with dimmer circuits, or a vendor you partner with stops selling a product that makes that particular device make sense.
By the text, is a lighting hub "isolable and hardware replaceable" if the vendor doesn't want to sell every attachment for the hub's life cycle? Removing one attached device doesn't make the attached device 'isolable', because turning on and off that light is its core feature. Nor is removing the entire hub from the internet, since there's no sane way to call that a "self-contained environment with other devices if and only if the integrity of devices within that environment can be ensured", when the especially if the entire reason to pop them off the internet has to do with their ability to communicate securely with the local hub. Would it be hardware replaceable is the only hardware replacement doesn't actually fit into the same socket, just because something attaches to the same hub?
Yes, in practice your interpretation is the sane one, and hopefully it's probably going to end up as the sort of asterisk that just confuses people, like vendors just putting out generic 'support may stop without notice for some devices' clauses. But at best that turns the requirement into aspirational text instead of the actual policy.
I think the interpretation of that standard is closer to page 45-46 here, if not on the exact same timelines, and that quickly turns into an eWaste and version hop mandate for a lot of stuff pretty quickly in order to theoretically prevent the plausibility of certain attack classes, rather than blocking trivial ones. But even for its steelman of "don't use WPA2-only chips in new products", I think it's still costly even if well-intended, and a lot of those costs don't make a ton of sense. There's a number of chips and equipment that can't connect on WPA3 at all, and even where it's something that can be implemented in software that doesn't mean it's exactly easy.
More broadly, though, it seems like overbroad application of a rule. A presumption toward encrypting everything makes sense when it's free or nearly-free, but there are a lot of entire devices where it's just not that relevant. If your equipment does literally nothing but relay temperature and humidity values over ISM bands, you might want some amount of authentication to prevent spoofing, but it's really not that big a deal if someone can listen in. And there's a lot of IoT stuff that goes into that category.
There's some parts of the rules that motion around this -- 5.5-1's "Appropriateness of security controls and the use of best practice cryptography is dependent on many factors including the usage context" or the exceptions for ARP, DHCP, DNS, ICMP, and NTP in 5.5-5 -- but again that turns the requirement into aspirational text.
Fair enough. Hopefully the worst case is that this ends up not being covered, even though it should be.
I think I can agree that there may be tradeoffs here for some devices.
I think these would almost certainly just be classified as "constrained devices", and they also give alternate mechanisms for valid trust relations, which I think will be what the automakers go for. They'll do the verification at a different step and say that the lack of physical or other access is what ensures that presence on the network is sufficient.
I think you're right that some portion of this is aspirational text, but I think it's along the lines of, "If you can just put some reason down on the table for why this should be considered aspirational text, then you're probably fine," and the only people who are at risk are the people who are doing the clearly and obviously boneheaded stuff. Like, I don't think it's going to be hard for the maker of a device that does nothing but relay temperature and humidity values over ISM bands to just say, "It's a constrained device; can't do any of that fancy stuff; pretty much no way in anyway," and we can all mostly go home happy. If we start having major corporate networks brought down by botnets of temperature monitors (uh, how?), then perhaps folks will have to figure out how to make it more than aspirational text.
In any event, thanks a bunch for really thinking through edge cases for a wide variety of really specialized and, for lack of a better term, really constrained devices.
More options
Context Copy link
More options
Context Copy link