[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns

Matt Tucker matt at jivesoftware.com
Tue May 27 20:53:16 UTC 2003


> Again, this is a server mis-configuration problem -- not protocol. 
> However, this scenario has always been possible. It's completely 
> possible that I can configure my system to ONLY support Zero-K (for 
> old-times sake) authentication. If I try and use a client that doesn't 
> support that mechanism, it's expected that auth will fail. This is 
> correct behaviour.

Yes, this is true, you could configure the server to only support 
edigest and not digest and all would work (even though old client 
couldn't connect). But, let's now step back for a second and make some 
real-world considerations. Any new protocol we add has to be 
*substantially* better than what we had previously since we're doing 
protocol upgrade work and not something fresh.

Let's think about this from the perspective of a server implementor: no 
old clients will understand edigest and there is a huge installed base. 
edigest doesn't actually give me any extra security, just some 
obscurity. Therefore, if i care about security I'll forget about edigest 
and implement SSL or password encryption in the database instead.

 From the client side perspective -- I have to support digest since that 
is what everyone is already using. edigest is new and hardly provides 
any advantages over digest. Most servers won't support it for a long 
time, if ever, since supporting it will break digest and plain text 
modes. Therefore, I'll simply ignore edigest support and concentrate on 
ssl or SASL.

So, we could make edigest, and it *might* be a tiny bit better, but what 
would be the point?

Tijl -- your ideas on making a better digest mode are good. But again, 
shouldn't we just leave digest as it is, let servers secure it on their 
end, and focus on SASL?


More information about the Standards mailing list