Re: [saag] AD review of draft-iab-crypto-alg-agility-06

[Eliot Lear <[e-mail]>]

Hi David,

On 7/18/15 10:18 AM, Black, David wrote:
>>> intro, 3rd para: are we saying that agility is achieved when a
>>> protocol (specification) can easliy migrate from one suite to a
>>> better one, or when a deployment can easily migrate? The current
>>> text implies the former, but I'm not sure if we'd be better off
>>> aiming more for the latter.
>> +1
> IoT slippery slope warning, e.g., I have no idea how to update my
> refrigerator's firmware, and "Patch Tuesday" is not a great answer due
> to risks of spoiled food ;-). (https://en.wikipedia.org/wiki/Patch_Tuesday)
>
> I'd concur that deployment upgradeability is a worthy goal, but would
> suggest leaving exploration of details of how to pull that off to other
> drafts/forums.

Right.  In constrained environments it may be easier to disable
functionality rather than enable functionality on constrained
platforms.  This is already recognized in the introduction, and is
largely covered also in Section 3.2.  My suggestion is simply to add a
sentence in the last paragraph of that section prior to "The idea is to
have..." along the following lines:

Implementation of more than one MTI requires that each associated code
path be not just implemented but USED, so that any change from a mature
yet broken code path does not lead to a rash of problems with an
up-til-that-point unused code path.

Also that paragraph ends with what is indeed a challenge:

>    Also, the manner by
>    which system administrators are advised to switch algorithms or
>    suites is at best ad hoc, and at worst entirely absent.

One approach is to simply take this out of the hands of system
administrators and leave it in the hands of implementers, who can update
their code.  This can help chop the tail off of the laggard side of the
curve, but it's not always appropriate.  But it might make for a good
default behavior.

Eliot