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

Nico Williams <> Thu, 03 September 2015 22:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD3CB1A88ED for <>; Thu, 3 Sep 2015 15:18:59 -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 njb8WkUOEDMg for <>; Thu, 3 Sep 2015 15:18:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 846841A1F04 for <>; Thu, 3 Sep 2015 15:18:58 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 42086674058; Thu, 3 Sep 2015 15:18:58 -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=36N6XW0YYrgMO+vk/2vI7smuWLw =; b=InrNZLojemJR5dyh2ikaoOMf+3SmizHPaLT9LZYATrP1tcZHsDEICmFMNcU m0/YCQOPlXZV2C6SqUzqONT3xUac1LV0j36SGxJWuRdLdab/qzIJ1DZaJeR40Ow0 N/M7LzW11vCdi03wIFkuEnjHZ04XQ74t+fb0jn+yLv5h+5GA=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 9BF2F674057; Thu, 3 Sep 2015 15:18:57 -0700 (PDT)
Date: Thu, 3 Sep 2015 17:18:56 -0500
From: Nico Williams <>
Message-ID: <20150903221855.GF1541@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 22:18:59 -0000

Viktor asks me what the take-away from section 2.5 should be.  IMO it is
as follows.

Applications (app devs) and users are not in a good position to evaluate
cryptographic strength (and acceptability) of outcomes of protocol
negotiations, therefore this should be moved to local policy.  Local
policy includes defaults provided by implementors of security mechanisms
(TLS, Kerberos, etcetera).

This I-D, aiming to be a BCP, needs to outline a best practice as to
policy.  That best practice, IMO, is to give application developers and
users a very small control knob: a choice between named policies with
simple semantics.  "Strong", "normal", "opportunistic", "maximally
interoperable", "weak" -- these are both, good names and descriptions of
possible policies to apply; they are also good descriptors of outcomes.

Local policy should be expressible in some way, but it's OK if it's
hardcoded in implementations, as long as there are choices like the ones
I listed above, as those are the ones that applications and their users
need to apply.

It's OK -expected!- that the content of such policies will vary over
time because the relative strengths of cryptographic algorithms and
protocols vary over time as cryptanalysis improves.

Another take-away here is that implementors of security mechanisms and
frameworks really must provide interfaces by which to request a policy
to apply.  I.e., SASL, GSS, and others need a way for the application to
request a policy or check whether an outcome meets a given policy.  It's
not really enough to tell users to edit N configuration files,
especially if that makes it difficult to have more than one policy.

Now, local policy is NOT really part of a protocol.  So, this guidance
can't be for protocol designers.  It can be for framework API designers
(e.g., for us in KITTEN WG).  It can be for implementors of protocols
and frameworks.  That's OK, we can do that in a BCP.