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

[Peter Saint-Andre - &yet <[e-mail]>]

Hi Tony, that all looks good!

On 2/13/15 11:51 AM, Tony Hansen wrote:
> 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