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

[Jerry Leichter]

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.  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.

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.  Everything depends on everything else; everything has to be trusted, in ways that we don't even understand.  We call the results "sophisticated"; a better word would be "incomprehensible".  Every successful attack simply shines the light on another piece of the mess that the attackers understood better than the designers.

As an example of what could be an alternative approach ... our moderator (hi, Perry, haven't seen you saying anything in quite a while) started off this discussion looking at secure email.  I would contend that we could solve one small piece of this puzzle:  We could build a secure IMAP server.  The IMAP API is complicated, but fairly well understood.  I believe we could write a security specification for that API - and we could build a sealed box that implements that API.  We'd have to figure out how to add and remove users, but that, too, could be a very simple API.  And that would be it:  The box would have no other exposed interfaces.  You could tailor its TCP implementation to inherently not support any other incoming ports.  It wouldn't need UDP - well, maybe for DNS - so don't include it.  Leave out everything but exactly what you need to support the external service offered.  To a large degree, this can even be automated - it's constant folding writ large.  Not in particular that providing a way to patch this thing should be the *last* thing you consider adding.

Could this be done?  I suspect so, though someone would actually have to set out to do it; they we'd know.  Is there a market for such a device?  Not the point - this would be a proof of technical capabilities, nothing else.  Could the underlying hardware be spiked?  Sure.  The best you would be able to say about the box is that it's as secure today as the day it was installed.

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.
                                                        -- Jerry