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

Nico Williams <> Thu, 03 September 2015 21:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 83D861A1A6B for <>; Thu, 3 Sep 2015 14:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.366
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jaTjG1FqPz39 for <>; Thu, 3 Sep 2015 14:48:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2BDE41A8AFE for <>; Thu, 3 Sep 2015 14:48:13 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id C7F8C2005E629; Thu, 3 Sep 2015 14:48:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to;; bh=8vwsfMGI3iGi2/WQP5YRitclPf8 =; b=Fb5kM4nbJYwCQRYyVHHalz0ySbG6v6nnZpr/yOq1oDDW4lzApg5HP1dJEBg UZxnQuUtdqmByIcW2UK3FUUOlC28K7Phs6BmY/LxLISPxjPBQagifX9nGrX6cXAB Ka4f+dl3Pw9zUeDcO3FMbnD3uHydNK0qLZbjYXz9JVEwlRBk=
Received: from localhost ( []) (Authenticated sender: by (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 <>
Message-ID: <20150903214809.GE1541@localhost>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.