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 [1] make
DIGEST-MD5 less secure for XMPP authentication than SASL PLAIN?
- Ian
[1]
http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt
