> On 8 Sep 2016, at 7:08 PM, Kyle Rose <kr...@krose.org> wrote: > > On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann <pgut...@cs.auckland.ac.nz > <mailto:pgut...@cs.auckland.ac.nz>> wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I mean single DES, not 3DES) I've had a chorus of > complaints about it vanishing. > ... > Alarms, for example, send data > quantities measured in bytes, so some academic attack that would take 500 > million years to acquire the necessary data isn't going to lose anyone any > sleep. It's a nice piece of work, but you need to look at what practical > effect it has on real, deployed systems... > > To this class of examples, the problem seems to be less the implications for > security of the specific systems making use of weak crypto, and more the > effect the survival of weak options for crypto might have on other systems. > We don't want more general systems to be subject to attacks that may not be > applicable to the resource-constrained target systems, but that requires us > to answer a few questions about those constrained systems: > > (1) Is the target system isolated, such that a compromise cannot either > leverage transitive trust to another system or provide an attacker a beach > head from which to attack (surreptitiously probe, etc.) other systems? > > (2) Is the weak crypto being used by the target system in a way that renders > both the known and expected attacks inapplicable?
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. We as an SDO are 7 steps removed from this, so we can’t make that determination. We can be sure that if we specify a protocol that will prove successful (as in adopted) by industry, that protocol will protect lightbulbs, but it will also end up protecting critical infrastructure, high-value targets and probably even lives. We can’t even make Peter’s assumption that these things send only a few bytes of data, because many things send very little data. But some things will send a lot of data. And putting “no more than 1 MB per day” in the security considerations section is an exercise in futility. Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
