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

Russ Housley <housley@vigilsec.com> Mon, 07 September 2015 21:50 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 2DBA11B58E2 for <saag@ietfa.amsl.com>; Mon, 7 Sep 2015 14:50:01 -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 znwVogOCGWp0 for <saag@ietfa.amsl.com>; Mon, 7 Sep 2015 14:50:00 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EE3131B5A4F for <saag@ietf.org>; Mon, 7 Sep 2015 14:49:59 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9E6A9F2417D for <saag@ietf.org>; Mon, 7 Sep 2015 17:49:49 -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 3rUsEQ6tFPHI for <saag@ietf.org>; Mon, 7 Sep 2015 17:48:32 -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 B5DB7F24143 for <saag@ietf.org>; Mon, 7 Sep 2015 17:49:28 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20150907214128.GZ21942@mournblade.imrryr.org>
Date: Mon, 7 Sep 2015 17:49:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AA72C31-9BBE-4D7B-A62A-F705C19A2F33@vigilsec.com>
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> <20150907214128.GZ21942@mournblade.imrryr.org>
To: saag@ietf.org
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/sNYvOcmWijDe8kqbUvPEHbs8pyY>
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, 07 Sep 2015 21:50:01 -0000

On Sep 7, 2015, at 5:41 PM, Viktor Dukhovni wrote:

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

My intent is to give a heads up.  If there are too many layers, the application may not be able to do anything other than start the negotiation again.

Russ