[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
ian.paterson at clientside.co.uk
Wed Sep 12 12:53:37 UTC 2007
Peter Saint-Andre wrote:
> Ian Paterson wrote:
>> In real life servers will always be compromised (especially in cases
>> where the attacker is the service provider). So SASL PLAIN still
>> contains a serious vulnerability that is easily fixed in those cases
>> where DIGEST-MD5 is a practical option.
> Except that DIGEST-MD5 is effectively being deprecated by the IETF. Thus
> the interest in SCRAM, YAP, and their ilk.
With all due respect to the experts at the IETF, I feel (as a
non-expert) that they are trying to depricate DIGEST-MD5 before it has a
suitable replacement (i.e. another one that protects users' passwords
from a compromised server). I strongly agree we should recommend/require
SCRAM and/or YAP as soon as they are baked. But is that likely to happen
before 3920bis is puiblished?
I agree that if we start recommending SASL PLAIN in addition to
DIGEST-MD5 now, *and if we continue to do so in the future*, then we can
ensure that current implementations will still be compatible with future
implementations that have removed support for DIGEST-MD5.
However I don't understand why we are considering recommending weakening
the security of XMPP servers in the short and medium term by not
requiring any of DIGEST-MD5 or SCRAM or YAP. Are XMPP implementors
experiencing interoperability issues with DIGEST-MD5? If so can't we fix
them with a Best Practices XEP - as we did with SASL ANONYMOUS and SASL
EXTERNAL? Which of the 7 problems with DIGEST-MD5 mentioned in  make
DIGEST-MD5 less secure for XMPP authentication than SASL PLAIN?
More information about the Standards