[Cryptography] upgrade mechanisms and policies

[ianG]

On 7/04/2015 15:16 pm, John Denker wrote:
> 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).


(Nice neologism!  I wonder if a better spelling of that is outreduction ?)


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


That is more or less what I argue.


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


Right.  But we can't get to that stage until the fans of the mechanism 
realise that without a policy, the outcomes are unbalanced.


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


:)  And I think the discussion will be solved in this place, because it 
is a discussion group, with no "agenda" in mind.


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


Yes please.  And I think that this message will eventually make its way 
into better practice in writing protocol documents.  That is, if agility 
is part of the protocol, then a policy section or reference is a MUST.


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


Concur.

> ==========================

good stuff snipped.  That's what flag days are...

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


That is an important corollary of the upgrade mechanism & policy 
principle.  Once everyone has seen how we need a holistic approach -- if 
we are to include these upgrade possibilities -- it becomes much clearer 
that probably we want to have a more planned & conscious replacement of 
the old cruft before it becomes dangerous.


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


The "odds & evens" version replacement approach is what I think we'll 
drift to in the future, for those protocols have decided to dispense 
with the internal upgrade possibility.


iang