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

Joel Sing <jsing@openbsd.org> Mon, 31 August 2015 16:40 UTC

Return-Path: <gis-saag-2-moved1@m.gmane.org>
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 93CBC1B323A for <saag@ietfa.amsl.com>; Mon, 31 Aug 2015 09:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.088
X-Spam-Level:
X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 4UBw7MWwBFbH for <saag@ietfa.amsl.com>; Mon, 31 Aug 2015 09:40:09 -0700 (PDT)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D7C1B377F for <saag@ietf.org>; Mon, 31 Aug 2015 09:40:07 -0700 (PDT)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <gis-saag-2-moved1@m.gmane.org>) id 1ZWS7n-0007Se-Fu for saag@ietf.org; Mon, 31 Aug 2015 18:40:04 +0200
Received: from ppp118-209-173-126.lns20.mel8.internode.on.net ([118.209.173.126]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <saag@ietf.org>; Mon, 31 Aug 2015 18:40:03 +0200
Received: from jsing by ppp118-209-173-126.lns20.mel8.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <saag@ietf.org>; Mon, 31 Aug 2015 18:40:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: saag@ietf.org
From: Joel Sing <jsing@openbsd.org>
Date: Mon, 31 Aug 2015 16:38:00 +0000 (UTC)
Lines: 62
Message-ID: <loom.20150828T064228-679@post.gmane.org>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: sea.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 118.209.173.126 (Mozilla/5.0 (X11; OpenBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/o9kWb64UZz1lCFQtkWludlT7muo>
X-Mailman-Approved-At: Tue, 01 Sep 2015 08:14:17 -0700
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, 31 Aug 2015 16:40:11 -0000

Viktor Dukhovni <ietf-dane <at> dukhovni.org> writes:
> I should note, that premature deprecation of algorithms and/or
> protocol features by library maintainers who are not attuned to
> the needs of OS applications is already having detrimental effects.
> 
> For example, LibreSSL 2.2.2 has not only removed support for SSL
> 2.0 and SSL 3.0, but has also removed TLS server support for
> SSL-2.0-compatible HELLO.

I strongly recommend that you check your facts, in order to avoid 
distributing misinformation in a public forum:

- LibreSSL 2.2.2 has support for SSLv3 - it is disabled by default,
  however it can be re-enabled by an application at runtime (or by using
  the appropriate functions directly).

- LibreSSL 2.2.2 has server support for SSLv2 ClientHello messages and it 
  will not be removed any time soon.

> This means that servers linked with LibresSSL are unable to complete
> a TLS handshake with clients that have not yet disabled SSL 2.0
> and are still sending SSLv2-compatible HELLO.

This is inaccurate. I believe you are confusing this with a bug that was
introduced in the 2.2.2 release, which has already been fixed in 2.2.3. A 
TLS ClientHello that contained no extensions was incorrectly handled,
resulting in interoperability issues and handshake failures with some
clients.

> Such clients are not uncommon.  The Postfix user who ran into this
> problem reverted to linking Postfix with OpenSSL.  In the OpenSSL
> "master" branch (future 1.1.0), SSL 2.0 and SSL 3.0 are disabled
> just like in LibreSSL 2.2.2, but support for SSLv2-compatible HELLO
> is retained (on servers, but the client code will never send such
> a HELLO).
>
> It takes care and sound judgement to preserve interoperability,
> and not all applications have the same needs.  So while the
> "marketing" message needs to be clear and unequivocal (stop using
> obsolete crypto), in libraries the underlying technical changes to
> support that need to be constructed more carefully, and final
> removal may be the last step of a process that happens across
> multiple releases that gradually reduce support. 
> 
>     * Remove from use by default.
>     * Reduce relative preference.
>     * Require non-default compile-time options to enable.
>     * Remove the code.

You have practically just described the process that LibreSSL is using.
The main difference is the timeline under which the process is being
executed.

> Applications can move more aggressively, and use appropriate APIs
> to disable obsolete crypto faster because they are better positioned
> to know where to draw the line between security and interoperability
> with legacy systems.

Deprecation is difficult, since those who are doing it are often told
that they are doing the wrong thing, usually by people who try to discredit
the projects and teams that are busy making progress. Hopefully the
misinformation and inaccurate assertions above are not an example of this.