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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 02 Mar 2015 19:23:36 +0000

On 25/02/2015 15:25, Simon Josefsson wrote:
> Tony Hansen <[email-masked]> 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.)

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Mar 2015 21:56:04 +0100

Alexey Melnikov <[email-masked]> writes:

> 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?

Please see:
https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Mar 2015 11:08:22 +0000

Hi Simon,

> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03
Great. Missed this earlier.

I am fine to recommend using your channel binding from 
draft-josefsson-sasl-tls-cb-03. I sent you a question about 
draft-josefsson-sasl-tls-cb-0. If you think they should be discussed on 
the mailing list, feel free to reply to my private email and CC the 
mailing list.