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

From: Shawn M Emery <[email-masked]>
Date: Fri, 08 Aug 2014 01:02:27 -0600

On 7/24/14 4:57 PM, Tony Hansen wrote:
> I just posted this update to the document I circulated back in April, 
> registering SCRAM-SHA-256 as a SASL mechanism.
>
> I added Minimum iteration-count and OID to the registration form for 
> SCRAM-* registrations.
>
> I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. This 
> should probably be discussed further.

I know RFC 3962 calls for 4096 rounds for SHA-1.  I haven't heard of 
anything that would make us want to change this.  Are there specific 
use-cases for this mechanism that would be negatively affected when 
choosing a higher iteration or is there guidance on policies when using 
this number of iterations or lower?

> One question I have for this: would it be worth change SCRAM 
> registrations to Expert Review in place of IETF review?

Do you envision a number of future mechanisms under the SCRAM* family?  
If not then I would prefer leaving it as IETF review.

> There was discussion in the HTTPAUTH working group this morning, 
> asking about the use of SHA2 as an HTTP mechanism instead of the SHA1 
> being discussed in Alexey's draft.
>
> An open question is whether this could/should become a working group 
> draft. I am happy with it being handled either that way or keeping it 
> an individual AD-sponsored draft. (I've already spoken with Steven and 
> Kathleen about that possibility.)

Speaking as co-chair; it has been a strain on the WG's resources with 
getting through the previous and current set of SASL work items.  So my 
initial position on this would be to have this draft AD-sponsored.

Shawn.
--
> -------- Original Message --------
> Subject: 	I-D Action: draft-hansen-scram-sha256-01.txt
> Date: 	Thu, 24 Jul 2014 15:49:56 -0700
> From: 	[email-masked]
> Reply-To: 	[email-masked]
> To: 	[email-masked]
>
>
>
> 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-01.txt
> 	Pages           : 5
> 	Date            : 2014-07-24
>
> Abstract:
>     This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
>     SHA-256-PLUS.  It also updates RFC 5802 in minor ways.
>
>
> 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:
> http://tools.ietf.org/html/draft-hansen-scram-sha256-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-01
>
>
> 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/
>
>
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Tony Hansen <[email-masked]>
Date: Fri, 08 Aug 2014 22:54:47 -0400

Thank you Shawn.

On 8/8/14, 3:02 AM, Shawn M Emery wrote:
>> I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. 
>> This should probably be discussed further.
>
> choosing a higher iteration or is there guidance on policies when 
> using this number of iterations or lower?

I am not aware of any guidance on how to choose an appropriate number of 
iterations.

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

> Do you envision a number of future mechanisms under the SCRAM* 
> family?  If not then I would prefer leaving it as IETF review.

I could envision a SHA3-based registration in the future, but I wouldn't 
guarantee it.

I'm personally of the opinion that registrations WITHIN a family should 
be lighter weight than registrations of mechanism families.

But I'm happy to go with WG consensus on the question.

>> an individual AD-sponsored draft. (I've already spoken with Steven 
>> and Kathleen about that possibility.)
>
> getting through the previous and current set of SASL work items.  So 
> my initial position on this would be to have this draft AD-sponsored.

As I said, I'm happy keeping it AD-sponsored. I would continue to keep 
the reviews within kitten. I'll pursue that further then.

     Tony

---

From: Russ Allbery <[email-masked]>
Date: Fri, 08 Aug 2014 21:15:42 -0700

> I am not aware of any guidance on how to choose an appropriate number of

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

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

-- 
Russ Allbery ([email-masked])              <http://www.eyrie.org/~eagle/>

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 9 Aug 2014 11:07:13 +0200

> I could envision a SHA3-based registration in the future, but I
> wouldn't guarantee it.
> 
> I'm personally of the opinion that registrations WITHIN a family
> should be lighter weight than registrations of mechanism families.

I think the reasoning for this was that introducing a new SASL
mechanism has no backwards compatibility issues so it causes no
problems -- however introducing a new SCRAM mechanism poses some more
complexity wrt negotiation and the GSS-API part that warrants more
thinking, hence more review requirements.

However in practice I think the SASL family concept introduces more
complexity and problems than it helps with, so I would prefer if all
SASL mechanisms were separate from each other or that the mechanisms
instead dictated their relationship rather than the framework.

/Simon