Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding

Tony Hansen <> Sat, 23 May 2015 00:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8A1EE1A87DF for <>; Fri, 22 May 2015 17:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id omSPnB5tkZZl for <>; Fri, 22 May 2015 17:17:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C3851A82E2 for <>; Fri, 22 May 2015 17:17:43 -0700 (PDT)
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Sat, 23 May 2015 00:17:43 +0000 (UTC)
X-MXL-Hash: 555fc727590aad44-9e2c28615b837dc9c5d6baf74420ecf2f9eb9f57
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id t4N0GdqZ027455 for <>; Fri, 22 May 2015 20:16:39 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t4N0Ga3c027451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <>; Fri, 22 May 2015 20:16:39 -0400
Received: from ( []) by (RSA Interceptor) for <>; Sat, 23 May 2015 00:16:23 GMT
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id t4N0GOcq009460 for <>; Fri, 22 May 2015 20:16:24 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t4N0GJmY009322 for <>; Fri, 22 May 2015 20:16:19 -0400
Received: from tonys-macbook-pro.local (unknown[](untrusted sender)) by (mailgw1) with ESMTP id <20150523001618gw1000cebve>; Sat, 23 May 2015 00:16:19 +0000
X-Originating-IP: []
Message-ID: <>
Date: Fri, 22 May 2015 20:16:15 -0400
From: Tony Hansen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Alexey Melnikov <>, Simon Josefsson <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=b/AFFK6x c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=5hWoPXNsKEoA:10 a=ZXRAoOSSXYMA:10 a=BLceEmwcHowA:10 a=N65]
X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=h1PgugrvaO0A:10 a=48vgC7mU]
X-AnalysisOut: [AAAA:8 a=_EUyUsmAwj7DJXm3ejQA:9 a=pILNOxqGKmIA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
Archived-At: <>
Cc: "" <>
Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 May 2015 00:17:45 -0000

On 3/2/15 2:23 PM, Alexey Melnikov wrote:
> On 25/02/2015 15:25, Simon Josefsson wrote:
>> Tony Hansen <> writes:
>>> 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:
>>>> 1. a new channel binding or requiring tls-session-hash (and I guess
>>>>      some explanatory text about why that is good/needed)
>>> To recap:
>>> Simon Josefsson made this comment:
>>>> Since SCRAM was published, we have learned that the tls-unique channel
>>>> binding is insecure -- it would be nice if we could combine the SHA256
>>>> update with another default channel binding type to resolve that
>>>> problem.  In my view, the problem with SCRAM today isn't primarily its
>>>> use of SHA1 but it's broken channel binding.
>>> Martin Thompson responded:
>>>> We have a solution for that:
>>> I've read through tls-session-hash and am unsure how to proceed here.
>>> One of my goals when proposing SCRAM-SHA-256 was to not change the
>>> protocol at all, other than updating the hash algorithm.
>>> I'm not sure how to incorporate a recommendation for session hashing
>>> here. I'm thinking this would be best handled by adding something to
>>> the Security Considerations section. Does that seem right?
>>> Would anyone be willing to suggest text changes for these comments?
>> I believe the problem is that RFC 5802 is insecure as currently
>> specified, and we are bringing this up as a problem with your draft,
>> which is unfair to you since the problem was not introduced by you.
>> If people like the tls-session-hash approach (I'm not in that category,
>> but there may be consensus around it), the proper fix is to update RFC
>> 5802 and reference tls-session-hash as a normative reference.  This will
>> take care of the problem, as you could copy that text into your
>> document.  If you are looking for a text change here, it would be:
>>    To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel
>> that
>>    MUST have [TLS-SESSION-HASH] negotiated.
>> Personally, I would prefer to change to another mandatory channel
>> binding that is secure for all TLS versions.
> Before we make the decisions between referencing tls-session-hash
> versa a new channel binding, can you sketch out how the new channel
> binding is going to be defined?
> (If we choose to define a new channel binding, I think Kitten WG is
> the right place for doing this work.)

I added the following to the security section:

>     The strength of this mechanism is dependent in part on the
hash-iteration count, as denoted by "i" in
>     <xref target="RFC5802"/>.
>     As a rule of thumb, the hash-iteration count should be such that a
modern machine will take 0.1 seconds
>     to perform the complete algorithm; however this is unlikely to be
practical on mobile devices and
>     other relatively low-performance systems.
>     At the time this was written, the rule of thumb gives around
15,000 iterations required;
>     however an iteration count of 4096 takes around 0.5 seconds on
current mobile handsets.
>     This computational cost can be avoided by caching the ClientKey
(assuming the Salt and iteration count is stable).
>     Therefore the recommendation of this specification is that the
iteration count SHOULD be at least 4096, but careful
>     consideration ought to be given to using a significantly higher
value, particularly where mobile use is less important.

If anyone has suggestions for additions to this, or changes, please
suggest it now.

    Tony Hansen