[Cryptography] defaults, black boxes, APIs, and other engineering thoughts

[Kevin W. Wall]

On Sun, Jan 5, 2014 at 2:56 AM, ianG <iang at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140105/ebf44a4f/attachment.html>