<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;display:inline"></div><div class="gmail_extra">On Sun, Jan 5, 2014 at 2:56 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
...<snip>...</div>
<br>
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.<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 can replace the whole lot in the update cycle.  We don't need to ask the sysadm to start fiddling with these strings:<br>

<br>
SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+<u></u>aRSA+AESGCM:EECDH+aRSA+SHA384:<u></u>EECDH+aRSA+SHA256:EECDH:+<u></u>CAMELLIA256:+AES256:+<u></u>CAMELLIA128:+AES128:+SSLv3:!<u></u>aNULL:!eNULL:!LOW:!3DES:!MD5:!<u></u>EXP:!PSK:!SRP:!DSS:!RC4:!SEED:<u></u>!ECDSA:CAMELLIA256-SHA:AES256-<u></u>SHA:CAMELLIA128-SHA:AES128-SHA<br>

<br>
(which never worked as a security practice anyway).  (BTW, this comes from BetterCrypto.org project's draft: <a href="https://bettercrypto.org/static/applied-crypto-hardening.pdf" target="_blank">https://bettercrypto.org/<u></u>static/applied-crypto-<u></u>hardening.pdf</a> )<br>

<br>
Apply SUITE1.  We 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's crazy, loco, off his rocker.  Granted, this is a *thought experiment* .  Start from the facts we know:<br>
<br>
  * the world is moving to frequent dynamic updating *<br>
  * the old algorithm agility suite promiscuity idea failed *<br>
  * we will always need an ability to upgrade bits & pieces *<br>
<br>
What else can we do?<br></blockquote></div><br><div class="gmail_default" style="font-family:courier new,monospace">I see a few problems with it. Let's divide this into<br></div><div class="gmail_default" style="font-family:courier new,monospace">
two major crypto use cases... one is using crypto to<br></div><div class="gmail_default" style="font-family:courier new,monospace">secure data at rest and the other to secure data in<br>transit.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">
For the data-at-rest use case, let's suppose that you<br>start with a single algorithm, 'AlgA', and then for<br>some reason, we find we need to deprecate it and get<br></div><div class="gmail_default" style="font-family:courier new,monospace">
people to start using 'AlgB'.  Because this is a<br></div><div class="gmail_default" style="font-family:courier new,monospace">data-at-rest scenario, you are stuck with at least<br></div><div class="gmail_default" style="font-family:courier new,monospace">
keeping 'AlgA' around in your software so that data<br></div><div class="gmail_default" style="font-family:courier new,monospace">previously encrypted (or signed) with it can be<br>decrypted (or have its signature verified). You<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">should of course prevent new data from being encrypted<br></div><div class="gmail_default" style="font-family:courier new,monospace">(or signed) using 'AlgA' and force the use of 'AlgB'<br>
for this, but unless you wish to have people stop<br></div><div class="gmail_default" style="font-family:courier new,monospace">using your software, that's the best you can do. And<br>you have to do the same thing when changing from<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">'AlgB' to 'AlgC' (which you of course hope will never<br></div><div class="gmail_default" style="font-family:courier new,monospace">
happen). And should that case ever happen, you *STILL*<br></div><div class="gmail_default" style="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="gmail_default" style="font-family:courier new,monospace">that a company policy or regulatory practice dictate.<br></div><div class="gmail_default" style="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="gmail_default" style="font-family:courier new,monospace">to also know what algorithm it was encrypted with<br></div><div class="gmail_default" style="font-family:courier new,monospace">
or you try decrypting them all in some predetermined<br></div><div class="gmail_default" style="font-family:courier new,monospace">order (e.g., probably newest to oldest).<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">
The other use case is securing data in transit.<br></div><div class="gmail_default" style="font-family:courier new,monospace">Here it sounds as though you may have a bit more<br></div><div class="gmail_default" style="font-family:courier new,monospace">
success with your proposal, but even here, I think<br>there are difficulties.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">Suppose you are trying to support a TLS library.<br></div><div class="gmail_default" style="font-family:courier new,monospace">
Something like OpenSSL or GnuTLS or NSS. The first<br></div><div class="gmail_default" style="font-family:courier new,monospace">issue that you are going to have is that you are<br>going to have to choose some common cipher suite<br>
that is supported by the majority of other TLS<br></div><div class="gmail_default" style="font-family:courier new,monospace">implementations or otherwise there goes<br></div><div class="gmail_default" style="font-family:courier new,monospace">
interoperability. So if you want to have the<br></div><div class="gmail_default" style="font-family:courier new,monospace">OneTrueAlgorithm, your choices are probably<br>going to be limited from the start.  Secondly,<br></div>
<div class="gmail_default" style="font-family:courier new,monospace">let's assume that your OneTrueAlgorithm becomes<br></div><div class="gmail_default" style="font-family:courier new,monospace">problematic because of some newly discovered<br>
cryptographic weakness, so you decide to go<br>with your second choice of cipher suite,<br></div><div class="gmail_default" style="font-family:courier new,monospace">RemainingBestAlgorithm when you upgrade. As before,<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">you will be limited in your choices because of<br>interoperability with other TLS implementations.<br></div><div class="gmail_default" style="font-family:courier new,monospace">
I will even give you the benefit of the doubt<br>and assume that either every other implementation<br>either supports your desired choice or maybe, if<br>you can convince all the other implementations to<br></div><div class="gmail_default" style="font-family:courier new,monospace">
follow the same strategy, they all agree to upgrade<br>at the same time.  The problem is that even though<br></div><div class="gmail_default" style="font-family:courier new,monospace">the changes to all the TLS libraries may be<br>
interoperable and simultaneously released (and<br></div><div class="gmail_default" style="font-family:courier new,monospace">drop support for the old version), there decision<br>of when to upgrade the libraries that are used<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">rest either with the OS distro or (if statically<br>compiled) with the application itself that uses<br></div><div class="gmail_default" style="font-family:courier new,monospace">
the TLS libraries. And getting that to happen<br>lock-step is something that I just don't see<br></div><div class="gmail_default" style="font-family:courier new,monospace">happening. For example, you likely will find LOBs who<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">insist that they can't upgrade from something like<br></div><div class="gmail_default" style="font-family:courier new,monospace">Red Hat Enhanced Linux 3.0 or even older because<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">they have some old 3rd party COTs software running<br>on it that is "too expensive" to upgrade. So that<br></div><div class="gmail_default" style="font-family:courier new,monospace">
LOB generally signs some sort of risk acceptance<br>letter and it gets filed. But you can't do anything<br>to "break" their interoperability 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 the state of operations support.<br>It's also one reason why the 2013 OWASP Top 10 list<br>(<a href="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="gmail_default" style="font-family:courier new,monospace">  A9 - Using Components with Known Vulnerabilities<br></div><br clear="all"><div class="gmail_default" style="font-family:courier new,monospace">
It turns out, in many F500 mission critical business<br>applications, outages (or undue concern of outages)<br></div><div class="gmail_default" style="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="gmail_default" style="font-family:courier new,monospace">certainly not something they generally support),<br>but the truth is that its the revenue generating<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">LOBs that rule the company, not the security<br></div><div class="gmail_default" style="font-family:courier new,monospace">organizations. (But I'm sure you already knew that;<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">I'm just trying to stimulate you from working through<br>the difficult steps of operational support that you<br></div><div class="gmail_default" style="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="gmail_default" style="font-family:courier new,monospace;display:inline">kevin</div><div class="gmail_default" style="font-family:courier new,monospace">
</div><br>-- <br>Blog: <a href="http://off-the-wall-security.blogspot.com/" target="_blank">http://off-the-wall-security.blogspot.com/</a><br>NSA: All your crypto bit are belong to us.
</div></div>