[Cryptography] upgrade mechanisms and policies

Natanael natanael.l at gmail.com
Tue Apr 7 14:11:48 EDT 2015


Den 7 apr 2015 18:33 skrev "John Denker" <jsd at av8n.com>:
>
> Multiple recent threads have been very interesting, but
> incomplete and unbalanced.  It is like the old parable:
> Each person is correctly describing their favorite /part/
> of the elephant without acknowledging its relationship
> to the other guy's part ... and to other parts heretofore
> not mentioned.
>
> For crypto primitives as well as higher-level protocols,
> all-too-often we lack both /mechanism/ and /policy/ for
> outroduction (at the end of the life cycle).

[...]

> As another way of saying the same thing:  If we don't
> like the mechanism, we should criticize the mechanism
> on its own terms, or suggest a better mechanism;  we
> should not blame the policy (or lack thereof).  Conversely,
> if we don't like the policy, we should criticize the
> policy on its own terms, or suggest a better policy;
> we should not blame the mechanism (or lack thereof).
>
> The overall job's not done until we have both mechanism
> and policy.
>
> ==========================
>
> This elephant has been seen before.  It is a classic
> fallacy in business management.  The business plan for
> some new widget always includes an introduction strategy,
> but all-too-often neglects the outroduction strategy.
> The guys promoting the new widget assume a ridiculously
> overoptimistic estimate of its lifespan.  The wise
> manager will slap those guys upside the head and tell
> them not to come back until they have a more grown-up
> business plan.
>
> This is related to the sunk-cost dilemma, which is the
> mirror image of the sunk-cost fallacy.  It is best
> understood in terms of game theory, rather than classical
> microeconomics.
>
> There exist workable models that we can look to for
> inspiration.  For example, several categories of
> aeronautical charts expire every 56 days.  The reason
> is that the effective date of the new chart serves
> as "flag day" for anything that needs to be changed,
> such as airway alignment, communication frequencies,
> et cetera.  Everybody knows in advance that the charts
> have to be replaced every 56 days, even if the only
> change is the expiration date.

Here's my thoughts:

If anybody protests against a device going offline if there's no security
patches available to apply: can you tell me what the alternatives are?
Let's say you use crypto because the device is security sensitive (and
almost everything is, at the very least to not become malware vectors for
other devices). If you believe the security hole is unlikely to be exposed,
why do you need crypto in the first place, what is it doing there? Because
if you believe it is protecting against something, you need to accept that
the protection can go away one day if the algorithms are flawed. So then
what, you're using something security sensitive and allowing it to be
exposed to attackers?

Second of all (slightly off topic, though), I'm thinking IoT absolutely
will need some form of local server for a reasonable level of extra
protection. The basic idea is this: the server acts as a proxy, and most
"smart" devices talks ONLY to the server. Absolutely nothing else. The
server has fairly standard APIs (stuff like KNX,  bacnet, etc). This
provides many benefits: easy access control, reduced exposure / attack
surface, easier to update (the server searches for updates and tracks
security alerts, the devices can be quite dumb in and of themselves). Now
you just have one device to worry about, not dozens, and it makes
firewalling infinitely easier. Deployment can be done in a number of ways,
the important thing is that the devices are securely paired dig the server.
My thoughts on that part:
https://roamingaroundatrandom.wordpress.com/2015/02/01/a-simple-method-of-key-verification-for-multi-device-key-exchange/

There's many reasons home servers should become a thing, this is just one
of them. And endless number of things would become much simpler with a
reliable always accessible trusted server in your home.

I agree that time limited software, protocols and algorithms is probably
needed. If you aren't planning for updates, then please tell me why your
believe your entire threat model isn't flawed. You're probably not going to
be the first person in the world to deploy perfect software on the first
attempt. If transitions and updates are part of the continous process
everybody participates in, there shouldn't be a problem. Now, the problems
are to set reasonable time limits and to get people to keep things updated
(the latter part would be greatly helped by the above mentioned servers
that also track updates, so that nothing is forgotten).

And for all the things not yet deployed with best before dates and
transition plans, I believe we do need one of these alert systems that's
been discussed as an option (cipher death notes, except it should apply to
every single component in all of the software). Define a reasonably
expressive syntax for what's broken and how, for the relevant metadata for
the bug, how to know if it applies to you (cipher names, package names,
etc), if it can be disabled and how, and what else you think is necessary.
Allow for multiple signatures, to assist policy making (defining which
organizations you trust alerts from).

Regarding ciphers and protocol versions, my thinking right now is that we
should go with the idea of having a tightly defined protocol with limited
or no options (in the official spec). But it should be designed to be
modular, so "emergency patches" doesn't require total rewrites - switching
ciphers should be easy (and private implementations with custom ciphers
also shouldn't be unnecessarily hard to maintain). And there should always
be a standby option ready to be deployed as version X.Y+1, the same moment
a flaw is exposed in the protocol which you have confirmed that the backup
doesn't suffer from. At every given point in time, the standby should be
the strongest known option to what's in the current protocol. Cipher
agility should be part of the design and process. And the old protocol
versions gets deprecated the moment they become insecure.

There should be no such thing as old versions with custom options being
more secure than the latest version on the defaults. You should be on the
latest version, and the latest version should be secure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150407/b40b56e1/attachment.html>


More information about the cryptography mailing list