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

Kathleen Moriarty <> Sat, 18 July 2015 08:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A325F1AD151 for <>; Sat, 18 Jul 2015 01:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q9GdLPkaDt2R for <>; Sat, 18 Jul 2015 01:30:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 020311A6F04 for <>; Sat, 18 Jul 2015 01:30:23 -0700 (PDT)
Received: by wgmn9 with SMTP id n9so96950041wgm.0 for <>; Sat, 18 Jul 2015 01:30:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p4FSASH2RxjsBVpEq+BLRgxbRTSXUajKQA8WqQm0YaY=; b=BuOQn25ALGS3c9+4/eMK1+XkiYSx9B8Fy7xhrZ4PT5VxucfkqI9BZNmunhND4f5XmA 3lN6bpyKIpP4DsMNbtHhOx7rujqym+7m5EqIuztz4tnHxmwuZEEXqYbDF8vRqzvnEN9K CPHoX325oVZdMrLSZ2lJBbvMnuVmRnMn/j1dSVmIlXkR5QkIQ6Mj+zsmisXpc9q9HDbQ j9MXvaeQTK51uIp6zCPtbP9uhsqYcN6ov/KTyVhAPzPR0u6VHQgqNW26mHYwyLXPnCPR 3nWxwbFYUaKdMpyyRU0nTbpLkOC28AX6szSuiHbIr3eS7D6tnKlXmc3hUqo26aUIB1Ch oQaQ==
X-Received: by with SMTP id pv4mr39327886wjc.71.1437208221736; Sat, 18 Jul 2015 01:30:21 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id y1sm1512795wib.7.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Jul 2015 01:30:20 -0700 (PDT)
From: Kathleen Moriarty <>
X-Google-Original-From: Kathleen Moriarty <>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <>
Date: Sat, 18 Jul 2015 10:30:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Stephen Farrell <>
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: Sat, 18 Jul 2015 08:30:24 -0000


Sent from my iPhone

> On Jul 17, 2015, at 7:18 PM, Stephen Farrell <>; wrote:
> 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]
> 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?

I don't think we've really debated this enough to get consensus.  I don't think weaker algs fit into our agreed definitions for OS.  I just recall your debate with Pete on another draft, but think a wider debate is needed to see what the consensus is.  I don't think weaker algorithms should fit into the definition.

Best regards,
> 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
> _______________________________________________
> saag mailing list