Re: [http-auth] Why update Digest Auth?

[Stephen Farrell <[e-mail]>]

Hiya,

On 07/20/2013 05:33 PM, Yaron Sheffer wrote:
> Sorry for questioning the group's charter, but this keeps bugging me:

I'd rather we do stuff as promised personally and not re-open
the charter. In saying that, I am assuming we finish what we
promised promptly (i.e. within months, not years).

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

Fair point about vendors and their customers. OTOH, RFC 1149 has
also reportedly been requested of vendors, so customer RFQ silliness
isn't really a good metric for what an IETF WG ought do.

> Almost nobody will implement the other drafts.

That's a nicely confident prediction. Care to bet a beer? (If so,
quantify it fairly somehow and I'll take that bet.)

I hope you're wrong, at least wrt HOBA, but in any case, we ought
not base any decisions on you prediction above, or any equivalent
prediction.

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

Not to me. You can already and should already run over TLS, at which
point any advantage of ZKPP gets lost in the noise since phishing and
password verifier DB leakage are entirely unaffected by the elegant
ZKPP bit fiddling. (That is a shame, since the crypto really is quite
elegant, but its nonetheless true.)

So I'm still of the opinion that minimal modernising of the existing
schemes plus some experiments is right here and we should not
pointlessly anoint any of the experiments with standards-track
status until after we've seen that they are useful in reality.

Having said that, if we decided to abandon work on Digest I'd not
object.

S.

> 
> Thanks,
>     Yaron
> _______________________________________________
> http-auth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>