I share Larry's concern.
We agree with the IESG that this requirement should be "mandatory to
implement". What makes it untenable for us is the implication that an
implementation which does not enforce "mandatory to deploy" is non-compliant.
Server implementors are not in a position to enforce "mandatory to deploy",
and there are legitimate reasons why a site may choose to deploy unprotected
plaintext authentication.
Note the following text in RFC 2595:
[...] The PLAIN SASL mechanism
MUST NOT be advertised or used unless a strong encryption layer (such
as the provided by TLS) is active or backwards compatibility dictates
otherwise.
IESG approved this as standards-track for a new protocol (the PLAIN SASL
mechanism) which did not have any standards-track legacy to consider. IMAP,
on the other hand, has a standards-track legacy and furthermore a production
installed base dating from 1985.
This is, to put it mildly, inconsistent.
Is the following compromise be acceptable to the IESG?
Note: a server implementation MUST implement a configuration in which
it does NOT permit any plaintext password mechanisms unless the
STARTTLS command described in [IMAP-TLS] has been negotiated or
some other mechanism that protects the session from password
snooping has been provided. Server sites SHOULD NOT use any
configuration which permits a plaintext password mechanism without
a protection mechanism against password snooping. Client and
server implementations SHOULD implement additional SASL mechanisms
which do not use plaintext passwords, such the GSSAPI mechanism
described in [SASL] and/or the [DIGEST-MD5] mechanism.
This clearly puts the vendor off the hook if it has implemented the correct
mode, even if the site chooses to use the incorrect mode.
