Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update

From: Yoav Nir <[email-masked]>
Date: Sun, 2 Jun 2013 14:14:52 +0000

On May 30, 2013, at 3:56 AM, Manu Sporny <[email-masked]> wrote:

> On 05/29/2013 05:15 AM, Yoav Nir wrote:
>> On May 29, 2013, at 11:37 AM, Stephen Farrell wrote:
>>> Question is: why not just add sha256 and be done with it?
>> 
>> People like algorithm agility. This might even save us from having
>> to process "SHA3-256 and its use in HTTP Authentication", "GOST R 
>> 34.11-94 and its use in HTTP Authentication", and the same for djb2 
>> and other algorithms.
> 
> I don't think that is a very compelling argument. The specification
> should outline the best practice at the time and if there is a need to
> update it to shift to another algorithm in the future, an add-on spec
> can be drafted purely for that case.
> 
> Dumping a bag of algorithms into a spec is also really annoying from an
> implementers standpoint. Making sure your implementation has support and
> options for umpteen hashing algorithms is annoying, especially when 90%
> of the use cases just use the same algorithms, and the other 9% could
> use the same algorithms, but choose not to because they think it buys
> them some sort of advantage (when it usually does not).
> 
> Bags of algorithms also confuse developers and make using the API really
> annoying in the default case where you just want to use a set of
> reasonable defaults. "Should I use SHA-256 or SHA-1? Hmm, let me see
> what the remote end is using... crap, they're using MD5."
> 
> The Web Keys specifications as well as the Web Payments specifications
> all outline one way of hashing and encrypting/decrypting. There are
> backups that are ready to go when the current approaches fail, but the
> specs outline the best practice and make that the only normative
> implementation requirement.
> 
> -1 to bags of algorithms in specs, we should stop this bad practice.

[No_hats]

I agree it's bad, but unless we want to create "digest2" that always uses SHA2-256, (and if we don't, switching to SHA3 would mean "digest3") we are going to have an algorithm field. And if we're going to have an algorithm field, we have to have a list of values to use there: SHA2-256; SHA3-256. And if we have a list of values, people are going to write specs to update that list with their favorite algorithm.

We could reduce the interop pain by having mandatory-to-implement algorithms, but mandatory to implement does not mean mandatory to deploy, and if someone from Russia tells you that authentication to websites that carry personal data requires the use of GOST algorithms, can any of us tell them they're wrong?

I could see having text like "compliant implementations of this specification MUST implement the SHA2-256 algorithm, and SHOULD have it enabled in deployment unless the legal situation mandates a different algorithm". It helps interop with those who would like to interoperate, while not forcing those with vanity crypto to make their own methods.

[/No_hats]

[Chair_hat on]

So far all the comments have been around this issue of multiple algorithms. Is this the only problem people have with this draft?  If so, then I would like to accept it, and immediately open an issue in the tracker. Then we can continue to discuss it on the list and in Berlin.

Any objections?

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 2 Jun 2013 07:32:19 -0700

> We could reduce the interop pain by having mandatory-to-implement algorithms, but mandatory to implement does not mean mandatory to deploy, and if someone from Russia tells you that authentication…

Yes. And we could tell the U.S. and { fill in your most or least favorite country } the same.

> I could see having text like "compliant implementations of this specification MUST implement the SHA2-256 algorithm, and SHOULD have it enabled in deployment unless the legal situation mandates a d…

And I'm with manu on this one: no algorithm agility other than "create a new spec".

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Sun, 2 Jun 2013 15:23:59 +0000

> And I'm with manu on this one: no algorithm agility other than "create a new spec".

And are you also OK with discussing this while the draft is a WG draft (rather than a candidate)?

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 02 Jun 2013 16:34:25 +0100

> And I'm with manu on this one: no algorithm agility other than "create a new spec".

I don't think Manu said "no alg agility" but rather, "pick one and a
backup." I agree with the latter but not the former.

And for Yoav: yes, I'm fine if you wanna make this a WG doc now.

S.

> 
> --Paul Hoffman
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 2 Jun 2013 16:05:51 +0000

I would be fine with "limited agility", but I do not think that "no agility" is a good idea.

Regards,
 Rifaat

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Farrell
> Sent: Sunday, June 02, 2013 11:34 AM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-
> auth-update
> 
> 
> 
> >> We could reduce the interop pain by having mandatory-to-implement
> algorithms, but mandatory to implement does not mean mandatory to
> deploy, and if someone from Russia tells you that authentication to
> websites that carry personal data requires the use of GOST algorithms,
> can any of us tell them they're wrong?
> >
> >> I could see having text like "compliant implementations of this
> specification MUST implement the SHA2-256 algorithm, and SHOULD have it
> enabled in deployment unless the legal situation mandates a different
> algorithm". It helps interop with those who would like to interoperate,
> while not forcing those with vanity crypto to make their own methods.
> >