Subject: Re: [kitten] [IANA #748877] please review SASL-SCRAM-256

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Apr 2014 00:17:59 +0200

Hi again,

I haven't seen anyone disagree with my interpretation that the
registration policy for new SCRAM-* mechanisms are "IETF Review", which
requires an RFC.  Therefor, I will suggest to IANA that they turn down
the registration request until that has been fulfilled.

Personally, I see nothing wrong with registering this, given that a
GSS-API OID is allocated at the same time.

/Simon

You wrote:

> Dear all,
> 
> We have received a request to register the SCRAM-SHA-256 and
> SCRAM-SHA-256-PLUS mechanism.  According to my understanding of what
> RFC 5802 section 10 says, the registration process is "IETF Review"
> http://tools.ietf.org/html/rfc5226#page-11 which requires an RFC, but
> I may be mistaken.  Anyway, suggestions on how to deal with the
> registration request is appreciated.
> 
> Having a SCRAM with SHA-256 seems like a fairly non-controversial
> thing to me.  There are interop aspects though, and the utility of
> defining a lot of variants could be debated.  I would like to see a
> GSS-API OID registered at the same time for any new SCRAM-SHA-* family
> member, but it seems we forgot to write a policy to make sure that
> happens.  Other thoughts?
> 
> /Simon
> 
> You wrote:
> 
> > Dear Simon,
> > 
> > IANA has received a request from Tony Hansen ([email-masked]) for two
> > new registrations in the SASL Mechanisms registry at
> > http://www.iana.org/assignments/sasl-mechanisms. 
> > 
> > Please let us know when the two-week review period on [email-masked]
> > is complete.
> > 
> > thanks,
> > 
> > Amanda Baber
> > IANA Request Specialist
> > ICANN
> > 
> > ===
> > 
> > IANA, please register the following:
> > 
> > To: [email-masked]
> > Subject: Registration of a new SASL mechanism SCRAM-SHA-256
> > 
> > SASL mechanism name (or prefix for the family): SCRAM-SHA-256
> > Security considerations: Section 7 of [RFC5802]
> > Published specification (optional, recommended): [RFC5802]
> > Person & email address to contact for further information:
> > IETF SASL WG <[email-masked]>
> > Intended usage: COMMON
> > Owner/Change controller: IESG <[email-masked]>
> > Note:
> > 
> > To: [email-masked]
> > Subject: Registration of a new SASL mechanism SCRAM-SHA-256-PLUS
> > 
> > SASL mechanism name (or prefix for the family): SCRAM-SHA-256-PLUS
> > Security considerations: Section 7 of [RFC5802]
> > Published specification (optional, recommended): [RFC5802]
> > Person & email address to contact for further information:
> > IETF SASL WG <[email-masked]>
> > Intended usage: COMMON
> > Owner/Change controller: IESG <[email-masked]>
> > Note:
> > 
>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Apr 2014 00:10:18 +0100

> the registration request until that has been fulfilled.

Yes, they're IETF Review.

Although RFC 5802 is generally hash agnostic, a handful of parts of SCRAM
are defined specific to SCRAM-SHA-1[-PLUS], including the minimum iteration
count for example, so an RFC might prove useful anyway.

Dave.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 10 Apr 2014 22:59:20 -0400

On 4/10/14, 7:10 PM, Dave Cridland wrote:
> On 10 April 2014 23:17, Simon Josefsson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Although RFC 5802 is generally hash agnostic, a handful of parts of 
> SCRAM are defined specific to SCRAM-SHA-1[-PLUS], including the 
> minimum iteration count for example, so an RFC might prove useful anyway.

OK, I figured it was worth trying to do it this way. I'll start the RFC 
process.

Dave, a question for you: What do you think a better minimum iteration 
count should be for SCRAM-SHA-256? Why should it be any different than 
the value specified for SCRAM-SHA-1 (4096)?

One of the items in 5802 that is out of date is the email address to 
send registrations to, as it specifies [email-masked] which no longer 
exists. So I think an update to that part of 5802 is needed to point to 
the kitten list. Thoughts? Are there any other updates needed for 5802?

Another question: should an RFC for SCRAM-SHA-256[-PLUS] register any 
other SCRAM mechanism?

     Tony Hansen

---

From: Russ Allbery <[email-masked]>
Date: Thu, 10 Apr 2014 20:20:10 -0700

> the value specified for SCRAM-SHA-1 (4096)?

It might be worth considering increasing the minimum iteration count to
something that takes appreciable time on modern hardware.  I've not tested
SCRAM-SHA-256, but PBKDF2 with SHA-256 requires around 15,000 rounds to
take 0.1 seconds on a typical desktop system.

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

---

From: Tony Hansen <[email-masked]>
Date: Thu, 10 Apr 2014 23:24:22 -0400

> take 0.1 seconds on a typical desktop system.

On the other hand, we've found that 4096 is somewhat onerous and barely 
tolerable on most smart phones.

     Tony Hansen

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Apr 2014 10:46:31 +0200

You wrote:

> > registration policy for new SCRAM-* mechanisms are "IETF Review",
> > which requires an RFC.  Therefor, I will suggest to IANA that they
> > turn down the registration request until that has been fulfilled.
> 

Although I noticed now that RFC 4402 says family mechanism instances are
expert review, so the requirements is a bit confusing.  However I think
what's in RFC 5802 has more weight regarding SCRAM, and I think this
was actually discussed before.

> minimum iteration count for example, so an RFC might prove useful

Yes, that and the GSS-API OID.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Apr 2014 12:35:40 +0200

You wrote:

> exists. So I think an update to that part of 5802 is needed to point
> to the kitten list. Thoughts? Are there any other updates needed for
> 5802?

There is a couple of RFC errata's already.  It may make sense to file
another one for the incorrect email address.

> Another question: should an RFC for SCRAM-SHA-256[-PLUS] register any 

It doesn't have to.

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Apr 2014 12:04:32 +0100

>> Although RFC 5802 is generally hash agnostic, a handful of parts of
SCRAM are defined specific to SCRAM-SHA-1[-PLUS], including the minimum
iteration count for example, so an RFC might prove useful anyway.
process.
> Dave, a question for you: What do you think a better minimum iteration
count should be for SCRAM-SHA-256? Why should it be any different than the
value specified for SCRAM-SHA-1 (4096)?

No idea. I just noted that the iteration count was specific to the hash
algorithm.

> One of the items in 5802 that is out of date is the email address to send
registrations to, as it specifies [email-masked] which no longer exists. So
I think an update to that part of 5802 is needed to point to the kitten
list. Thoughts? Are there any other updates needed for 5802?
other SCRAM mechanism?

Let me counter that with a question. Why pick SHA-256 in particular? Why
not jump to SHA-512, or SHA-3?

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