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

[ianG]

On 4/01/14 19:06 PM, Jerry Leichter wrote:
> On Jan 4, 2014, at 5:22 AM, ianG wrote:
>> Have you noticed how the entire world is moving to a much more sophisticated update model, typically dynamically, monthly?  If you can do that, you don't need algorithm agility as a static tool.
> I would contend the dynamic, monthly update model is a sign of failure, not success.

Oh, maybe, indeed.  I'm not arguing that this is a good thing or a bad 
thing, I'm suggesting that software distribution models are changing, 
and the old assumptions about bugs and quality and so forth aren't reliable:

Jonathon Thornburg writes in same thread:
 > But OSs which make
 > security a very high priority, like (say) OpenBSD, aren't moving
 > that way at all -- they're staying with the old "updates are
 > manually applied by a (human) system administrator" model.

 > The OpenBSD website points out that they've only had two remote
 > holes in the default install in "a heck of a long time" (I
 > think more than a decade).  So perhaps the manual-updates
 > security model remains > viable....


Right, so those who have security as an obsession write once, right 
once.  I spoke too quickly when I said *entire* world...

But even Linux, the close competitor, has update insanity, it's one 
reason I don't use it.  Apple is delivering stuff more frequently and 
more aggressively, both my machines are bugging me to upgrade, when I 
used to survive on FreeBSD with a rebuild every 2 years.


> For it to be a success, it would have to be putting itself out of business - i.e., the quantity and severity of problems would be going down over time, aiming for complete cessation in some visible future.  In fact, there is no evidence I've seen that this is happening.  Most likely, the *opposite* is happening:  One of the reasons we've gone to monthly updates is that the volume of individual updates was so large that people couldn't keep up.  And then we went to automatically, silently installed updates because people couldn't even keep up with the monthly updates.


Ah, so sorry.  This is assuming the software world is driven by bugs. 
It isn't, it is driven by features.

> And as a side effect, we've expanded the attack surface.  You could, in the past, design systems with no privileged network-facing components.  In a world of automatic monthly updates, the update mechanism is itself a prime means of attack:  By its design and nature, it's *supposed* to be able to make arbitrary modifications to the system, while being accessible to the network. Just step back and think about what we're saying:  We have a system we *know* is vulnerable to some kind of attack, else why would we be patching it.  And yet we completely trust the update mechanism to make things better, not worse.  Does that make a lot of sense?
>
> I contend the only way to a secure future is to consider Tony Hoare's wonderful comment:  You can either make your system so simple it obviously has no bugs, or so complex it has no obvious bugs.  Most of our systems - certainly any system we have that has anything to do with the Web - have gone in the opposite direction.  And we've done this both at the individual element level, and every level above.


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?


> Would this solve any significant piece of the Internet security puzzle?  In and of itself, no.  It's a tiny piece of the puzzle.  But what we're doing now not only isn't working - if we look ahead in the direction we're moving, "working" isn't visible out there.


We are shouting vociferously in agreement, then!

Let me put my view into that perspective:  by stripping out much of the 
internal elements of the software (the spare suites, the defaults, the 
management of options, the FIPS features, etc) I'm making the overall 
design simpler.  Much simpler.  Write once, right once.

So, it's also more robust, lasts for more time, and locks down more stuff.

However, there is always a need for a fix or a tune or a new feature or 
a replacement.  So some way to replace things is needed.  What's that? 
I'd say that should be built in too, but it should be at a much higher 
layer, and it should be part of the overall major version update 
process.  Do it very infrequently.



iang