[147616] in cryptography@c2.net mail archive
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
daemon@ATHENA.MIT.EDU (David Mercer)
Fri Oct 11 00:18:59 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711D74E506E@USMBX1.msg.corp.akamai.com>
Date: Fri, 11 Oct 2013 11:33:55 +0800
From: David Mercer <radix42@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Watson Ladd <watsonbladd@gmail.com>,
Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============0978208049446336867==
Content-Type: multipart/alternative; boundary=001a11c29ad2bc727c04e86ec936
--001a11c29ad2bc727c04e86ec936
Content-Type: text/plain; charset=UTF-8
On Thursday, October 10, 2013, Salz, Rich wrote:
> > TLS was designed to support multiple ciphersuites. Unfortunately this
> opened the door
> > to downgrade attacks, and transitioning to protocol versions that
> wouldn't do this was nontrivial.
> > The ciphersuites included all shared certain misfeatures, leading to the
> current situation.
>
> On the other hand, negotiation let us deploy it in places where
> full-strength cryptography is/was regulated.
>
> Sometimes half a loaf is better than nothing.
The last time various SSL/TLS ciphersuites needed to be removed from
webserver configurations when I managed a datacenter some years ago led to
the following 'failure modes', either from the user's browser now warning
or refusing to connect to a server using an insecure cipher suite, or when
the only cipher suites used by a server weren't supported by an old browser
(or both at once):
1) for sites that had low barriers to switching, loss of traffic/customers
to sites that didn't drop the insecure ciphersuites
2) for sites that are harder to leave (your bank, google/facebook level
sticky public ones [less common]), large increases in calls to support,
with large costs for the business. Non-PCI compliant businesses taking CC
payments are generally so insecure that customers that fled to them really
are uppung their chances of suffering fraud.
In both cases you have a net decrease of security and an increase of fraud
and financial loss.
So in some cases anything less than a whole loaf, which you can't guarantee
for N years of time, isn't 'good enough.' In other words, we are screwed no
matter what.
-David Mercer
--
David Mercer - http://dmercer.tumblr.com
IM: AIM: MathHippy Yahoo/MSN: n0tmusic
Facebook/Twitter/Google+/Linkedin: radix42
FAX: +1-801-877-4351 - BlackBerry PIN: 332004F7
PGP Public Key: http://davidmercer.nfshost.com/radix42.pubkey.txt
Fingerprint: A24F 5816 2B08 5B37 5096 9F52 B182 3349 0F23 225B
--001a11c29ad2bc727c04e86ec936
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, October 10, 2013, Salz, Rich wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">> TLS was designed to support multiple ciphersuites. Unfortunat=
ely this opened the door<br>
> to downgrade attacks, and transitioning to protocol versions that woul=
dn't do this was nontrivial.<br>
> The ciphersuites included all shared certain misfeatures, leading to t=
he current situation.<br>
<br>
On the other hand, negotiation let us deploy it in places where full-streng=
th cryptography is/was regulated.<br>
<br>
Sometimes half a loaf is better than nothing.</blockquote><div><br></div><d=
iv>=C2=A0The last time various SSL/TLS ciphersuites needed to be removed fr=
om webserver configurations when I managed a datacenter some years ago led =
to the following 'failure modes', either from the user's browse=
r now warning or refusing to connect to a server using an insecure cipher s=
uite, or when the only cipher suites used by a server weren't supported=
by an old browser (or both at once):<br>
</div><div><br></div><div>1) for sites that had low barriers to switching, =
loss of traffic/customers to sites that didn't drop the insecure cipher=
suites</div><div><br></div><div>2) for sites that are harder to leave (your=
bank, google/facebook level sticky public ones [less common]), large incre=
ases in calls to support, with large costs for the business. Non-PCI compli=
ant businesses taking CC payments are generally so insecure that customers =
that fled to them really are uppung their chances of suffering=C2=A0=C2=A0f=
raud.</div>
<div><br></div><div>In both cases you have a net=C2=A0decrease of security =
and an increase of fraud and financial loss.=C2=A0</div><div><br></div>So i=
n some cases anything less than a whole loaf, which you can't guarantee=
for N years of time, isn't 'good enough.' In other words, we a=
re screwed no matter what.<div>
<br></div><div>-David Mercer</div><div><br></div><br><br>-- <br><div dir=3D=
"ltr">David Mercer - <a href=3D"http://dmercer.tumblr.com" target=3D"_blank=
">http://dmercer.tumblr.com</a><br>IM: =C2=A0AIM: MathHippy Yahoo/MSN: n0tm=
usic<br>
Facebook/Twitter/Google+/Linkedin: radix42<br>FAX: +1-801-877-4351 - BlackB=
erry PIN: 332004F7<div>PGP Public Key:=C2=A0<a href=3D"http://davidmercer.n=
fshost.com/radix42.pubkey.txt" target=3D"_blank">http://davidmercer.nfshost=
.com/radix42.pubkey.txt</a></div>
<div>Fingerprint:=C2=A0A24F 5816 2B08 5B37 5096 =C2=A09F52 B182 3349 0F23 2=
25B</div></div><br>
--001a11c29ad2bc727c04e86ec936--
--===============0978208049446336867==
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
--===============0978208049446336867==--
