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

Tony Hansen <tony@att.com> Thu, 28 May 2015 15:26 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 D8EE71B2B80 for <kitten@ietfa.amsl.com>; Thu, 28 May 2015 08:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 KE2QK-u5LhlI for <kitten@ietfa.amsl.com>; Thu, 28 May 2015 08:26:29 -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 55D361B2B4B for <kitten@ietf.org>; Thu, 28 May 2015 08:26:29 -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 2a337655.0.6038705.00-2307.16356702.nbfkord-smmo05.seg.att.com (envelope-from <tony@att.com>); Thu, 28 May 2015 15:26:29 +0000 (UTC)
X-MXL-Hash: 556733a50b37e4f1-f1e7965acb2dc6cb3fd55f88b77298fd70d18e1e
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 t4SFQPEo000788 for <kitten@ietf.org>; Thu, 28 May 2015 11:26:26 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SFQNGR000761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <kitten@ietf.org>; Thu, 28 May 2015 11:26:24 -0400
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for <kitten@ietf.org>; Thu, 28 May 2015 15:26:03 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 t4SFQ3nj006469 for <kitten@ietf.org>; Thu, 28 May 2015 11:26:03 -0400
Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SFPxli006195 for <kitten@ietf.org>; Thu, 28 May 2015 11:25:59 -0400
Received: from tonys-macbook-pro.local (unknown[135.110.241.230](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150528152558gw1000cecqe>; Thu, 28 May 2015 15:25:59 +0000
X-Originating-IP: [135.110.241.230]
Message-ID: <55673385.6080006@att.com>
Date: Thu, 28 May 2015 11:25:57 -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.7.0
MIME-Version: 1.0
CC: "kitten@ietf.org" <kitten@ietf.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> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> <20150528171122.2bceebb6@latte.josefsson.org>
In-Reply-To: <20150528171122.2bceebb6@latte.josefsson.org>
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: [=9cW_t1CCXrUA:10 a=tHvJy1wsfNMA:10 a=grKcJhx5cuYA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=N659UExz7-8A:10 a=zQP7CpKOAAAA:8 a=h1Pgugrv]
X-AnalysisOut: [aO0A:10 a=31Yo1cYTXzT7QG4VKnkA: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/CxkB-XHs_iX7enZuItXLpsrdvWU>
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: Thu, 28 May 2015 15:26:32 -0000

On 5/28/15 11:11 AM, Simon Josefsson wrote:
>>> You then go on to say: "Personally, I would prefer to change to
>>> another mandatory channel binding that is secure for all TLS
>>> versions."
>> This is not really appropriate here because it's the applications that
>> need to do this, and we can't say anything here about this that will
>> force them to.
>> A reference to TLS-SESSION-HASH of the same level (i.e., normative
>> or informative) as RFCs 5246 and 5929 would be nice.
> I believe that what is required is
>
>   1) scram-sha256 has a normative reference to tls-session-hash; or
>
>   2) tls-session-hash uses an Update: that makes it applicapable to all
>   TLS versions, and that it is clarified (if not already the case) that
>   tls-session-hash must be used; or
>
>   3) scram-sha256 uses a new channel binding that is secure with or
>   without tls-session-hash.
>
> I believe 1) and 2) would be worse than 3) for the next ~5 years or
> so, and things being equal after that.  SASL libraries/applications
> rarely have any influence over TLS internals, but they directly
> influence the channel binding used.  Using another channel binding for
> hansen-scram-sha256 should not be difficult, as far as I can tell --
> SCRAM implementations needs to be changed to support the other stuff
> for SCRAM-SHA256 so they could just as well be modified to support a
> new channel binding too.  But I would not object to 1) or 2), if people
> prefer that.

Simon, right now scram-sha256 does not change anything in the SCRAM base
spec other than setting the hash mechanism to SHA256.

I *think* what you are asking for would actually be a change to the
SCRAM base spec, which so far has been out of scope for this document.

    Tony Hansen