[148939] in cryptography@c2.net mail archive
Re: [Cryptography] defaults, black boxes, APIs,
daemon@ATHENA.MIT.EDU (Kevin W. Wall)
Sun Jan 5 22:49:39 2014
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52C91026.9010507@iang.org>
Date: Sun, 5 Jan 2014 20:19:26 -0500
From: "Kevin W. Wall" <kevin.w.wall@gmail.com>
To: ianG <iang@iang.org>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2863570098926210705==
Content-Type: multipart/alternative; boundary=bcaec544efe002467a04ef430d97
--bcaec544efe002467a04ef430d97
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Jan 5, 2014 at 2:56 AM, ianG <iang@iang.org> wrote:
> ...<snip>...
>
> Right, so we're agreed. The point then is that if this is the state of
> the world we are trying to protect -- leaving aside the *BSDs who'll not
> need our help -- then we do have faster update cycles to help us.
>
> So the notion of putting in extra algorithms up front so we can switch
> from one to the other on signs of trouble doesn't make as much sense. We
> can replace the whole lot in the update cycle. We don't need to ask the
> sysadm to start fiddling with these strings:
>
> SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:
> EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!
> aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:
> !ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
>
> (which never worked as a security practice anyway). (BTW, this comes from
> BetterCrypto.org project's draft: https://bettercrypto.org/
> static/applied-crypto-hardening.pdf )
>
> Apply SUITE1. We can just work on SUITE2 in the background and when the
> failure occurs, roll it out entirely.
>
> OK, so I hear from here that people are shaking their heads and saying,
> he's crazy, loco, off his rocker. Granted, this is a *thought experiment*
> . Start from the facts we know:
>
> * the world is moving to frequent dynamic updating *
> * the old algorithm agility suite promiscuity idea failed *
> * we will always need an ability to upgrade bits & pieces *
>
> What else can we do?
>
I see a few problems with it. Let's divide this into
two major crypto use cases... one is using crypto to
secure data at rest and the other to secure data in
transit.
For the data-at-rest use case, let's suppose that you
start with a single algorithm, 'AlgA', and then for
some reason, we find we need to deprecate it and get
people to start using 'AlgB'. Because this is a
data-at-rest scenario, you are stuck with at least
keeping 'AlgA' around in your software so that data
previously encrypted (or signed) with it can be
decrypted (or have its signature verified). You
should of course prevent new data from being encrypted
(or signed) using 'AlgA' and force the use of 'AlgB'
for this, but unless you wish to have people stop
using your software, that's the best you can do. And
you have to do the same thing when changing from
'AlgB' to 'AlgC' (which you of course hope will never
happen). And should that case ever happen, you *STILL*
might not be able to completely drop 'AlgA' because
you can't be certain of the data retention practices
that a company policy or regulatory practice dictate.
Of course, if you are going to have to do this, then
when it comes to (say) decryption, you either have
to also know what algorithm it was encrypted with
or you try decrypting them all in some predetermined
order (e.g., probably newest to oldest).
The other use case is securing data in transit.
Here it sounds as though you may have a bit more
success with your proposal, but even here, I think
there are difficulties.
Suppose you are trying to support a TLS library.
Something like OpenSSL or GnuTLS or NSS. The first
issue that you are going to have is that you are
going to have to choose some common cipher suite
that is supported by the majority of other TLS
implementations or otherwise there goes
interoperability. So if you want to have the
OneTrueAlgorithm, your choices are probably
going to be limited from the start. Secondly,
let's assume that your OneTrueAlgorithm becomes
problematic because of some newly discovered
cryptographic weakness, so you decide to go
with your second choice of cipher suite,
RemainingBestAlgorithm when you upgrade. As before,
you will be limited in your choices because of
interoperability with other TLS implementations.
I will even give you the benefit of the doubt
and assume that either every other implementation
either supports your desired choice or maybe, if
you can convince all the other implementations to
follow the same strategy, they all agree to upgrade
at the same time. The problem is that even though
the changes to all the TLS libraries may be
interoperable and simultaneously released (and
drop support for the old version), there decision
of when to upgrade the libraries that are used
rest either with the OS distro or (if statically
compiled) with the application itself that uses
the TLS libraries. And getting that to happen
lock-step is something that I just don't see
happening. For example, you likely will find LOBs who
insist that they can't upgrade from something like
Red Hat Enhanced Linux 3.0 or even older because
they have some old 3rd party COTs software running
on it that is "too expensive" to upgrade. So that
LOB generally signs some sort of risk acceptance
letter and it gets filed. But you can't do anything
to "break" their interoperability with other systems
because theirs is a "mission critical" application
and there would be hell to pay if you did. That is
the sad truth about the state of operations support.
It's also one reason why the 2013 OWASP Top 10 list
(https://www.owasp.org/index.php/Top_10_2013-Top_10)
now includes for the first time:
A9 - Using Components with Known Vulnerabilities
It turns out, in many F500 mission critical business
applications, outages (or undue concern of outages)
trumps potential security breaches. That is probably
not something that most CISOs would admit (and
certainly not something they generally support),
but the truth is that its the revenue generating
LOBs that rule the company, not the security
organizations. (But I'm sure you already knew that;
I'm just trying to stimulate you from working through
the difficult steps of operational support that you
eventually will have to face if you wish to go
forth with your 'one true cipher' strategy.
-
kevin
--
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.
--bcaec544efe002467a04ef430d97
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier =
new,monospace;display:inline"></div><div class=3D"gmail_extra">On Sun, Jan =
5, 2014 at 2:56 AM, ianG <span dir=3D"ltr"><<a href=3D"mailto:iang@iang.=
org" target=3D"_blank">iang@iang.org</a>></span> wrote:<br>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div class=3D"gmail_default" style=3D"font-family:courier new,monospace;d=
isplay:inline">
...<snip>...</div>
<br>
Right, so we're agreed. =A0The point then is that if this is the state =
of the world we are trying to protect -- leaving aside the *BSDs who'll=
not need our help -- then we do have faster update cycles to help us.<br>
<br>
So the notion of putting in extra algorithms up front so we can switch from=
one to the other on signs of trouble doesn't make as much sense. We ca=
n replace the whole lot in the update cycle. =A0We don't need to ask th=
e sysadm to start fiddling with these strings:<br>
<br>
SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+<u></u>aRSA+AESGCM:EECDH+aRSA+SH=
A384:<u></u>EECDH+aRSA+SHA256:EECDH:+<u></u>CAMELLIA256:+AES256:+<u></u>CAM=
ELLIA128:+AES128:+SSLv3:!<u></u>aNULL:!eNULL:!LOW:!3DES:!MD5:!<u></u>EXP:!P=
SK:!SRP:!DSS:!RC4:!SEED:<u></u>!ECDSA:CAMELLIA256-SHA:AES256-<u></u>SHA:CAM=
ELLIA128-SHA:AES128-SHA<br>
<br>
(which never worked as a security practice anyway). =A0(BTW, this comes fro=
m BetterCrypto.org project's draft: <a href=3D"https://bettercrypto.org=
/static/applied-crypto-hardening.pdf" target=3D"_blank">https://bettercrypt=
o.org/<u></u>static/applied-crypto-<u></u>hardening.pdf</a> )<br>
<br>
Apply SUITE1. =A0We can just work on SUITE2 in the background and when the =
failure occurs, roll it out entirely.<br>
<br>
OK, so I hear from here that people are shaking their heads and saying, he&=
#39;s crazy, loco, off his rocker. =A0Granted, this is a *thought experimen=
t* . =A0Start from the facts we know:<br>
<br>
=A0 * the world is moving to frequent dynamic updating *<br>
=A0 * the old algorithm agility suite promiscuity idea failed *<br>
=A0 * we will always need an ability to upgrade bits & pieces *<br>
<br>
What else can we do?<br></blockquote></div><br><div class=3D"gmail_default"=
style=3D"font-family:courier new,monospace">I see a few problems with it. =
Let's divide this into<br></div><div class=3D"gmail_default" style=3D"f=
ont-family:courier new,monospace">
two major crypto use cases... one is using crypto to<br></div><div class=3D=
"gmail_default" style=3D"font-family:courier new,monospace">secure data at =
rest and the other to secure data in<br>transit.<br><br></div><div class=3D=
"gmail_default" style=3D"font-family:courier new,monospace">
For the data-at-rest use case, let's suppose that you<br>start with a s=
ingle algorithm, 'AlgA', and then for<br>some reason, we find we ne=
ed to deprecate it and get<br></div><div class=3D"gmail_default" style=3D"f=
ont-family:courier new,monospace">
people to start using 'AlgB'.=A0 Because this is a<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:courier new,monospace">data-at-r=
est scenario, you are stuck with at least<br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:courier new,monospace">
keeping 'AlgA' around in your software so that data<br></div><div c=
lass=3D"gmail_default" style=3D"font-family:courier new,monospace">previous=
ly encrypted (or signed) with it can be<br>decrypted (or have its signature=
verified). You<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">should of course prevent new data from being encrypted<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:courier new,monospace">(or signe=
d) using 'AlgA' and force the use of 'AlgB'<br>
for this, but unless you wish to have people stop<br></div><div class=3D"gm=
ail_default" style=3D"font-family:courier new,monospace">using your softwar=
e, that's the best you can do. And<br>you have to do the same thing whe=
n changing from<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">'AlgB' to 'AlgC' (which you of course hope will never<b=
r></div><div class=3D"gmail_default" style=3D"font-family:courier new,monos=
pace">
happen). And should that case ever happen, you *STILL*<br></div><div class=
=3D"gmail_default" style=3D"font-family:courier new,monospace">might not be=
able to completely drop 'AlgA' because<br>you can't be certain=
of the data retention practices<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">that a company policy or regulatory practice dictate.<br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:courier new,monospace">Of course,=
if you are going to have to do this, then<br>
when it comes to (say) decryption, you either have<br></div><div class=3D"g=
mail_default" style=3D"font-family:courier new,monospace">to also know what=
algorithm it was encrypted with<br></div><div class=3D"gmail_default" styl=
e=3D"font-family:courier new,monospace">
or you try decrypting them all in some predetermined<br></div><div class=3D=
"gmail_default" style=3D"font-family:courier new,monospace">order (e.g., pr=
obably newest to oldest).<br><br></div><div class=3D"gmail_default" style=
=3D"font-family:courier new,monospace">
The other use case is securing data in transit.<br></div><div class=3D"gmai=
l_default" style=3D"font-family:courier new,monospace">Here it sounds as th=
ough you may have a bit more<br></div><div class=3D"gmail_default" style=3D=
"font-family:courier new,monospace">
success with your proposal, but even here, I think<br>there are difficultie=
s.<br><br></div><div class=3D"gmail_default" style=3D"font-family:courier n=
ew,monospace">Suppose you are trying to support a TLS library.<br></div><di=
v class=3D"gmail_default" style=3D"font-family:courier new,monospace">
Something like OpenSSL or GnuTLS or NSS. The first<br></div><div class=3D"g=
mail_default" style=3D"font-family:courier new,monospace">issue that you ar=
e going to have is that you are<br>going to have to choose some common ciph=
er suite<br>
that is supported by the majority of other TLS<br></div><div class=3D"gmail=
_default" style=3D"font-family:courier new,monospace">implementations or ot=
herwise there goes<br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:courier new,monospace">
interoperability. So if you want to have the<br></div><div class=3D"gmail_d=
efault" style=3D"font-family:courier new,monospace">OneTrueAlgorithm, your =
choices are probably<br>going to be limited from the start.=A0 Secondly,<br=
></div>
<div class=3D"gmail_default" style=3D"font-family:courier new,monospace">le=
t's assume that your OneTrueAlgorithm becomes<br></div><div class=3D"gm=
ail_default" style=3D"font-family:courier new,monospace">problematic becaus=
e of some newly discovered<br>
cryptographic weakness, so you decide to go<br>with your second choice of c=
ipher suite,<br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace">RemainingBestAlgorithm when you upgrade. As before,<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">you will be limited in your choices because of<br>interoperability with=
other TLS implementations.<br></div><div class=3D"gmail_default" style=3D"=
font-family:courier new,monospace">
I will even give you the benefit of the doubt<br>and assume that either eve=
ry other implementation<br>either supports your desired choice or maybe, if=
<br>you can convince all the other implementations to<br></div><div class=
=3D"gmail_default" style=3D"font-family:courier new,monospace">
follow the same strategy, they all agree to upgrade<br>at the same time.=A0=
The problem is that even though<br></div><div class=3D"gmail_default" styl=
e=3D"font-family:courier new,monospace">the changes to all the TLS librarie=
s may be<br>
interoperable and simultaneously released (and<br></div><div class=3D"gmail=
_default" style=3D"font-family:courier new,monospace">drop support for the =
old version), there decision<br>of when to upgrade the libraries that are u=
sed<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">rest either with the OS distro or (if statically<br>compiled) with the =
application itself that uses<br></div><div class=3D"gmail_default" style=3D=
"font-family:courier new,monospace">
the TLS libraries. And getting that to happen<br>lock-step is something tha=
t I just don't see<br></div><div class=3D"gmail_default" style=3D"font-=
family:courier new,monospace">happening. For example, you likely will find =
LOBs who<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">insist that they can't upgrade from something like<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:courier new,monospace">Red Hat E=
nhanced Linux 3.0 or even older because<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">they have some old 3rd party COTs software running<br>on it that is &qu=
ot;too expensive" to upgrade. So that<br></div><div class=3D"gmail_def=
ault" style=3D"font-family:courier new,monospace">
LOB generally signs some sort of risk acceptance<br>letter and it gets file=
d. But you can't do anything<br>to "break" their interoperabi=
lity with other systems<br>because theirs is a "mission critical"=
application<br>
and there would be hell to pay if you did. That is<br>the sad truth about t=
he state of operations support.<br>It's also one reason why the 2013 OW=
ASP Top 10 list<br>(<a href=3D"https://www.owasp.org/index.php/Top_10_2013-=
Top_10">https://www.owasp.org/index.php/Top_10_2013-Top_10</a>)<br>
now includes for the first time:<br></div><div class=3D"gmail_default" styl=
e=3D"font-family:courier new,monospace">=A0 A9 - Using Components with Know=
n Vulnerabilities<br></div><br clear=3D"all"><div class=3D"gmail_default" s=
tyle=3D"font-family:courier new,monospace">
It turns out, in many F500 mission critical business<br>applications, outag=
es (or undue concern of outages)<br></div><div class=3D"gmail_default" styl=
e=3D"font-family:courier new,monospace">trumps potential security breaches.=
That is probably<br>
not something that most CISOs would admit (and<br></div><div class=3D"gmail=
_default" style=3D"font-family:courier new,monospace">certainly not somethi=
ng they generally support),<br>but the truth is that its the revenue genera=
ting<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">LOBs that rule the company, not the security<br></div><div class=3D"gma=
il_default" style=3D"font-family:courier new,monospace">organizations. (But=
I'm sure you already knew that;<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">I'm just trying to stimulate you from working through<br>the diffic=
ult steps of operational support that you<br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:courier new,monospace">
eventually will have to face if you wish to go<br>forth with your 'one =
true cipher' strategy.<br></div>-<div class=3D"gmail_default" style=3D"=
font-family:courier new,monospace;display:inline">kevin</div><div class=3D"=
gmail_default" style=3D"font-family:courier new,monospace">
</div><br>-- <br>Blog: <a href=3D"http://off-the-wall-security.blogspot.com=
/" target=3D"_blank">http://off-the-wall-security.blogspot.com/</a><br>NSA:=
All your crypto bit are belong to us.
</div></div>
--bcaec544efe002467a04ef430d97--
--===============2863570098926210705==
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
--===============2863570098926210705==--
