[http-auth] Why update Digest Auth?

[Yaron Sheffer <[e-mail]>]

Sorry for questioning the group's charter, but this keeps bugging me:

I'm assuming this WG will publish two Standards Track RFCs, updating 
Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of 
lovely state-of-the-art crypto.

Enterprises will require vendors to implement the updated Basic and 
Digest, and in a few years' time we will end up with the worlds' 
browsers and Web servers supporting Basic and Digest Auth with I18N and 
(for Digest) crypto agility. Almost nobody will implement the other drafts.

In addition, the websec WG will hopefully work on "session 
continuation", which will extend the authentication to the whole session 
in a better way than cookies, and will provide channel binding. Assuming 
much of the Internet's traffic will remain unencrypted for years, this 
will be "good enough" security for this traffic. But, it won't work with 
Digest (because it is not "key generating", to borrow an EAP term).

Now my question: we are telling implementors to upgrade Digest to gain 
I18N (and the algorithm agility, which in this case is mostly security 
theater, because when using short passwords we remain vulnerable to a 
dictionary attack anyway). Why not tell them *instead* to move to 
Digest-v2, which is dictionary attack resistant? Digest-v2 could be 
based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will 
support session continuation.

Seems to me this would be a much better use of our time, as well as 
implementors' energy.

Thanks,
     Yaron