[147570] in cryptography@c2.net mail archive
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
daemon@ATHENA.MIT.EDU (Watson Ladd)
Wed Oct 9 16:19:13 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <2AEF1BE5-0783-46F7-A938-5524B9A14357@lrw.com>
Date: Tue, 8 Oct 2013 09:13:20 -0700
From: Watson Ladd <watsonbladd@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: Cryptography <cryptography@metzdowd.com>,
Bill Frantz <frantz@pwpconsult.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============5566588833217257174==
Content-Type: multipart/alternative; boundary=001a11c24316227c0304e83d0cab
--001a11c24316227c0304e83d0cab
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter <leichter@lrw.com> wrote:
> On Oct 8, 2013, at 1:11 AM, Bill Frantz <frantz@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
--001a11c24316227c0304e83d0cab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Oct 8, 2013 at 7:38 AM, Jerry Leichter <span dir=3D"ltr">&l=
t;<a href=3D"mailto:leichter@lrw.com" target=3D"_blank">leichter@lrw.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Oct 8, 2013, at 1:11 AM=
, Bill Frantz <<a href=3D"mailto:frantz@pwpconsult.com">frantz@pwpconsul=
t.com</a>> wrote:<br>
>> If we can't select ciphersuites that we are sure we will alway=
s be comfortable with (for at least some forseeable lifetime) then we urgen=
tly need the ability to *stop* using them at some point. =C2=A0The examples=
of MD5 and RC4 make that pretty clear.<br>
>> Ceasing to use one particular encryption algorithm in something li=
ke SSL/TLS should be the easiest case--we don't have to worry about old=
signatures/certificates using the outdated algorithm or anything. =C2=A0An=
d yet we can't reliably do even that.<br>
><br>
> We seriously need to consider what the design lifespan of our crypto s=
uites is in real life. That data should be communicated to hardware and sof=
tware designers so they know what kind of update schedule needs to be suppo=
rted. Users of the resulting systems need to know that the crypto standards=
have a limited life so they can include update in their installation plann=
ing.<br>
</div>This would make a great April Fool's RFC, to go along with the cl=
assic "evil bit". =C2=A0:-(<br>
<br>
There are embedded systems that are impractical to update and have expected=
lifetimes measured in decades. =C2=A0RFID chips include cryptography, are =
completely un-updatable, and have no real limit on their lifetimes - the pe=
rcentage of the population represented by any given "vintage" of =
chips will drop continuously, but it will never go to zero. =C2=A0We are ra=
pidly entering a world in which devices with similar characteristics will, =
in sheer numbers, dominate the ecosystem - see the remote-controllable Phil=
lips Hue light bulbs (<a href=3D"http://www.amazon.com/dp/B00BSN8DLG/?tag=
=3Dgooghydr-20&hvadid=3D27479755997&hvpos=3D1t1&hvexid=3D&h=
vnetw=3Dg&hvrand=3D1430995233802883962&hvpone=3D&hvptwo=3D&=
hvqmt=3Db&hvdev=3Dc&ref=3Dpd_sl_5exklwv4ax_b" target=3D"_blank">htt=
p://www.amazon.com/dp/B00BSN8DLG/?tag=3Dgooghydr-20&hvadid=3D2747975599=
7&hvpos=3D1t1&hvexid=3D&hvnetw=3Dg&hvrand=3D143099523380288=
3962&hvpone=3D&hvptwo=3D&hvqmt=3Db&hvdev=3Dc&ref=3Dpd_s=
l_5exklwv4ax_b</a>) as an early example. =C2=A0(Oh, and there's been an=
attack against them: =C2=A0<a href=3D"http://www.engadget.com/2013/08/14/p=
hilips-hue-smart-light-security-issues/" target=3D"_blank">http://www.engad=
get.com/2013/08/14/philips-hue-smart-light-security-issues/</a>. =C2=A0The =
response from Phillips to that article says "In developing Hue we have=
used industry standard encryption and authentication techni<br>
=C2=A0ques.... =C2=A0[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 t=
he standard was being developed. RFID usually isn't that security criti=
cal: 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 advan=
ces develop. Quantum computers will doom ECC, but in the meantime we are go=
od.</div>
<div><br></div><div>Cryptography in the two parties authenticating and comm=
unicating is a solved problem. What isn't solved, and behind many of th=
ese issues is 1) getting the standard committees up to speed and 2) deploym=
ent/PKI issues.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
I'm afraid the reality is that we have to design for a world in which s=
ome devices will be running very old versions of code, speaking only very o=
ld versions of protocols, pretty much forever. =C2=A0In 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. =C2=A0It's by no means clear how one would do t=
his, 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 wou=
ld fix that F5 terminator currently stopping the rest of us from deploying =
various TLS extensions.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 -- Jerry<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><=
br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
"Those who would give up Essential Liberty to purchase a little Tempor=
ary Safety deserve neither=C2=A0 Liberty nor Safety."<br>-- Benjamin F=
ranklin=20
</div></div>
--001a11c24316227c0304e83d0cab--
--===============5566588833217257174==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============5566588833217257174==--
