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

Eliot Lear <lear@cisco.com> Sat, 18 July 2015 12:04 UTC

Return-Path: <lear@cisco.com>
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 8ED0C1B2BCB for <saag@ietfa.amsl.com>; Sat, 18 Jul 2015 05:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 1bLpSVHF-78o for <saag@ietfa.amsl.com>; Sat, 18 Jul 2015 05:04:41 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8821B2BCA for <saag@ietf.org>; Sat, 18 Jul 2015 05:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2864; q=dns/txt; s=iport; t=1437221081; x=1438430681; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+QA5/eOCt2qodHqGR/irdHzrVBKEj0HF8dQDkxHeKvQ=; b=Ay2nxiDGapaviqt7b+Pr1O82Ef7JG52tBLnFoEdxIbBcJVFXdV0FJN6T ExesHHCiwPwos6L2WRHf1Yogb7oJSmO2j+PmfEjIO09cmUReYj4stBBO9 wqPDc453+Gs+I0nht5DNRNdXtASfeP/dhJrAiB9DEwvh/07+d4CL65pze Q=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DZBAAZQKpV/xbLJq1bg2eEDLo7hXcCgWQRAQEBAQEBAYEKhCMBAQEDASNVAQULCxgJFgsCAgkDAgECAUUGAQwIAQGIIggNtlWVbwEBAQEBAQEBAQEBAQEBAQEBAQEVBIpKgQKFBgeCaIFDAQSUUoIzgVRohzKBQ4cIiCOIGSaCCIF2PIJ8AQEB
X-IronPort-AV: E=Sophos;i="5.15,499,1432598400"; d="asc'?scan'208";a="571211757"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 18 Jul 2015 12:04:39 +0000
Received: from [10.61.90.21] (ams3-vpn-dhcp6678.cisco.com [10.61.90.21]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6IC4crO004561; Sat, 18 Jul 2015 12:04:38 GMT
To: "Black, David" <david.black@emc.com>, Paul Hoffman <paul.hoffman@vpnc.org>
References: <55A938F1.9090404@cs.tcd.ie> <2F4FD8A9-2222-47E1-A895-003258D88E7C@vpnc.org> <CE03DB3D7B45C245BCA0D243277949361400A551@MX104CL02.corp.emc.com>
From: Eliot Lear <lear@cisco.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55AA40D9.4000505@cisco.com>
Date: Sat, 18 Jul 2015 14:04:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949361400A551@MX104CL02.corp.emc.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uT1MoAOSS832hQKtGUmluXOK64gNIfWnP"
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/9MausdOig1SNxFjxO6yNDL_WgVw>
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [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: Sat, 18 Jul 2015 12:04:42 -0000

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