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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 26 August 2015 10:48 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 F0A901ACDE1 for <saag@ietfa.amsl.com>; Wed, 26 Aug 2015 03:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 jmne7EY27agA for <saag@ietfa.amsl.com>; Wed, 26 Aug 2015 03:48:09 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A4B1ACD6B for <saag@ietf.org>; Wed, 26 Aug 2015 03:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1440586089; x=1472122089; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pjeITi40Q1V9Ih+VSzyrMKWeI9TdfarqI5bbOmsI9vU=; b=OYmScKsaB1qtauaDBELrPMiRp+olcYGuef9HOEy9VRPD9MdQB34qOJyw jH7plzYgYJmHzUyhlj6TlWJCQxpqIWHu8x9RsLjCd/GknTi2v7SPRTpbK iGzYE2L8svfoYC8edY54U+ht4ZuOlrgOJ9eOVgRN0bE1aFi5TkB5dY7wg Epi0wtn2COvF06CJGjdYRPS0BV2BqeeWGJdNQ3sMfr+LuCqkEDqn4REQG 8NLdfD3iNC0z8Z5NxDFlYJgyn20Z3FjjtoPo+LhBZw02mheZbyoRIfNiK 65sWwnxR67YBJ8ZNmDw2QYsZl9NYT0mqvn75vTLaE9QeEp9IQcbv7vA1G w==;
X-IronPort-AV: E=Sophos;i="5.17,415,1437393600"; d="scan'208";a="37803690"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Aug 2015 22:48:07 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 26 Aug 2015 22:48:07 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [saag] AD review of draft-iab-crypto-alg-agility-06
Thread-Index: AQHQ3qvbT9ZhMqG4SESDb9hHYel1Rp4a4U6AgAAA+wCAAAUHgIABabjA//+gh4CAACG1AIAABjkAgAAFlYCAABR0gIAARFKAgAGj6uI=
Date: Wed, 26 Aug 2015 10:48:07 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AE7336@uxcn10-5.UoA.auckland.ac.nz>
References: <CAHbuEH7B3_G9vAhw=U2tuz-Uh8mKMUfL6s=H+BOG96FDZaACig@mail.gmail.com> <20150824212907.GN9021@mournblade.imrryr.org> <619ffebb05ba4e2a9af03a6dcc768d6e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150824215037.GO9021@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4AE62A1@uxcn10-5.UoA.auckland.ac.nz> <20150825134333.GX9021@mournblade.imrryr.org> <6b5167f3d0684a8a91caa6d37dec65e3@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150825160627.GH9021@mournblade.imrryr.org> <CAHbuEH5r5s8ofChzt0_Rd8dxKqf8KXLDteYw8RSBX43nyFrN+A@mail.gmail.com> <2E7E9F38-DA68-4933-AD67-CF2A8E51B4F7@dukhovni.org>, <20150825214411.GS9021@mournblade.imrryr.org>
In-Reply-To: <20150825214411.GS9021@mournblade.imrryr.org>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/0C_9boQsApHgNWQFpHmGva5JSqE>
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: Wed, 26 Aug 2015 10:48:13 -0000

Viktor Dukhovni <ietf-dane@dukhovni.org>; writes:

>    * Remove from use by default.
>    * Reduce relative preference.
>    * Require non-default compile-time options to enable.
>    * Remove the code.

That's more or less what I use, specifially, "make the option least-
preferred", then "require a custom compile", then "remove the code", with an
occasional "reinsert the &*)(($)@ code because some widely-used app is still
living 15 years in the past".

The problem with trying to handle backwards-compatibility is that the long
tail never actually reaches zero but instead tends toward some (non-zero)
constant of users who will never upgrade if they're not forced to.  This is
why you can't maintain backwards-compatibility for ever, some users have to be
forced to upgrade.  What I typically do is make something a compile-time
option that's not enabled in any standard build, so they have the option to
enable the deprecated behaviour at the expense of building and distributing
custom binaries to do so.  Suddenly the absolutely-impossible-can-never-be-
done upgrade magically becomes possible, because the cost of not upgrading has
become nonzero.  The trick is figuring out how nonzero to make it, and on
which time schedule.

Peter.