<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Oct 8, 2013, at 1:11 AM, Bill Frantz <<a href="mailto:frantz@pwpconsult.com">frantz@pwpconsult.com</a>> wrote:<br>
>> 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.<br>
>> 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.<br>
><br>
> 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.<br>
</div>This would make a great April Fool's RFC, to go along with the classic "evil bit". :-(<br>
<br>
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 (<a href="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" target="_blank">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</a>) as an early example. (Oh, and there's been an attack against them: <a href="http://www.engadget.com/2013/08/14/philips-hue-smart-light-security-issues/" target="_blank">http://www.engadget.com/2013/08/14/philips-hue-smart-light-security-issues/</a>. The response from Phillips to that article says "In developing Hue we have used industry standard encryption and authentication techni<br>
ques.... [O]ur main advice to customers is that they take steps to ensure they are secured from malicious attacks at a network level."<br><br></blockquote><div>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.</div>
<div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"> -- Jerry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety."<br>-- Benjamin Franklin
</div></div>