On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter <leich...@lrw.com> wrote:
> On Oct 8, 2013, at 1:11 AM, Bill Frantz <fra...@pwpconsult.com> wrote: > >> If we can't select ciphersuites that we are sure we will always be > comfortable with (for at least some forseeable lifetime) then we urgently > need the ability to *stop* using them at some point. The examples of MD5 > and RC4 make that pretty clear. > >> Ceasing to use one particular encryption algorithm in something like > SSL/TLS should be the easiest case--we don't have to worry about old > signatures/certificates using the outdated algorithm or anything. And yet > we can't reliably do even that. > > > > We seriously need to consider what the design lifespan of our crypto > suites is in real life. That data should be communicated to hardware and > software designers so they know what kind of update schedule needs to be > supported. Users of the resulting systems need to know that the crypto > standards have a limited life so they can include update in their > installation planning. > This would make a great April Fool's RFC, to go along with the classic > "evil bit". :-( > > There are embedded systems that are impractical to update and have > expected lifetimes measured in decades. RFID chips include cryptography, > are completely un-updatable, and have no real limit on their lifetimes - > the percentage of the population represented by any given "vintage" of > chips will drop continuously, but it will never go to zero. We are rapidly > entering a world in which devices with similar characteristics will, in > sheer numbers, dominate the ecosystem - see the remote-controllable > Phillips Hue light bulbs ( > http://www.amazon.com/dp/B00BSN8DLG/?tag=googhydr-20&hvadid=27479755997&hvpos=1t1&hvexid=&hvnetw=g&hvrand=1430995233802883962&hvpone=&hvptwo=&hvqmt=b&hvdev=c&ref=pd_sl_5exklwv4ax_b) > as an early example. (Oh, and there's been an attack against them: > http://www.engadget.com/2013/08/14/philips-hue-smart-light-security-issues/. > The response from Phillips to that article says "In developing Hue we have > used industry standard encryption and authentication techni > ques.... [O]ur main advice to customers is that they take steps to > ensure they are secured from malicious attacks at a network level." > > The obvious solution: Do it right the first time. Many of the TLS issues we are dealing with today were known at the time the standard was being developed. RFID usually isn't that security critical: if a shirt insists its an ice cream, a human will usually be around to see that it is a shirt. AES will last forever, unless cryptoanalytic advances develop. Quantum computers will doom ECC, but in the meantime we are good. Cryptography in the two parties authenticating and communicating is a solved problem. What isn't solved, and behind many of these issues is 1) getting the standard committees up to speed and 2) deployment/PKI issues. > > I'm afraid the reality is that we have to design for a world in which some > devices will be running very old versions of code, speaking only very old > versions of protocols, pretty much forever. In such a world, newer devices > either need to shield their older brethren from the sad realities or > relegate them to low-risk activities by refusing to engage in high-risk > transactions with them. It's by no means clear how one would do this, but > there really aren't any other realistic alternatives. > Great big warning lights saying "Insecure device! Do not trust!". If Wells Fargo customers got a "Warning: This site is using outdated security" when visiting it on all browsers, they would fix that F5 terminator currently stopping the rest of us from deploying various TLS extensions. > -- Jerry > > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
