Re: [kitten] AD sponsoring draft-hansen-scram-sha256

Tony Hansen <tony@att.com> Fri, 13 February 2015 19:32 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 1A7CF1A0117 for <kitten@ietfa.amsl.com>; Fri, 13 Feb 2015 11:32:57 -0800 (PST)
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 5y7N42H7hlts for <kitten@ietfa.amsl.com>; Fri, 13 Feb 2015 11:32:55 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E8C1A0115 for <kitten@ietf.org>; Fri, 13 Feb 2015 11:32:54 -0800 (PST)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 6615ed45.0.4180537.00-2168.11530877.nbfkord-smmo07.seg.att.com (envelope-from <tony@att.com>); Fri, 13 Feb 2015 19:32:55 +0000 (UTC)
X-MXL-Hash: 54de51677357e5bd-732ec525ac66ca837b759504fc4dd78469159800
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 t1DJWQhL005299 for <kitten@ietf.org>; Fri, 13 Feb 2015 14:32:53 -0500
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 t1DIq6gK008818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <kitten@ietf.org>; Fri, 13 Feb 2015 13:52:07 -0500
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>; Fri, 13 Feb 2015 18:51:57 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 t1DIpvXc031553 for <kitten@ietf.org>; Fri, 13 Feb 2015 13:51:57 -0500
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 t1DIpqfJ031337 for <kitten@ietf.org>; Fri, 13 Feb 2015 13:51:52 -0500
Received: from txcdtl01ks8671.itservices.sbc.com (txcdtl01ks8671.itservices.sbc.com?[135.110.240.237](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150213185150gw1000cebme>; Fri, 13 Feb 2015 18:51:51 +0000
X-Originating-IP: [135.110.240.237]
Message-ID: <54DE47C6.4060609@att.com>
Date: Fri, 13 Feb 2015 13:51:50 -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
To: Peter Saint-Andre - &yet <peter@andyet.net>, "kitten@ietf.org" <kitten@ietf.org>
References: <54DC00D0.2050900@cs.tcd.ie> <54DE1A1C.6020908@andyet.net>
In-Reply-To: <54DE1A1C.6020908@andyet.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=boL78jmi c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=mJp9S24oyUUA:10 a=UZBibCCZedwA:10 a=BLceEmwcHowA:10 a=N65]
X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=0HtSIViG9nkA:10 a=AwGr7gOs]
X-AnalysisOut: [GDYIhd7fnNoA: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/cJf5rJTDqLC291hHtrgEPwR8Kf8>
Subject: Re: [kitten] AD sponsoring draft-hansen-scram-sha256
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: Fri, 13 Feb 2015 19:32:57 -0000

Thanks Peter!

More below.

On 2/13/15 10:37 AM, Peter Saint-Andre - &yet wrote:
> On 2/11/15 6:24 PM, Stephen Farrell wrote:
>>
>> Hiya,
>>
>> I've been asked to AD sponsor draft-hansen-scram-sha256 [1] as it's
>> needed for some work in http-auth but doesn't quite fit with any
>> current WG. I plan to start an IETF LC for that shortly, but please
>> do let me know if there are any issues.
>>
>> This was previously discussed on the kitten WG list, so (with
>> the WG chairs' permission) I'd ask that you send any comments
>> there if you've any before I start the IETF LC. (Reply-to is
>> set to the kitten WG list.)
>
> This is a helpful document. Herewith a few comments.
>
> §2
>
>    For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers
>    SHOULD announce a hash iteration-count of at least 4096.
>
> Because (per RFC 5082) it is mandatory for the server to announce a 
> hash iteration-count, I'm wondering if that could be better expressed as:
>
>    For the SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL mechanisms, the
>    hash iteration-count announced by a server SHOULD be at least 4096.

ok

> §3
>
> It might be helpful here (or in the introduction) to describe why we 
> need these mechanisms, i.e., presumably they might have stronger 
> security properties or greater predicted longevity than the SCRAM 
> mechanisms based on SHA-1.

I'll add the following to the introduction (gladly re-using your suggest 
words):

     SHA-256 has stronger security properties than SHA-1, and it is 
expected that SCRAM
     mechanisms based on it will have greater predicted longevity than 
the SCRAM
     mechanisms based on SHA-1.

I don't think it's necessary to mention that the HTTP SCRAM document 
will probably reference it.

Seem okay?

> Nits:
>
> §1
>
> mechanism are defined -> mechanisms are defined

ack

> §4
>
> I doubt that we need RFC 2119 language in the form.

While I might agree, that text is copied directly from RFC 5802. I don't 
feel strongly enough about the use of mustard there to worry about it.

     Tony