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

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Feb 2015 01:24:32 +0000

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

Thanks,
S.

[1] https://tools.ietf.org/html/draft-hansen-scram-sha256

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 13 Feb 2015 08:37:00 -0700

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

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

Nits:

§1

mechanism are defined -> mechanisms are defined

§4

I doubt that we need RFC 2119 language in the form.

Peter

---

From: Tony Hansen <[email-masked]>
Date: Fri, 13 Feb 2015 13:51:50 -0500

Thanks Peter!

More below.

On 2/13/15 10:37 AM, Peter Saint-Andre - &yet wrote:
> 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:
>

ok

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

> mechanism are defined -> mechanisms are defined

ack

> 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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 13 Feb 2015 13:09:51 -0700

Hi Tony, that all looks good!

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Feb 2015 10:48:25 +0100

> do let me know if there are any issues.

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.

A suggested (not even mandated) pbkdf iteration count of at least 4096
is unchanged since RFC 5802 -- I'd really like to see that be
significantly higher.  Back in 2000 an iteration count of 1000 was
recommended as the minimum.  Surely computational power has increased
more than a factor of four since then.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Feb 2015 11:54:57 +0100

Den Mon, 16 Feb 2015 21:15:40 +1100
skrev Re: [saag] AD sponsoring draft-hansen-scram-sha256:

> On 16 February 2015 at 20:48, Simon Josefsson <[email-masked]>
> wrote:
> > 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.
> 
> 
> We have a solution for that:
> https://tools.ietf.org/html/draft-ietf-tls-session-hash

Then SCRAM-SHA256 should normatively references that and require that
it is implemented for secure use of SCRAM with channel bindings.  There
are drawbacks with that approach: it is not widely implemented, not
published as an RFC that updates earlier TLS versions, and difficult
for SCRAM implementers to validate (usually the TLS stack is opaque to
the SCRAM implementer).  I could live with that though, as a way of
pushing the current security problem down from the IETF protocol layer
into the implementation layer.

Alternatively, use a new channel binding type that use the extended
master secret derivation as described by the document above.  I could
update draft-josefsson-sasl-tls-cb to describe this approach.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Feb 2015 11:10:01 +0000

Hi Simon,

On 16/02/2015 09:48, Simon Josefsson wrote:
  [snip]
> more than a factor of four since then.
I've heard complains from developers that 4096 with SHA-1 is too high 
for current Android phones. It would be good to get more information on 
performance before changing the number.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 16 Feb 2015 11:21:33 +0000

On 16 Feb 2015 11:10, "Alexey Melnikov" <[email-masked]> wrote:
> I've heard complains from developers that 4096 with SHA-1 is too high for
current Android phones. It would be good to get more information on
performance before changing the number.

Worth asking in the XSF, there's likely to be implementation experience
from the Android client devs there.

However, clients need only do the iterations once, if the salt is stable,
at least in principle.

>
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Feb 2015 12:22:53 +0100

Alexey Melnikov <[email-masked]> writes:

> for current Android phones. It would be good to get more information
> on performance before changing the number.

You will always hear complaints from developers that security features
adds computational and other resource costs.  When that happens, I
prefer asking myself whether the threat model motivates the cost or not.

/Simon

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Feb 2015 21:15:40 +1100

---

From: Sam Whited <[email-masked]>
Date: Wed, 18 Feb 2015 07:57:46 -0500

On Mon, Feb 16, 2015 at 6:21 AM, Dave Cridland <[email-masked]> wrote:
> Worth asking in the XSF, there's likely to be implementation experience from
> the Android client devs there.

I wrote the SCRAM-SHA-1 implementation in Conversations. While I don't
remember actual numbers off the top of my head, I can definitely tell
you that there is a noticable delay with a 4096 iteration count
(probably a little over half a second) on my HTC m7 (which is fairly
beefy as far as phones go). HOWEVER—

> However, clients need only do the iterations once, if the salt is stable, at
> least in principle.

—since we then store the session information in an LRU Cache in
memory, it's only slow when you first login. I've thought about moving
the session info to the database as well to make it even more
persistant, but decided it wasn't enough of a problem to bother
polluting the database.

Best,
Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Feb 2015 11:56:47 +0000

(list reduced to kitten)

> set to the kitten WG list.)

So I've seen positive responses, and some tweaks suggested which
are all to the good, so I'm happy to sponsor this work.

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)

2. justify and possibly mandate an iteration count with which folks
   are happy

Tony - could you propose text for #1 and #2 or start threads to
resolve them. Feel free to shoot out any revisions you think make
sense whilst doing that. And once we're done with those, and have
a draft that reflects the consensus then I'll start IETF LC.

Cheers,
S.

> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 
>

---

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 08:55:55 -0500

> persistant, but decided it wasn't enough of a problem to bother

We have implementations of both SCRAM-SHA-1 and SCRAM-SHA-256 on 
multiple phone platforms, both Android and iOS. Yes, it can be rather 
slow. But, as Sam says above, caching does mitigate the issue for 
subsequent uses.

This is why I pushed back when it was suggested before in KITTEN to 
raise the number higher than 4096.

     Tony Hansen

---

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 09:53:19 -0500

> a draft that reflects the consensus then I'll start IETF LC.

Thanks Stephen. I'll start separate threads for these.

     Tony

---

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 11:33:30 -0500

On 2/24/15 6:56 AM, Stephen Farrell wrote:
> resolved before IETF LC: ...
>

> more than a factor of four since then.

(Note: I think that recommendation of 1000 was for MD5, but let's assume 
SHA-1 in the following discourse.)

> prefer asking myself whether the threat model motivates the cost or not.

There is a balancing act with the minimum hash iteration count: 
usability versus security.

When this was last discussed in kitten last August, I brought the topic 
up myself, but I also noted that:

> I do know that we found 4096 iterations to be significant on a 
> handheld device, and I would *prefer* not raising it any higher. (We 
> would not be willing to change our existing implementation of 
> scram-sha-256 to a higher number unless there was a >>really good 
> reason<<.)

(This was specifically about 4096 iterations for SHA-256. SHA-1 runs 
better.)

A subsequent comment by Russ Allbery said:

> The rule of thumb that I was told by the CS crypto faculty at Stanford was
> to use a number of iterations such that string-to-key would take 0.1
> seconds on a computer with typical current performance.  That may or may
> not be practical, given...
>
>> I do know that we found 4096 iterations to be significant on a handheld
>> device, and I would*prefer*  not raising it any higher. (We would not be
>> willing to change our existing implementation of scram-sha-256 to a higher
>> number unless there was a >>really good reason<<.)
> ...you're already seeing performance issues with 4,096, and my testing
> showed that meeting that rule of thumb would require at least 14,500
> iterations of SHA-2 with PBKDF2.

So in 2000, the recommendation for SHA-1 was 1000. In 2010, the 
recommendation for SHA-1 was 4096 [RFC5082].

What is the definition for "typical current performance"? Should it be 
oriented toward mobile or oriented toward desktops or oriented toward 
super computers?

Does SHA-256 being slower than SHA-1 affect the answer any?

So, what to do for SCRAM-SHA-256?

One way to derive a recommended number might be to use a log scale 
between 2000's and 2010's numbers, extend it out to 2015, then reduce 
the number by some percentage to account for SHA-1 vs SHA-256 
performance. If my math is correct, and using a performance reduction of 
30%, this gives 4260, which is only a few percent away from my original 
recommendation of 4096 for SHA-2.

Or we could jump all the way up to 14500, as suggested by Russ.

Another possibility is to suggest two values: one for mobile use and one 
for non-mobile use.

Let the stones and arrows fly!

     Tony Hansen

---

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 11:50:32 -0500

>     some explanatory text about why that is good/needed)

To recap:

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

     Tony Hansen

---

From: Dave Cridland <[email-masked]>
Date: Tue, 24 Feb 2015 16:55:54 +0000

On 24 February 2015 at 16:33, Tony Hansen <[email-masked]> wrote many
things...

As a thought, is it not worthwhile to distill all this into a paragraph or
two within the Security Considerations, such as:

The strength of this mechanism is dependent in part on the iteration count,
as denoted by "i" in [RFC 5802]. As a rule of thumb, the 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.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Feb 2015 16:59:52 +0000

On 24/02/2015 16:55, Dave Cridland wrote:
>
> On 24 February 2015 at 16:33, Tony Hansen <[email-masked] 
> <mailto:[email-masked]>> wrote many things...
>
> As a thought, is it not worthwhile to distill all this into a 
> paragraph or two within the Security Considerations, such as:
>
> The strength of this mechanism is dependent in part on the iteration 
> count, as denoted by "i" in [RFC 5802]. As a rule of thumb, the 
> 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.
>
+1.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 24 Feb 2015 12:30:50 -0500

> where mobile use is less important.

Thank you Dave. I think this is an excellent path forward.

     Tony Hansen

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 25 Feb 2015 16:06:21 +0100

Tony Hansen <[email-masked]> writes:

> performance. If my math is correct, and using a performance reduction
> of 30%, this gives 4260, which is only a few percent away from my
> original recommendation of 4096 for SHA-2.
>
> Another possibility is to suggest two values: one for mobile use and
> one for non-mobile use.

I think there are at least two different considerations:

1) Language used.  As you quoted, the text now says that servers "SHOULD
announce at least 4096".  Using SHOULD already gives room for using
other values if there is good justification.  To split things into
mobile and non-mobile use-cases (which sounds like a bad idea for
several reasons to me) would require changing the language, as the
server normally doesn't know what type the client is.  Another idea is
to give two values but phrase it in a different way: one MUST minimum
value for protocol conformance (say 4096) and one RECOMMENDED value for
good protection in various deployments (say 14500).

2) How to decide the value.  I don't agree with the focus on performance
-- the reason for using PBKDF2 is to improve security, so the normal
approach to decide security parameters (compare key sizes) is that the
security needs dictate the requirements.  On one extreme, using 10
iteration count would be weak (although I can't cite attacks, maybe
because nobody uses 10 iterations...).  IMHO, the metric should be: how
many iterations raises the cost for an attacker so that it is no longer
a cost-effective way to crack the system?  Of course, different systems
will have different attack cost models, but we should give a ball-park
number applicable for common Internet applications.  I'm with Alexey
that current estimates are probably mostly guesses.  I don't know of a
established way to derive a better value.  However it feels weird for us
to not raise the value when we are revising the specification: surely
all attacks are more cost-effective as time passes by, so the value
should at least be incremented somewhat.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 25 Feb 2015 16:25:08 +0100

Tony Hansen <[email-masked]> writes:

> here. I'm thinking this would be best handled by adding something to
> the Security Considerations section. Does that seem right?
>

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.

/Simon