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

[Tony Hansen <[e-mail]>]

On 3/2/15 2:23 PM, Alexey Melnikov wrote:
>
> On 25/02/2015 15:25, Simon Josefsson wrote:
>> Tony Hansen <[e-mail]> 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