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

Reply via email to