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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 07 September 2015 21:41 UTC

Return-Path: <ietf-dane@dukhovni.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 91B491B4D06 for <saag@ietfa.amsl.com>; Mon, 7 Sep 2015 14:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] 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 wV4lpj4gty0X for <saag@ietfa.amsl.com>; Mon, 7 Sep 2015 14:41:30 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DC11B3F66 for <saag@ietf.org>; Mon, 7 Sep 2015 14:41:30 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EADFA283048; Mon, 7 Sep 2015 21:41:28 +0000 (UTC)
Date: Mon, 7 Sep 2015 21:41:28 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: saag@ietf.org
Message-ID: <20150907214128.GZ21942@mournblade.imrryr.org>
References: <55A938F1.9090404@cs.tcd.ie> <20150720044849.GY28047@mournblade.imrryr.org> <B866063D-C1A8-4286-83E1-9EBAE7994297@vigilsec.com> <20150902212858.GM9021@mournblade.imrryr.org> <20150903214809.GE1541@localhost> <CB751DCD-7A3D-4834-8287-FD3F8163492A@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CB751DCD-7A3D-4834-8287-FD3F8163492A@vigilsec.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/afUL3WrKov-t7tY2-_PIscJcvi8>
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
Reply-To: saag@ietf.org
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:41:31 -0000

On Mon, Sep 07, 2015 at 05:22:12PM -0400, Russ Housley wrote:

> 2.5.  Cryptographic Key Establishment
> 
>    Traditionally, protocol designers have avoided more than one approach
>    to exchanges that establish cryptographic keys because it makes the
>    security analysis of the overall protocol more difficult.  When
>    frameworks such as EAP [RFC3748] and SASL [RFC4422] are employed, key
>    establishment is very flexible, often hiding many of the details from
>    the application.  This results in protocols that support multiple key
>    establishment approaches.  In fact, the key establishment approach
>    itself is negotiable, which creates a design challenge to protect the
>    negotiation of the key establishment approach before it is used to
>    produce cryptographic keys.
> 
>    Protocols can negotiate a key establishment approach, derive an
>    initial cryptographic key, and then authenticate the negotiation.
>    However, if the authentication fails, the only recourse is to start
>    the negotiation over from the beginning.
> 
>    Some environments will restrict the key establishment approaches by
>    policy.  Such policies tend to improve interoperability within a
>    particular environment, but they cause problems for individuals that
>    need to work in multiple incompatible environments.
> 
> I hope the change in terminology helps.  Let me know.

The subject under discussion is now much more clear, this is I
think progress, thanks!  

The text might still use a bit more polish.  More importantly
though, is there an intended best-practice recommendation here?
Or if not, what is the intended purpose of this section?

-- 
	Viktor.