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

From: Matthew Lepinski <[email-masked]>
Date: Tue, 28 May 2013 21:04:37 -0400

The HTTP-AUTH working group is chartered to produce a specification
updating HTTP Digest Authentication.

The following document has been submitted to the chairs as a potential
starting point for the working group's efforts on digest authentication:
draft-ahrens-httpbis-digest-auth-update-00

We are therefore asking the working group if you support
adopting draft-ahrens-httpbis-digest-auth-update as a working group
document to serve as a starting point for digest authentication work.

Note that this document is only a starting point and not a complete
solution. Indeed, the document does not address the issue of
internationalization, and text would need to be added in a future (See for
example, the following proposal
http://www.ietf.org/mail-archive/web/http-auth/current/msg01264.html)

The chairs are not currently aware of any alternative drafts that might
serve as as starting point for our work.

Thanks,

Yoav & Matt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 May 2013 09:37:06 +0100

So I've two questions before I'd say yes, but would
like to see the WG do this work so we can finally
obsolete 2617.

- What are the other deficiencies hinted at in 2.1.2
that are not being fixed (other than i18n)? They
don't all need to be in the draft but we should
consider 'em on the list I think.

- I don't think adding a bagful of hash functions is
useful, just adding sha256 would seem fine. Or I
could buy other options if there are real use
cases, but I bet there aren't. Question is: why
not just add sha256 and be done with it?

S.

On 05/29/2013 02:04 AM, Matthew Lepinski wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 May 2013 09:15:34 +0000

Hi Stephen.

Just one comment (with no hats)

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

We probably want to make only sha256 MTI, else we don't get interoperability. But what's the harm of adding a whole bagful?

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 29 May 2013 12:52:21 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Farrell
> Sent: Wednesday, May 29, 2013 4:37 AM
> To: Matthew Lepinski
> Cc: [email-masked]
> Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-
> auth-update
> 
> 
We have discussed this in the past. 
This document will not obsolete RFC2617, but will update it.
Even with the addition of the i18n text, I do not think that this draft will obsolete RFC2617.
Can you elaborate on what is it that you want to obsolete from RFC2617?

> consider 'em on the list I think.
I think that this is just a reminder of the text from RFC2617 section 3.1.4.
http://tools.ietf.org/html/rfc2617#section-3.1.4

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 29 May 2013 12:55:11 +0000

I agree with Yoav.

Regards,
 Rifaat

> Behalf Of Yoav Nir
> Sent: Wednesday, May 29, 2013 5:16 AM
> To: Stephen Farrell
> Cc: <[email-masked]>
> 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.
> 
> We probably want to make only sha256 MTI, else we don't get
> interoperability. But what's the harm of adding a whole bagful?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 May 2013 13:10:31 -0400

On Wed, May 29, 2013 at 5:15 AM, Yoav Nir <[email-masked]> wrote:

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

You don't get stronger security by adding support for stronger algorithms.

You get stronger security by REMOVING support for weak algorithms.

Hence a scheme with a mixed bag of weak and strong algorithms is no longer
considered best practice for crypto. Pick one algorithm that you think will
be secure and at most one backup. Make sure it is possible to add new
algorithms at a later date.

In this case the only problem with the construction is that it is
unfashionable to use MD5 and it is easier to change this spec than to
explain to people why MD5 is ok in this particular use. So moving from MD5
to SHA1 which has the same problem is not an improvement.

My vote would be SHA2-256 with SHA3-256 as a backup.

-- 
Website: http://hallambaker.com/

---

From: Manu Sporny <[email-masked]>
Date: Wed, 29 May 2013 20:56:32 -0400

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.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/