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

Nico Williams <nico@cryptonector.com> Thu, 03 September 2015 21:48 UTC

Return-Path: <nico@cryptonector.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 83D861A1A6B for <saag@ietfa.amsl.com>; Thu, 3 Sep 2015 14:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level:
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 jaTjG1FqPz39 for <saag@ietfa.amsl.com>; Thu, 3 Sep 2015 14:48:13 -0700 (PDT)
Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDE41A8AFE for <saag@ietf.org>; Thu, 3 Sep 2015 14:48:13 -0700 (PDT)
Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id C7F8C2005E629; Thu, 3 Sep 2015 14:48:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=8vwsfMGI3iGi2/WQP5YRitclPf8 =; b=Fb5kM4nbJYwCQRYyVHHalz0ySbG6v6nnZpr/yOq1oDDW4lzApg5HP1dJEBg UZxnQuUtdqmByIcW2UK3FUUOlC28K7Phs6BmY/LxLISPxjPBQagifX9nGrX6cXAB Ka4f+dl3Pw9zUeDcO3FMbnD3uHydNK0qLZbjYXz9JVEwlRBk=
Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 00C8D2005E623; Thu, 3 Sep 2015 14:48:11 -0700 (PDT)
Date: Thu, 3 Sep 2015 16:48:10 -0500
From: Nico Williams <nico@cryptonector.com>
To: saag@ietf.org
Message-ID: <20150903214809.GE1541@localhost>
References: <55A938F1.9090404@cs.tcd.ie> <20150720044849.GY28047@mournblade.imrryr.org> <B866063D-C1A8-4286-83E1-9EBAE7994297@vigilsec.com> <20150902212858.GM9021@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150902212858.GM9021@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/RqB4BlEMpUxFqBi4ba7uftMCxlA>
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: Thu, 03 Sep 2015 21:48:14 -0000

On Wed, Sep 02, 2015 at 09:28:58PM +0000, Viktor Dukhovni wrote:
> On Wed, Sep 02, 2015 at 04:48:38PM -0400, Russ Housley wrote:
>     2.5.  Cryptographic Key Management
> 
>        Traditionally, protocol designers have avoided more than one approach
>        to key management because it makes the security analysis of the
>        overall protocol more difficult.  When frameworks such as EAP and
>        GSSAPI are employed, the key management is very flexible, often
>        hiding many of the details from the application.  This results in
>        protocols that support multiple key management approaches.  In fact,
>        the key management approach itself may be negotiable, which creates a
>        design challenge to protect the negotiation of the key management
>        approach before it is used to produce cryptographic keys.
> 
>        Protocols can negotiate a key management 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 management 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.
> 
> Reading section 2.5 again, and being well versed in both TLS and
> GSSAPI (I commit code to both OpenSSL and Heimdal), I still have
> no idea what it is saying.  In what sense is "key management" (which
> for me means how keys are deployed and rotated) "negotiated" in
> the protocol.

I think what this is referring to is that *applications* may not get a
great deal of visibility into what happens at negotiation time.

Of course, local policy can still be applied ex-application, so that's
not fatal.

Any time you have a lot of options and layered frameworks we get this
problem.  Even plain TLS has quite a few things to represent to an
application that wishes to impose some policy.

The simplest approach, IMO, is to have local policy ex-application, with
applications at most naming a local policy to apply.

> Is this talking about "Key Exchange" rather than "Key Management"?
> Is the problem you have in mind that when, for example, negotiating
> "GSSAPI" in SASL one might not know what that entails before deciding
> to use GSSAPI over some other SASL mechanism?
> 
> Whatever this section is trying to say, I'm just not smart enough
> to figure it out, even with the hint in this response.

Because I've dealt (struggled) with this before, it's quite clear to me
what Russ intended to convey.  I agree that it's not necessarily clear
to others because the word "application" appears only once, in the first
paragraph.  So it can be made clearer.

Nico
--