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

ianG <> Fri, 24 July 2015 19:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0ECD71A0366 for <>; Fri, 24 Jul 2015 12:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Grzu3Q8176mg for <>; Fri, 24 Jul 2015 12:31:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C8361A00DC for <>; Fri, 24 Jul 2015 12:31:51 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id EEA076D748; Fri, 24 Jul 2015 15:31:49 -0400 (EDT)
Message-ID: <>
Date: Fri, 24 Jul 2015 20:31:48 +0100
From: ianG <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2015 19:31:53 -0000

On 18/07/2015 09: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 ;-). (
> 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.

The inability to deploy is one of the major criticisms of agility;  if 
there is zero deployment, then there is no point to agility, and it is 
likely doing harm (complexity plus consumption of resources).  Then, if 
there is some deployment, there is some benefit, but does it achieve 
profit?  The arguments begin...

The IETF's business is more about protocol drafts not deployments, so I 
would say that the agility refers to the ability of the protocol to be 
agile, and not towards deployment.  Therefore agility is achieved when 
the protocol has it, not when deployment is shown.  So I'd leave the 
text as it is.

However, because of this criticism, we can't get away without putting a 
warning in there that agility is strictly limited by its ability to 
deploy.  That seems to find itself in section 4. Security 
Considerations, especially last para.

So I think in essence the point is covered.