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

Derek Atkins <derek@ihtfp.com> Fri, 04 September 2015 13:41 UTC

Return-Path: <derek@ihtfp.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 591BD1B43B9 for <saag@ietfa.amsl.com>; Fri, 4 Sep 2015 06:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 imt7dRyyLtOd for <saag@ietfa.amsl.com>; Fri, 4 Sep 2015 06:41:33 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0391B4A67 for <saag@ietf.org>; Fri, 4 Sep 2015 06:41:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 884CEE2035; Fri, 4 Sep 2015 09:41:31 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29724-06; Fri, 4 Sep 2015 09:41:28 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id CF956E2034; Fri, 4 Sep 2015 09:41:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1441374087; bh=b4c/noM1IEHEFmF321nd3XBZgIXS51gFm28JTESL3/A=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=MM+pKH5uGR29Gr0eNXimB90n9PRPEKPpYnLcD7FT1szpyQ4uhxrHHKpOzys/t20xO drLjlwKS2UWmr3YK/iw9qTfEEbYX+AtSXt9WdY7toOH8BMjSbdBj5oNC8lERAlPwCV gf3AbGm9pfzV+0ODrBfYRRraPxRiQzTSNkEtK6CY=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t84DfReL016345; Fri, 4 Sep 2015 09:41:27 -0400
From: Derek Atkins <derek@ihtfp.com>
To: Russ Housley <housley@vigilsec.com>
References: <55A938F1.9090404@cs.tcd.ie> <20150720044849.GY28047@mournblade.imrryr.org> <B866063D-C1A8-4286-83E1-9EBAE7994297@vigilsec.com> <55E83554.6010808@cisco.com> <62CBD9E2-2DB4-4D3D-93E5-ADEB0F3D3C12@vigilsec.com>
Date: Fri, 04 Sep 2015 09:41:27 -0400
In-Reply-To: <62CBD9E2-2DB4-4D3D-93E5-ADEB0F3D3C12@vigilsec.com> (Russ Housley's message of "Thu, 3 Sep 2015 16:30:44 -0400")
Message-ID: <sjmd1xy2tfc.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/nGCzinYJHvXkaa91ZBvX_EfcdRc>
Cc: 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: Fri, 04 Sep 2015 13:41:35 -0000

One spelling nit:

Russ Housley <housley@vigilsec.com> writes:

> I'm trying to address both comments with this proposal:
>
> 2.6.  Preserving Interoperability
>
>    Cryptographic algorithm deprecation is very difficult.  People do not
>    like to introduce interoperability problems, even to preserve
>    security.  As a result, flawed algorithms are supported for far too
>    long.  The impact of legacy software and long support tails on
>    security can be reduced by making it easy to transition from old
>    algorithms and suites to new ones.  Social pressure is often needed
>    to cause the transition to happen.
>
>    Implementers have been reluctant to remove deprecated algorithms or
>    suites from server software, and server administrators have been
>    reluctant to diable them over concerns that some party will no longer
--------------------^

This should be "disable", not "diable".

>    have the ability to connect to their server.  Implementers and
>    administrators want to improve security by using the best supported
>    algorithms, but their actions are tempered by the desire to preserve
>    connectivity.  Recently, some browser vendors have started to provide
>    visual warnings when a deprecated algorithm or suite is used.  These
>    visual warnings provide a new incentive to transition away from
>    deprecated algorithms and suites.
>
>    Transition in Internet infrastructure is particularly difficult.  The
>    digital signature on the certificate for an intermediate
>    certification authority (CA) [RFC5280] is often expected to last
>    decades, which hinders the transition away from a weak signature
>    algorithm or short key length.  Once a long-lived certificate is
>    issued with a particular signature algorithm, that algorithm will be
>    used by many relying parties, and none of them can stop supporting it
>    without invalidating all of the subordinate certificates.  In a
>    hierarchical system, many subordinate certificates could be impacted
>    by the decision to drop support for a weak signature algorithm or an
>    associated hash function.
>
>    Institutions, being large or dominant users within a large user base,
>    can assist by coordinating the demise of an algorithm suite, making
>    the transition easier for their own users as well as others.
>
> Russ

-derek

> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant