[standards-jig] Re: [Foundation] Last Minute JEP 78 Concerns
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