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

From: Tony Hansen <[email-masked]>
Date: Mon, 20 Jul 2015 04:54:31 -0400

The SCRAM-SHA-256 I-D has been updated.

   Changed from Informational document to Standards Track.

   Beefed up the Security Considerations (Section 4) section.

   At the request of IANA, reworked the IANA Considerations (Section 5)
   section.

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.

    Tony Hansen

On 7/20/15 4:46 AM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms
>         Author          : Tony Hansen
> 	Filename        : draft-hansen-scram-sha256-03.txt
> 	Pages           : 8
> 	Date            : 2015-07-20
>
> Abstract:
>    This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
>    SHA-256-PLUS.  It also updates the SCRAM registration procedures of
>    RFC 5802.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-hansen-scram-sha256-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Jul 2015 21:33:30 +0200

> document< mention something about channel binding, >please< suggest

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.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 26 Jul 2015 14:34:08 +0100

On 20/07/2015 20:33, Simon Josefsson wrote:
>> 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] 
> 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.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Jul 2015 09:31:21 -0400

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?

    Tony

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Jul 2015 09:40:31 -0400

Make that "applies to scram-sha-1-plus". Here is my proposed text:

        To be secure, SCRAM-SHA-256-PLUS and SCRAM-SHA-1-PLUS MUST
either be used over a TLS channel that
        has had [ID.ietf-tls-session-hash] negotiated, or session
resumption MUST NOT
        have been used.

- Tony Hansen

On 7/28/15 9:31 AM, Tony Hansen wrote:
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 28 Jul 2015 14:48:40 +0100

Hi Tony,

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

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Jul 2015 09:53:48 -0400

I agree. However, it's the best mechanism we have.

    Tony

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Jul 2015 22:49:02 +0200

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

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

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Jul 2015 17:11:30 -0400

I'll work something in along these lines. Thanks for continuing to bang
on this.

    Tony