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

Barry Leiba <barryleiba@computer.org> Wed, 02 September 2015 22:06 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 A63B11A1BED for <saag@ietfa.amsl.com>; Wed, 2 Sep 2015 15:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 GBv2mj0PIb6C for <saag@ietfa.amsl.com>; Wed, 2 Sep 2015 15:06:46 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F45E1A8737 for <saag@ietf.org>; Wed, 2 Sep 2015 15:06:46 -0700 (PDT)
Received: by igbut12 with SMTP id ut12so25655726igb.1 for <saag@ietf.org>; Wed, 02 Sep 2015 15:06:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=oGl7PXR6sl5ci0LtSB4UiBYkLmkwKgJVH07GrE4ohLg=; b=Fus8qdWQ7hu+p1ziTlhk4Z7EXxwxsDMvZq5GLT0GHG8pshKiBGlAB+mvVi9kAVSQZN 6xXy5uhI2lPVqg4L0MiYe0kEb+JsFg9EBJobBPP79hpTyoVqffj9zW+HDqvQWzi/zADF L20qoMRvEUNhOHIQMKkSIcw0CRvNg9m8BnjG0sgY5e5ApfNEYxJvUZo/XyE1YMEBgiMA ZXUXC7dAaipqVP3cDn+FOw1U/xdww6V04i2HH7br22gclHg2E/m0QP39QOlKdzwc3E5g 4SAWAP3kQiUbQqR2UHS7HSsdHTNMsehPzQyD9b4pI4iXW+26y7nTgJcA7+C4owM1kqLm lrUw==
MIME-Version: 1.0
X-Received: by 10.50.83.104 with SMTP id p8mr7281596igy.90.1441231605444; Wed, 02 Sep 2015 15:06:45 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.107.17.24 with HTTP; Wed, 2 Sep 2015 15:06:45 -0700 (PDT)
In-Reply-To: <20150902040145.GD9021@mournblade.imrryr.org>
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> <tsl8u8pmzta.fsf@mit.edu> <92D9378E-4724-4721-A5F4-26614D96831E@gmail.com> <20150902040145.GD9021@mournblade.imrryr.org>
Date: Wed, 02 Sep 2015 18:06:45 -0400
X-Google-Sender-Auth: dM6XO2355QZqrDL1TPn9u1-R3u8
Message-ID: <CAC4RtVBJQX+B3XvnGnUpHbHdyw08Yn+CEGXML7K+c3q2pLNa7w@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: saag <saag@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/DLfdHraPB4wR-26CK0jvNNir9Bg>
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 22:06:47 -0000

(Responding to the thread in general, not to VIktor's note in particular.)

I honestly don't see why this issue is relevant to agility at all, and
I would just strike the mention altogether, as I don't think it
affects the point that we need to have the ability to change
algorithms baked into the protocol and designed into the software.

The point of OS is to negotiate the best security we can, and be
willing to accept a certain minimal security level, where the
definition of what's minimally acceptable will change from one
situation to another.

Algorithm agility can help us achieve that, and that might be worth
saying.  But whether in a particular OS situation we care willing to
negotiate something that we'd otherwise consider deprecated is a
question unto itself, not one that guidance on algorithm agility needs
to discuss.

Barry

On Wed, Sep 2, 2015 at 12:01 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> On Tue, Sep 01, 2015 at 11:09:23PM -0400, Kathleen Moriarty wrote:
>
>> I think the proposed text is a lot better than what was there and I think
>> there is consensus around it.  Once you get more specific, then you are
>> moving away from what was agreed upon in the OS draft.  Doing that would
>> require quite a bit more discussion.
>>
>> The proposed text reads well to me and keeps us more consistent - use of
>> weaker crypto for OS is limited to legacy deployments and is not okay for
>> authenticated and encrypted sessions for OS, just unauthenticated.  If
>> you have a proposal for text that keeps within the space where I think we
>> have consensus, then I'm okay with change otherwise I'm not.  It might
>> take reading through this draft and the OS RFC, once that has been done,
>> this text makes sense... Reading big through the discussion on this over
>> the past week or so may help as well.
>
> I am not saying the proposed text is wrong on its substance, rather
> I am a somewhat concerned about what seems to be misplaced emphasis.
> I think Sam agrees along essentially the same lines.
>
> I've not suggested a specific remedy, just throwing ideas out there
> and hoping they might be useful.
>
> In part I don't think I should be the only one doing all the
> explaining of OS, it is best if others can make additional
> contributions to the formulation of a refined consensus in this
> area.
>
> It would I think be better to note that OS (when unauthenticated
> and provies only passive protection) is not fundamentally about
> use of weaker crypto.  Rather it is about doing as much better than
> cleartext as one can, and agility is helpful, but more quickly on
> the uptake of new algos than deprecation of legacy algos, because
> interop considerations and avoiding cleartext trump the urgency of
> deprecating weak crypto.
>
> That said, that's just how I see it, and I don't want force my
> formulation on everyone else, so if there are other ways to improve
> the text (change of emphasis) that's fine.
>
> --
>         Viktor.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag