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

Derek Atkins <> Fri, 04 September 2015 13:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 591BD1B43B9 for <>; Fri, 4 Sep 2015 06:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id imt7dRyyLtOd for <>; Fri, 4 Sep 2015 06:41:33 -0700 (PDT)
Received: from ( [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB0391B4A67 for <>; Fri, 4 Sep 2015 06:41:32 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 884CEE2035; Fri, 4 Sep 2015 09:41:31 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 29724-06; Fri, 4 Sep 2015 09:41:28 -0400 (EDT)
Received: from (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by (Postfix) with ESMTPS id CF956E2034; Fri, 4 Sep 2015 09:41:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 (8.14.8/8.14.8/Submit) id t84DfReL016345; Fri, 4 Sep 2015 09:41:27 -0400
From: Derek Atkins <>
To: Russ Housley <>
References: <> <> <> <> <>
Date: Fri, 04 Sep 2015 09:41:27 -0400
In-Reply-To: <> (Russ Housley's message of "Thu, 3 Sep 2015 16:30:44 -0400")
Message-ID: <>
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: <>
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: Fri, 04 Sep 2015 13:41:35 -0000

One spelling nit:

Russ Housley <>; 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


> saag mailing list

       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant