[Cryptography] upgrade mechanisms and policies

[John Denker]

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

 *) It could be argued that in the absence of a decent
  policy, there's no point in having a mechanism.

 *) It could be argued that in the absence of a decent
  mechanism, there's no point in worrying about policy.

Each of those arguments is technically true, but irrelevant.
The point is, we will have to /solve the whole problem/ 
eventually, including both mechanism and policy.

  Suggestion #1:  This is a discussion group, not the
  patent office.  Brainstorming is allowed.  Incomplete
  ideas are allowed.  People are not required to 
  /solve the whole problem/ on Day One.

  On the other hand:  Suggestion #2:  Those who are 
  suggesting a mechanism should please acknowledge the
  need for a policy.  If they haven't got a policy, they
  should at least point out where a policy could be 
  plugged into their mechanism.

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.

Crypto itself provides some good examples:  We put
expiration dates on our session keys, PGP keys, x.509
certificates, et cetera.  Everybody knows in advance
that such things will have to be replaced.

The same approach could be applied to crypto primitives
and higher-level protocols.  It could be applied to the
Internet of Things and everything else.  We should plan
for the *fact* that such things have a finite useful
lifespan.  Life-cycle costs should be reflected in the 
purchase price.  We can only estimate the lifespan, but 
we should not assume a ridiculous overestimate.  An 
imperfect estimate is better than no estimate.  

Most importantly:  Once you have a mechanism for updating
the widget, you can do that ... even if the only thing
that changes is the expiration date!

Don't tell me that the IoT can't be upgraded.  The very
fact that the widgets are connected to the internet
makes them easy to upgrade, incomparably easy compared
to other things that we manage to renew every so often,
such as car tires, brake pads, and engine oil.  Doing
the IoT upgrade securely requires a bit of crypto, but
we are supposed to know how to do that.

===

Do we need a plan for dealing with emergencies?  Yes,
absolutely.  That's an important part of the elephant.

The only thing better than that is /preventing/ emergencies,
i.e. staying far far away from anything that could lead to 
an emergency.  In particular:  We should plan on replacing 
primitives and protocols /before/ we know for sure that 
they are broken.

As a corollary:  We can avoid "flag day" problems by
introducing the new thing on cycle N, then deprecating
the old thing on cycle N+2 and outlawing it on cycle
N+4.  This sort of well-planned transition works a lot 
better in non-emergency situations.