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

Russ Housley <> Mon, 07 September 2015 21:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1C7B51A8833 for <>; Mon, 7 Sep 2015 14:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lJYgNnvFV4wR for <>; Mon, 7 Sep 2015 14:22:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 066321A898C for <>; Mon, 7 Sep 2015 14:22:55 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 69F89F24177; Mon, 7 Sep 2015 17:22:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j-dFtlmFpYWd; Mon, 7 Sep 2015 17:21:27 -0400 (EDT)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id B05C2F24143; Mon, 7 Sep 2015 17:22:23 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <>
In-Reply-To: <20150903214809.GE1541@localhost>
Date: Mon, 7 Sep 2015 17:22:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <20150903214809.GE1541@localhost>
To: Nico Williams <>, Viktor Dukhovni <>
X-Mailer: Apple Mail (2.1085)
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: Mon, 07 Sep 2015 21:22:56 -0000

Nico and Viktor:

Late last week, you each made comments on Section 2.5.  I have tried to address them.  The text in my edit buffer is:

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.