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

Russ Housley <housley@vigilsec.com> Mon, 07 September 2015 21:06 UTC

Return-Path: <housley@vigilsec.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 A43E71B5374 for <saag@ietfa.amsl.com>; Mon, 7 Sep 2015 14:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 x9rdL0D7Oicb for <saag@ietfa.amsl.com>; Mon, 7 Sep 2015 14:06:32 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6F1B4DC8 for <saag@ietf.org>; Mon, 7 Sep 2015 14:06:31 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 159F1F24192; Mon, 7 Sep 2015 17:06:22 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Z2hb4n4ibYLf; Mon, 7 Sep 2015 17:05:04 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 312A4F2415F; Mon, 7 Sep 2015 17:06:01 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <sjmd1xy2tfc.fsf@securerf.ihtfp.org>
Date: Mon, 07 Sep 2015 17:05:49 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <C76669F5-A021-4909-B681-F2865E3C3F17@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> <sjmd1xy2tfc.fsf@securerf.ihtfp.org>
To: Derek Atkins <derek@ihtfp.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/fLwjajulVeGPNsuSB8wIVBO8Sb4>
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: Mon, 07 Sep 2015 21:06:33 -0000

Fixed.  Thanks.


On Sep 4, 2015, at 9:41 AM, Derek Atkins wrote:

> 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