On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir <ynir.i...@gmail.com> wrote:
> > Good questions, no doubt. But I don’t think they can be answered. > > Someone is going to specify protocols and algorithms. This could be the > IETF. This could be the ITU, or IEEE, or some other SDO. Makes no > difference. > Someone is going to implement these protocols and algorithms in some > combination of hardware and software. > Someone is going to combine this implementation with other parts like > network stack, wired or wireless communications, memory to create a > “brains” for IoT devices. > Someone is going to build a sensor or an actuator that includes that > “brains” plus hardware and software. This could be a lightbulb, and smoke > detector, a temperature sensor. > Someone is going to use this sensor or actuator as part of a system: a > car, a refrigerator, an HVAC system, a door alarm. > Someone is going to deploy these systems in a home, in a data center, in a > plane, in a nuclear power plant. > > It’s that last step that determines how attractive this is going to be to > attackers and what value is going to be protected by a device using these > protocols and algorithms. And the last two steps determine how isolated the > “thing” will be. > Not necessarily. Manufacturers may be able to push some of those isolation properties higher into the list. E.g., if the silicon simply cannot speak a more general protocol even if compromised, or has some other physical constraint (e.g., data rate, CPU power, etc.) that limits its expressiveness, you may be able to make provable statements about the potential impact of compromise. We obviously can't impose those restrictions on manufacturers, but I don't know if it's completely hopeless to create standards or compile best practices for mitigating compromise of insecure devices. But this brings me back to my earlier post where I said this sounds like a research problem: the IETF is not anywhere near being in the position of making such recommendations. And I'm not convinced that this path is a productive use of our time, when hardware being hardware means that increased functionality (better crypto, upgradability) gets cheaper all the time. OTOH, manufacturers being manufacturers means that security and upgradability are baked in only when users demand it, and users being users means that no one demands either until it's too late. So it's possible there's real value in doing the research and then creating safety standards for classes of devices that seem to be designed to atrophy, but it's probably more useful for that standardization to focus on network isolation rather than on crypto since the crypto is only one small part of the TCB. Is the era in which the marginal cost of upgradability is too expensive to support a short one, or is this a problem we're going to be dealing with for a long time? If the latter, then I'm starting to see some value in not having everything be globally-routable or even talk IP. Kyle
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
