Subject: [http-auth] Digest Update - Algorithm Agility

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sat, 22 Jun 2013 17:46:09 +0000

I have just submitted a new version of this draft.
http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt

With this new version I fixed few nits and removed the i18n section; I have started working on a new separate draft to address the i18n.

Meanwhile, I would like to continue the Algorithm Agility discussion to try to come to an agreement on this issue.
The feedback I got so far seems to indicate that we want to limit the algorithm agility to few of the best current algorithms.
How about the following:
   SHA3-256 as the default algorithm.
   SHA2-256 as a backup algorithm.
   MD5 for backward compatibility.

Any thoughts?

Thanks,
 Rifaat

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 22 Jun 2013 23:04:05 +0300

Hi Rifaat,

I'm confused by your message. SHA3 is not even mentioned in the draft, 
and (AFAIK) is not fully standardized yet.

So it seems to me the default ought to be SHA2-256, with SHA3-256 coming 
in as the backup as soon as it is finalized.

Thanks,
	Yaron

On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 22 Jun 2013 20:53:31 +0000

Hi Yaron

Agree about SHA-2 being the default. At SAAG last meeting there was a speaker from NIST ( http://www.ietf.org/proceedings/86/slides/slides-86-saag-3.pdf ). The presentation doesn't say so, but he did say that the parameters for SHA-3 will be decided in the next few months. So SHA-3 may be finalized before this draft goes out.

Yoav

On Jun 22, 2013, at 11:04 PM, Yaron Sheffer <[email-masked]> wrote:

> Hi Rifaat,
> 
> I'm confused by your message. SHA3 is not even mentioned in the draft, and (AFAIK) is not fully standardized yet.
> 
> So it seems to me the default ought to be SHA2-256, with SHA3-256 coming in as the backup as soon as it is finalized.
> 
> Thanks,
> 	Yaron
> 
> Email secured by Check Point

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 23 Jun 2013 08:40:08 +0300

In addition to the algorithm question, there's the bigger question of 
the actual security (rather than "regulatory compliance") benefit that 
this buys us. If HTTP-Digest is used with short passwords over an 
unencrypted medium (or an encrypted one, where there may be a MITM 
attacker), then using SHA256 instead of MD5 has zero benefit. Dictionary 
attacks are much more effective than breaking MD5, and will remain so 
for the foreseeable future.

So the whole exercise only seems worthwhile when used with non-memorable 
"passwords", i.e. with actual crypto keys. Which really only makes sense 
within web services, rather than regular browsing. I suggest adding the 
following section to the draft:

--- start text ---

Applicability

HTTP Digest authentication, when used with human-memorable passwords, is 
vulnerable to dictionary attacks. Such attacks are much easier than 
cryptographic attacks on any widely used algorithm, including those that 
are no longer considered secure. In other words, algorithm agility does 
not make this usage any more secure.

As a result, Digest authentication SHOULD be used only with passwords 
that have a reasonable amount of entropy, e.g. 128-bit or more. Such 
passwords typically cannot be memorized by humans but can be used for 
automated web services.

--- end text ---

Yes, the text refers to RFC 2617 in the security considerations. But 14 
years later I believe we can do better than that.

Thanks,
	Yaron

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 23 Jun 2013 10:02:52 +0000

Hi Yaron,

You are right; I should have added SHA3 to the document before taken it into considerations. Will do that in the next version.

I am ok with changing the default to SHA2-256, as follows:

  SHA2-256 as the default algorithm.
  SHA3-256 as a backup algorithm.
  MD5 for backward compatibility.

We could revisit this decision if, as Yoav mentioned, SHA3 is finalized before this document is done.

Regards,
 Rifaat

> -----Original Message-----
> From: Yoav Nir [mailto:[email-masked]]
> Sent: Saturday, June 22, 2013 4:54 PM
> To: Yaron Sheffer
> Cc: Shekh-Yusef, Rifaat (Rifaat); [email-masked]
> Subject: Re: [http-auth] Digest Update - Algorithm Agility
> 
> Hi Yaron
> 
> Agree about SHA-2 being the default. At SAAG last meeting there was a
> speaker from NIST ( http://www.ietf.org/proceedings/86/slides/slides-86-
> saag-3.pdf ). The presentation doesn't say so, but he did say that the
> parameters for SHA-3 will be decided in the next few months. So SHA-3
> may be finalized before this draft goes out.
> 
> Yoav
> 
> 
> > So it seems to me the default ought to be SHA2-256, with SHA3-256
> coming in as the backup as soon as it is finalized.
> >
> > Thanks,
> > 	Yaron
> >
> >> With this new version I fixed few nits and removed the i18n section;
> I have started working on a new separate draft to address the i18n.
> >>
> >> Meanwhile, I would like to continue the Algorithm Agility discussion
> to try to come to an agreement on this issue.
> >> The feedback I got so far seems to indicate that we want to limit the
> algorithm agility to few of the best current algorithms.
> >> How about the following:

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 23 Jun 2013 10:05:11 +0000

Thanks Yaron,

I like the text you proposed below; I will add it to the limitations section.

Regards,
 Rifaat

> From: Yaron Sheffer [mailto:[email-masked]]
> Sent: Sunday, June 23, 2013 1:40 AM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: [email-masked]
> > With this new version I fixed few nits and removed the i18n section; I
> have started working on a new separate draft to address the i18n.
> >

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 23 Jun 2013 11:15:54 +0100

Seems like a fine direction. SHA3 defo ought not be the default
but is probably ok as a backup.

I'd add something along the lines that you really ought only send
these headers over HTTPS, properly validated. And that since that's
quite practical these days clients SHOULD require that (or stated
another way clients SHOULD NOT send these headers in clear) and
servers SHOULD log if they receive such headers in clear (but they
MUST NOT log the header values!!) and try to something about that
(go fix your own site's use of TLS).

It might also be worth putting the same piece of text into all the
drafts this wg produces where dictionary attacks are possible based
on the headers emitted. That'd maybe also mean a few editorial
changes. (No rush on that, probably better finalised when more than
one doc is ready for WGLC.)

As another point, it might also be worthwhile having a bit of
text for all drafts that are vulnerable to password verifier
database theft. IMO that really is the most important security
consideration for all these mechanisms (today at least). I don't
have time right now to draft that but will happily try later if
someone reminds me. (maybe plonk an issue in the tracker?)

Cheers,
S

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 23 Jun 2013 11:20:36 +0000

Thanks Stephen,

> (go fix your own site's use of TLS).

I will add some text along these line to the next version of the draft.

Regards,
 Rifaat

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Sunday, June 23, 2013 6:16 AM
> Cc: Yaron Sheffer; [email-masked]
> I

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 24 Jun 2013 10:55:28 +0300

Hi Stephen,

please see some comments below.

Thanks,
	Yaron

> but is probably ok as a backup.

+1, even after SHA3 is finally standardized. Because it'll be quite a 
few years before it is widely implemented.

> (go fix your own site's use of TLS).

I think you're going too far here. There's value in authenticating HTTP, 
even when traffic is unencrypted, and especially if Session Continuation 
happens. OTOH I don't think the industry is ready to mandate encryption 
at the SHOULD level.

> someone reminds me. (maybe plonk an issue in the tracker?)

I disagree about the relative important of these threats (passive/active 
attacks on traffic vs. off-line analysis of captured password 
databases), because we've seen to what lengths governments, enterprises 
and service providers are willing to go to MITM people's traffic. But I 
guess it's a pointless argument.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Jun 2013 08:33:27 +0000

Hi Yaron.

On Jun 24, 2013, at 10:55 AM, Yaron Sheffer <[email-masked]> wrote:

> +1, even after SHA3 is finally standardized. Because it'll be quite a few years before it is widely implemented.
> 
> I think you're going too far here. There's value in authenticating HTTP, even when traffic is unencrypted, and especially if Session Continuation happens. OTOH I don't think the industry is ready to mandate encryption at the SHOULD level.

I agree that the industry is not ready, but this option was discussed extensively at httpbis last July, and not only by security geeks:

http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0455.html  (OK, not the best example of non-security-geek)
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0464.html
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0548.html

> I disagree about the relative important of these threats (passive/active attacks on traffic vs. off-line analysis of captured password databases), because we've seen to what lengths governments, enterprises and service providers are willing to go to MITM people's traffic. But I guess it's a pointless argument.

>From what I've seen, they go to the provider. AFAIK breaking SSL on the national level is pretty rare. 

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 24 Jun 2013 11:43:19 +0300

Hi Yoav,

out of the three messages you link, I tend to agree with Carsten who 
says that a mechanism should not mandate a policy. In any case, a new 
version of HTTP-Auth is NOT the right place to say, thou SHALL encrypt 
everything.

Re: MITM, I did not mean specifically attacks on SSL. The Tunisian 
attack is an HTTP-level MITM for password recovery. The Iranian attack 
is an honest-to-God SSL MITM. Enterprise SSL proxies are an SSL MITM 
with (some, implicit) user consent. Traffic shaping being done every day 
by many providers *can* be considered a MITM attack, though some would 
disagree.

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Jun 2013 10:13:48 +0100

Hi Yoav, Yaron,

> http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0548.html

Its fair to say that my suggesting "SHOULD use TLS" is a bit
bogus in 2119 terms. I guess "MUST use TLS" would also work for
me and isn't bogus:-)

I do however think that we ought to put in the strongest possible
guidance we think is practical, because sending dictionary
attackable values over the Internet in clear really is dumb and
the world has moved on since 1999 when RFC 2617 was finished.

BTW, "MUST use TLS" is demonstrably doable. I just setup a free
(but real, i.e. verifiable in afaik all browsers) TLS server cert
on a box and that took all of 20 minutes, with a bit of messing
about setting up mail for the domain etc. so the 20 minutes of
PKI was spread over a couple of days. That particular CA service
does require you to control the domain, and that's not always
possible, e.g. I couldn't have done it for a machine within
tcd.ie, so for those I tend to use self-signed server certs
rather than deal with college admin folks:-) So stuff I setup
within tcd.ie does use TLS, but not entirely properly. And
that's why I ended up with the dodgy SHOULD statement.

How we wordsmith all that is a fine thing to discuss here,
but I'm sure we can come up with something that'll be good
enough.

>>From what I've seen, they go to the provider. AFAIK breaking SSL on the national level is pretty rare. 

Guidance here ought be aimed at implementers and those who
deploy authentication schemes that need password verifier
databases. (PVDB) We clearly can't say "don't do that" because
"doing that" is inherent in using these auth schemes, but we
really have to call out the problem and 2617 doesn't really do
that. (The closest it gets seems to be in 4.13 [1] which does
discuss the problem but doesn't really reflect what's been
happening with millions of PVDB entries leaking constantly
as has been happening for the last few years.)

Whether this is the most important thing or not is certainly
debatable, and probably not a debate that we can resolve, but
I hope we all do consider PVDB leaks a serious vulnerability
and can agree we at least have to recognise the vulnerability
where it exists and also the reality that this vulnerability
has been exploited at scale and repeatedly and that there is
a lot of code out there that helps one to exploit that
vulnerability when you get your hands on PVDB entries.

Cheers,
S.

[1] http://tools.ietf.org/html/rfc2617#section-4.13