IETF Logo Mail Archive

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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 July 2015 17:18 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC01D1ACCFE for <saag@ietfa.amsl.com>; Fri, 17 Jul 2015 10:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5gaie50oRyv for <saag@ietfa.amsl.com>; Fri, 17 Jul 2015 10:18:46 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E701ACD08 for <saag@ietf.org>; Fri, 17 Jul 2015 10:18:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46CA9BE77 for <saag@ietf.org>; Fri, 17 Jul 2015 18:18:44 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVWifcdDhbJX for <saag@ietf.org>; Fri, 17 Jul 2015 18:18:42 +0100 (IST)
Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E28B2BE56 for <saag@ietf.org>; Fri, 17 Jul 2015 18:18:41 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437153522; bh=vsu53bitIPq+iqvAhrYbwout2ty7/FBIKL7undd9QPw=; h=Date:From:To:Subject:From; b=DZjV1ULYrSWdIqPb5RCaxHZjEnX5eagpngRwVnYQGoQFwfbZPQaHQuNF9B3QCca8v hBuXCfA57mQG2eywZzCripGXklfYq5ff3a3OufEzEX5eXCSCZ03yGFlZIF7aA7+CAb VIylJfrrDdlBXpC6Zcc7+7X/+fQMCGtgdxTYjxu4=
Message-ID: <55A938F1.9090404@cs.tcd.ie>
Date: Fri, 17 Jul 2015 18:18:41 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "saag@ietf.org" <saag@ietf.org>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/260I2fxhfeX3tBd-cc355tI8Y0Y>
Subject: [saag] AD review of draft-iab-crypto-alg-agility-06
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2015 17:18:49 -0000

Hiya,

Russ has asked me to start IETF last call for this draft and I
plan to do that shortly. For WG drafts I usually post an AD
review before doing so, and that's below. I don't think any of
my comments need to be processed before starting LC so these
should be considered along with other last call comments
received.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility-06


Don't be put off by the filename, this is being proposed for the
IETF stream as a BCP.

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

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)

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

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

v2.23.0 | Report a Bug | By Email