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

Sam Hartman <hartmans-ietf@mit.edu> Wed, 02 September 2015 00:26 UTC

Return-Path: <hartmans@mit.edu>
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 2C76C1ACDEA for <saag@ietfa.amsl.com>; Tue, 1 Sep 2015 17:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
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 9zIxe1rJzEDU for <saag@ietfa.amsl.com>; Tue, 1 Sep 2015 17:26:29 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883AC1ACDF0 for <saag@ietf.org>; Tue, 1 Sep 2015 17:26:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2FCE7207C3; Tue, 1 Sep 2015 20:24:19 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyB0-0IEV4vu; Tue, 1 Sep 2015 20:24:18 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 1 Sep 2015 20:24:18 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56053808FA; Tue, 1 Sep 2015 20:26:25 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Russ Housley <housley@vigilsec.com>
References: <CAHbuEH6w+O-TSA9SRP-9TrM+Hdh+vn7Me+tdJrFTNY_-Nbenug@mail.gmail.com> <20150901165526.GU9021@mournblade.imrryr.org> <4F6E430F-61E7-46BA-9B4A-8E12156B62FA@vigilsec.com> <20150901211906.GA9021@mournblade.imrryr.org> <E44EE5B3-1469-49D7-9C15-299230E13779@vigilsec.com>
Date: Tue, 01 Sep 2015 20:26:25 -0400
In-Reply-To: <E44EE5B3-1469-49D7-9C15-299230E13779@vigilsec.com> (Russ Housley's message of "Tue, 1 Sep 2015 19:56:16 -0400")
Message-ID: <tsl8u8pmzta.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/IZgqfACsOA6FbFVFCT7qubgXIQA>
Cc: saag@ietf.org
Subject: Re: [saag] Section 2.9: was Re: 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: Wed, 02 Sep 2015 00:26:31 -0000

>>>>> "Russ" == Russ Housley <housley@vigilsec.com> writes:

    >> I still think that the focus on just the weak(er) algorithms in
    >> OS is unfortunate.  Rather agility and OS work hand-in-hand to
    >> improve communications to the extent possible.  As new algorithms
    >> are deployed, opportunistic peers will autmatically start to use
    >> stronger cryptography.
    >> 
    >> Once new algorithms have largely displaced legacy algorithms, one
    >> can begin considering retirement of algorithms that used to be
    >> required for interoperability.  This process is likely to take
    >> longer for OS protocols/applications because interoperability
    >> carries greater weight when security is not a hard requirement
    >> and the alternative is cleartext.
    >> 
    >> So I'd like to see text that first emphasises the good news (over
    >> time agility improves the security of OS protocols).  Then the
    >> bad news (retirement of legacy crypto takes longer).  And finally
    >> notes that OS is not carte-blanche for weak crypto, new OS
    >> applications need to start with non-deprecated crypto, and legacy
    >> crypto needs to still be retired once no longer needed.

    Russ> The whole point of the document is to make it easy to migrate
    Russ> from one algorithm suite to another more desirable one.
    Russ> However, sometimes we want to keep an algorithm around that
    Russ> would otherwise have been discarded to achieve opportunistic
    Russ> security.  You seem to be trying to pull the points from the
    Russ> rest of the document into this paragraph.

Russ, like Viktor, when I read the proposed text for section 2.9 I hear
emphasis on supporting weak crypto for OS.  The text doesn't quite come
out and say any of the following, but I find myself trying to come up
with justifications for why I'd prefer weak crypto for OS.  Is it
faster?  Is it more exportable?  By the time I get to the sentence that
says stronger is still preferable, I'm so lost that it hardly registers.

I find the quoted paragraph sounds like it's trying to be more divergent
with the rest of the document rather than complimentary.
So, while perhaps literally doing what Viktor proposes and including all
those points in 2.9 would be redundant, perhaps we can strive for
something more consistent with his approach.

What the proposed text says is all consistent, it just reads wrong and
at least to me and apparently Viktor implies things that I don't think
we really mean.

I'm sorry I can't be more helpful.  I'm not trying to raise anything
blocking, just hoping to help you better understand the explanation.