Subject: [http-auth] 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: 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: Martin Thomson <[email-masked]>
Date: Mon, 16 Feb 2015 21:15:40 +1100

> 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

---

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:

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

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