RE: Further IESG feedback on draft-crispin-imapv-17.txt

[Mark Crispin <[e-mail]>]

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.