Subject: Re: [kitten] I-D Action: draft-hansen-scram-sha256-03.txt

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Aug 2015 16:57:36 +0100

Hi Tony, all,

The 2nd IETF last call for this is done. This thread is I think
the only thing that needs to be processed. (Please correct me if
I'm wrong.)

Tony - will you please make the changes described below and
submit a -04 with those in? (Feel free to check with folks beforehand
as to precise wording.)

If you can get that done in the couple of days I'll be happy to put
this on the Sep 3rd IESG telechat for approval. If it takes longer
(but pretty please, not so long this time:-) then it'll slip.

Cheers,
S.

On 28/07/15 22:11, Tony Hansen wrote:
> I'll work something in along these lines. Thanks for continuing to bang
> on this.
> 
>     Tony
> 
> On 7/28/15 4:49 PM, Simon Josefsson wrote:
>> Alexey Melnikov <[email-masked]> writes:
>>
>>> Hi Tony,
>>>
>>> On 28/07/2015 14:31, Tony Hansen wrote:
>>>> I will add this text to the security considerations section.
>>>>
>>>> This doc >is< updating RFC 5802 (the base SCRAM spec), so what do you
>>>> think of stating that this also applies to scram-sha-1?
>>> I am Ok with that. Although I suspect that most implementors are not
>>> going to look for this advice in your document.
>> I agree, so there is a problem.  To adress it, can we make the abstract
>> and introduction of scram-sha256 say that the document is ALSO adressing
>> a security problem in the base RFC 5802 specification?  Perhaps going as
>> far as modifying the title.  To me, this normative language related to
>> TLS-SESSION-HASH have importance to RFC 5802 implementers.
>>
>> How about modifying the abstract from:
>>
>>    This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
>>    SHA-256-PLUS.  It also updates the SCRAM registration procedures of
>>    RFC 5802.
>>
>> into
>>
>>    This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
>>    SHA-256-PLUS, and provide guidance for secure implementation of the
>>    original SCRAM-SHA-1-PLUS mechanism.  It also updates the SCRAM
>>    registration procedures of RFC 5802.
>>
>> And add to the Introduction section the following paragraph:
>>
>>   After publication of RFC 5802, it was discovered that TLS does not
>>   have the expected properties for the tls-unique channel binding to be
>>   secure [TLS-SESSION-HASH].  Therefor, this document contain normative
>>   text that applies to both the original SCRAM-SHA-1-PLUS and the newly
>>   introduced SCRAM-SHA-256-PLUS mechanism.
>>
>> I can't help but finish this repeating my rant that I don't think any of
>> this will be effective, and that we will face a long time of insecure
>> SCRAM-PLUS adoption.  Application writers in general cannot sufficiently
>> guarantee that their TLS stack always uses TLS-SESSION-HASH.  Alas, it
>> seems this approach is the most likely to reach consensus, and that
>> stalling this document further is not productive.
>>
>> /Simon
>>
>>>>      Tony
>>>>
>>>> On 7/26/15 9:34 AM, Alexey Melnikov wrote:
>>>>> On 20/07/2015 20:33, Simon Josefsson wrote:
>>>>>> Tony Hansen <[email-masked]> writes:
>>>>>>
>>>>>>> Note: I have NOT done anything about incorporating session
>>>>>>> hashing for channel binding, as I remain unconvinced that this is
>>>>>>> the right document to do anything about the topic. If you feel
>>>>>>> otherwise about having >this document< mention something about
>>>>>>> channel binding, >please< suggest specific text.
>>>>>> You may use:
>>>>>>
>>>>>> To be secure, SCRAM-SHA-256-PLUS has to be used over a TLS channel
>>>>>> that MUST have [TLS-SESSION-HASH] negotiated, or session resumption
>>>>>> MUST NOT have been used.
>>>>>>
>>>>>> [TLS-SESSION-HASH]
>>>>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash-06
>>>>>>
>>>>>> If this (or some other text) is not added, we would publish a
>>>>>> known insecure protocol without any discussion of the problem.
>>>>> I agree that this should be added. While the preferred way would be to
>>>>> update the base SCRAM specification, I think this note is still
>>>>> preferable to saying nothing.
>>>>>
>>>>>
> 
> 
> 
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Tony Hansen <[email-masked]>
Date: Tue, 25 Aug 2015 14:08:23 -0400

Stephen, I actually had an update almost complete, waiting for the LC to
finish. :-)

I've just submitted a -04. I feel that it addresses everything asked for
during LC. In particular, Simon, I hope the additions provide everything
you think is needed.

Diff can be found at
<https://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-04>.

    Tony

---

From: [email-masked]
Date: Tue, 25 Aug 2015 18:42:19 +0000

> Stephen, I actually had an update almost complete, waiting for the LC to

Fantastic, I'll look at it later and push it along.

S.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Aug 2015 21:38:38 +0200

Tony Hansen <[email-masked]> writes:

> during LC.

Thank you for your patience.

> In particular, Simon, I hope the additions provide everything you
> think is needed.

Not really, but I believe it provides what we can hope to find people
willing to write text on and gain consensus around at this point.  Which
is as good as it is going to get.  So effectively +1 from me.

> <https://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-04>.

* Why the colon in 'registers:' in the abstract?  It looks a bit strange
  to me.

* Typo 'provdes'.

/Simon

---

From: Tony Hansen <[email-masked]>
Date: Tue, 25 Aug 2015 15:45:43 -0400

I'm glad for the +1.

And thanks for pointing out the typos. I'll hold off on fixing them
though until AUTH48.

    Tony