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

"Paul Hoffman" <> Fri, 17 July 2015 20:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BBA911A1C02 for <>; Fri, 17 Jul 2015 13:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.953
X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lQY_C9hg39Yx for <>; Fri, 17 Jul 2015 13:51:13 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF94B1A1BFA for <>; Fri, 17 Jul 2015 13:51:12 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.15.1/8.14.9) with ESMTPSA id t6HKp3vC048373 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jul 2015 13:51:04 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: "Paul Hoffman" <>
To: "Stephen Farrell" <>
Date: Fri, 17 Jul 2015 13:51:03 -0700
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <>
Cc: "" <>
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, 17 Jul 2015 20:51:13 -0000

On 17 Jul 2015, at 10:18, Stephen Farrell 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.


> 2.1: "Algorithm identifiers, on the other hand, impose a burden on
> implementations by forcing a determination at run-time regarding
> which algorithm combinations are acceptable." Here you mean IPsec
> style or chinese menu style alg ids. Do we need to make sure that
> alg id and suite id are used consistently throughout as one or the
> other but not both, and do we need a new term that means either? (I
> find this clear enough, but I'm not sure if it might confuse some
> readers.)

This is not necessarily about "pick one from each column". For example, 
an S/MIME implementation has to decide whether to accept a particular 
algorithm for authentication if it has a policy "always strong crypto".

> 2.3: "a mechanism is needed to determine whether the new algorithm
> has been deployed" I think that's overstated, maybe
> s/needed/desirable/ would be better?  (maybe with a bit more
> wordsmithing)

+1. "mechanism" is overstated (although "policy" is usually a mess...).

> 2.4: The SHOULD for integrity only applies when the negotiation is
> done over the network, but some "selection" methods might not need
> protocol integrity mechanisms. Maybe drop "selection" there?
> 2.4: Maybe join paras 2 and 3, para 2 alone reads a little oddly
> 2.9: I'm not really a fan of blessing weaker algs for OS, but I lost
> that argument before. I wonder if we would get consensus if this
> said that weak algs are better than no encryption but still MUST be
> deprecated as soon as feasible?
> 3.1, 1st para: I think this could do with some more editing.
> 3.2: "some people say" is a bit too weasel-wordy

Disagree. We don't have solid statements from enough believable parties 

> 3.2: the second para here is repetition, I think you could delete
> all or almost all of that
> 4: "eliminate the cruft" - yes, I like that:-)
> general: there are some typos throughout, another pass to fix those
> would be good but I didn't have time to note them all sorry

--Paul Hoffman