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

Tony Hansen <tony@att.com> Sat, 23 May 2015 00:17 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1EE1A87DF for <kitten@ietfa.amsl.com>; Fri, 22 May 2015 17:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omSPnB5tkZZl for <kitten@ietfa.amsl.com>; Fri, 22 May 2015 17:17:43 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3851A82E2 for <kitten@ietf.org>; Fri, 22 May 2015 17:17:43 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 427cf555.0.3309587.00-2350.8869247.nbfkord-smmo05.seg.att.com (envelope-from <tony@att.com>); Sat, 23 May 2015 00:17:43 +0000 (UTC)
X-MXL-Hash: 555fc727590aad44-9e2c28615b837dc9c5d6baf74420ecf2f9eb9f57
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0GdqZ027455 for <kitten@ietf.org>; Fri, 22 May 2015 20:16:39 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0Ga3c027451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <kitten@ietf.org>; Fri, 22 May 2015 20:16:39 -0400
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for <kitten@ietf.org>; Sat, 23 May 2015 00:16:23 GMT
Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0GOcq009460 for <kitten@ietf.org>; Fri, 22 May 2015 20:16:24 -0400
Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0GJmY009322 for <kitten@ietf.org>; Fri, 22 May 2015 20:16:19 -0400
Received: from tonys-macbook-pro.local (unknown[135.110.240.65](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150523001618gw1000cebve>; Sat, 23 May 2015 00:16:19 +0000
X-Originating-IP: [135.110.240.65]
Message-ID: <555FC6CF.5020306@att.com>
Date: Fri, 22 May 2015 20:16:15 -0400
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.6.0
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>, Simon Josefsson <simon@josefsson.org>
References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com>
In-Reply-To: <54F4B8B8.8090406@isode.com>
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)]
X-MAIL-FROM: <tony@att.com>
X-SOURCE-IP: [144.160.229.23]
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/bbohmhfGWjKoMR-mhVZqyI7Vbjo>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding
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: 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 <tony@att.com> 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:
>>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash
>>> 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