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

Russ Housley <housley@vigilsec.com> Thu, 03 September 2015 20:31 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 15C821B377B for <saag@ietfa.amsl.com>; Thu, 3 Sep 2015 13:31: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 nW4thuw8OaWZ for <saag@ietfa.amsl.com>; Thu, 3 Sep 2015 13:31:31 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8051A8A60 for <saag@ietf.org>; Thu, 3 Sep 2015 13:31:28 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id F23E7F2412B; Thu, 3 Sep 2015 16:31:17 -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 hFeCvr9kC+Y3; Thu, 3 Sep 2015 16:30:00 -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 12644F24126; Thu, 3 Sep 2015 16:30:57 -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: <55E83554.6010808@cisco.com>
Date: Thu, 3 Sep 2015 16:30:44 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <62CBD9E2-2DB4-4D3D-93E5-ADEB0F3D3C12@vigilsec.com>
References: <55A938F1.9090404@cs.tcd.ie> <20150720044849.GY28047@mournblade.imrryr.org> <B866063D-C1A8-4286-83E1-9EBAE7994297@vigilsec.com> <55E83554.6010808@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/AHruj7I3fgGKMhcBlH5hXXH6O5w>
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: Thu, 03 Sep 2015 20:31:33 -0000

Eliot:

We are talking about section 2.6...

>>   Without clear mechanisms for algorithm and suite transition,
>>   preserving interoperability becomes a difficult social problem.  For
>>   example, consider web browsers.  Dropping support for an algorithm
>>   suite can break connectivity to some web sites, and the browser
>>   vendor will lose users by doing so.  This situation creates
>>   incentives to support algorithm suites that would otherwise be
>>   deprecated in order to preserve interoperability.
> 
> Honestly this paragraph is confusing.  It's opaque because it's not
> clear whether you're aiming at a strawman of where TLS doesn't support
> agility or the case of long lived root or intermediate certificates.  If
> it's the former, can you find a more current example?  And the last
> sentence is just flat out ambiguous, although in an amusing sort of way
> (who deprecates in order to preserve interoperability?).

Kathleen also had a comment on this part of the document in her IESG ballot.

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
   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