[kitten] draft-hansen-scram-sha256 and the hash iteration count

Tony Hansen <tony@att.com> Tue, 24 February 2015 16:34 UTC

Return-Path: <tony@att.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 62C071A1A8F for <kitten@ietfa.amsl.com>; Tue, 24 Feb 2015 08:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id r2LdQrtL19R8 for <kitten@ietfa.amsl.com>; Tue, 24 Feb 2015 08:34:05 -0800 (PST)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9881A1A9D for <kitten@ietf.org>; Tue, 24 Feb 2015 08:33:54 -0800 (PST)
Received: from unknown [] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 1f7ace45.0.4904219.00-2387.13800259.nbfkord-smmo06.seg.att.com (envelope-from <tony@att.com>); Tue, 24 Feb 2015 16:33:54 +0000 (UTC)
X-MXL-Hash: 54eca7f27a74d008-34d69c864845c6f151f1d5a7be56b896ca172f98
Received: from enaf.aldc.att.com (localhost []) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXqH7028760 for <kitten@ietf.org>; Tue, 24 Feb 2015 11:33:53 -0500
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com []) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXlmF028714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <kitten@ietf.org>; Tue, 24 Feb 2015 11:33:51 -0500
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com []) by alpi131.aldc.att.com (RSA Interceptor) for <kitten@ietf.org>; Tue, 24 Feb 2015 16:33:35 GMT
Received: from aldc.att.com (localhost []) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXZCX018436 for <kitten@ietf.org>; Tue, 24 Feb 2015 11:33:35 -0500
Received: from mailgw1.maillennium.att.com (maillennium.att.com []) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1OGXViH018220 for <kitten@ietf.org>; Tue, 24 Feb 2015 11:33:31 -0500
Received: from tonys-macbook-pro.local (unknown[](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150224163330gw1000ceeke>; Tue, 24 Feb 2015 16:33:31 +0000
X-Originating-IP: []
Message-ID: <54ECA7DA.40203@att.com>
Date: Tue, 24 Feb 2015 11:33:30 -0500
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
CC: "kitten@ietf.org" <kitten@ietf.org>
References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie>
In-Reply-To: <54EC66FF.50603@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="------------000401040301070403080902"
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=V6DKJ5bi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=9cW_t1CCXrUA:10 a=mJp9S24oyUUA:10 a=6ASjcdcU7ckA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=4Qr2YTnE]
X-AnalysisOut: [bfVFj56_p2gA:9 a=QEXdDO2ut3YA:10 a=PXvjJup8crUr2pDL:21 a=D]
X-AnalysisOut: [uVDpGu2oBqJH4kU:21 a=E4mqhp5XrJEm3fLxLvcA:9 a=_W_S_7VecoQA]
X-AnalysisOut: [:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <tony@att.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ZV_p_Fe8LJR50sKZTVjV-10TNeo>
Subject: [kitten] draft-hansen-scram-sha256 and the hash iteration count
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2015 16:34:07 -0000

On 2/24/15 6:56 AM, Stephen Farrell wrote:
> But in addition, there were two substantive issues that ought be
> resolved before IETF LC: ...
> 2. justify and possibly mandate an iteration count with which folks
>     are happy

The issue here is this text in draft-hansen-scram-sha256:

>     For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers
>     SHOULD announce a hash iteration-count of at least 4096.

Simon Josefsson's comment in saag was:

> A suggested (not even mandated) pbkdf iteration count of at least 4096
> is unchanged since RFC 5802 -- I'd really like to see that be
> significantly higher.  Back in 2000 an iteration count of 1000 was
> recommended as the minimum.  Surely computational power has increased
> more than a factor of four since then.

(Note: I think that recommendation of 1000 was for MD5, but let's assume 
SHA-1 in the following discourse.)

Alexey Melnikov responded:

> I've heard complains from developers that 4096 with SHA-1 is too high 
> for current Android phones. It would be good to get more information 
> on performance before changing the number.

to which Simon responded:

> You will always hear complaints from developers that security features
> adds computational and other resource costs.  When that happens, I
> prefer asking myself whether the threat model motivates the cost or not.

There is a balancing act with the minimum hash iteration count: 
usability versus security.

When this was last discussed in kitten last August, I brought the topic 
up myself, but I also noted that:

> I do know that we found 4096 iterations to be significant on a 
> handheld device, and I would *prefer* not raising it any higher. (We 
> would not be willing to change our existing implementation of 
> scram-sha-256 to a higher number unless there was a >>really good 
> reason<<.)

(This was specifically about 4096 iterations for SHA-256. SHA-1 runs 

A subsequent comment by Russ Allbery said:

> The rule of thumb that I was told by the CS crypto faculty at Stanford was
> to use a number of iterations such that string-to-key would take 0.1
> seconds on a computer with typical current performance.  That may or may
> not be practical, given...
>> I do know that we found 4096 iterations to be significant on a handheld
>> device, and I would*prefer*  not raising it any higher. (We would not be
>> willing to change our existing implementation of scram-sha-256 to a higher
>> number unless there was a >>really good reason<<.)
> ...you're already seeing performance issues with 4,096, and my testing
> showed that meeting that rule of thumb would require at least 14,500
> iterations of SHA-2 with PBKDF2.

So in 2000, the recommendation for SHA-1 was 1000. In 2010, the 
recommendation for SHA-1 was 4096 [RFC5082].

What is the definition for "typical current performance"? Should it be 
oriented toward mobile or oriented toward desktops or oriented toward 
super computers?

Does SHA-256 being slower than SHA-1 affect the answer any?

So, what to do for SCRAM-SHA-256?

One way to derive a recommended number might be to use a log scale 
between 2000's and 2010's numbers, extend it out to 2015, then reduce 
the number by some percentage to account for SHA-1 vs SHA-256 
performance. If my math is correct, and using a performance reduction of 
30%, this gives 4260, which is only a few percent away from my original 
recommendation of 4096 for SHA-2.

Or we could jump all the way up to 14500, as suggested by Russ.

Another possibility is to suggest two values: one for mobile use and one 
for non-mobile use.

Let the stones and arrows fly!

     Tony Hansen