re: Revised TLS + IMAP/POP/ACAP draft-06

This latest draft document still has major problems.

(1) The entire Motivation section is unnecessary; it handwaves in parts, and
goes into opinion elsewhere.  This is a minor problem, compared to the other
problems.

(2) The text "Updates: RFC 2060" has the effect of requiring that this
document be incorporated into subsequent portions of the base specification.
Unless the IMAP working group is reconstituted (and we want to reset the
standards clock on IMAP), it is inappropriate to do this.

(3) The text in the second paragraph of 2.3 is completely unacceptable:
          Furthermore, a server which implements both STARTTLS and a
          clear-text password mechanism which is not documented in a
          standards track RFC MUST NOT permit use of that mechanism
          unless suitable TLS encryption is active.

This text has the following consequences:
 (a) PLAIN is permitted without TLS encryption the instant PLAIN becomes
     standards-track, in direct contradiction of sections 6 and 9.
 (b) it declares my server broken (and is a blatant attack on my server)
 (c) it defines non-standard behavior?!?  This itself is self-contradictory.

The second paragraph of 2.3 must be deleted.

If Chris Newman refuses to stop these attacks, someone else should take over
the document.  I am sick and tired of Chris' repeated efforts at revenge.  A
standards-track specification has to follow IESG rules.  I'm sorry that Chris'
implementation has run afoul of these rules, but the fact that I pointed it
out does not justify Chris taking it out on my implemntation.

If I tried to standardize the LOGIN mechanism (which, by the way, is over
three years old now and is widely distributed), I would have had the same
problems as Chris is now facing.  But I didn't.  Chris wants PLAIN (which is
much newer) standardized, and if that is going to happen then PLAIN must
follow the rules.

(4) The text in section 2.4 needs to clarify if CNAME canonicalization is
done.

(5) The text in 3.2 should clarify that LOGIN will always return NO (not BAD)
if LOGIN is disabled.  Otherwise, it changes the base specification.

(6) The text in section 6 reads:
          [...] The PLAIN
          SASL mechanism MUST NOT be used unless strong TLS encryption or
          an equivalent strong encryption layer is also in use. In
          particular, if a strong encryption layer is not currently in
          use in the session, a client MUST NOT attempt to authenticate
          via the PLAIN SASL mechanism.

Chris Newman states:
> * I didn't add Mark Crispin's specific language forbidding server
>   advertisement about PLAIN.  The generic requirement that PLAIN can't be
>   used unless encryption is active makes it quite clear now that servers
>   are forbidden from advertising PLAIN if encryption is not active. I don't
>   want to confuse implementors into the mistaken impression that server
>   advertisement of PLAIN has a significant impact on protocol security
>   when it's the client's responsibility to determine when PLAIN is
>   acceptable.

I find this unconvincing.  The same thing can be said about the statement
relating to client behavior ["...a client MUST NOT attempt to authenticate via
the PLAIN SASL mechanism"].  The text needs to be complete and explicit about
both ends:
          [...] The PLAIN
          SASL mechanism MUST NOT be used unless strong TLS encryption or
          an equivalent strong encryption layer is also in use. In
          particular, if a strong encryption layer is not currently in
          use in the session, a client MUST NOT attempt to authenticate
          via the PLAIN SASL mechanism, and a server MUST NOT advertise
          the PLAIN SASL mechanism nor accept an attempt to authenticate
          via the PLAIN SASL mechanism.

Otherwise, PLAIN should not become standards-track.

(7) The text:
          Non-US-ASCII characters are permitted as long as they are
          represented in UTF-8 [UTF-8]. Use of non-visible characters or
          characters which a user may be unable to enter on some
          keyboards is discouraged.
needs to be clarified that it refers to the authorization and authentication
identities and not the password (which is binary).

(8) The example:

          Here is an example session where a client erroneously attempts
          to use PLAIN prior to starting TLS:

     Example:    S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS)
                 C: a001 AUTHENTICATE "PLAIN" {21}
                 S: a001 NO (ENCRYPT-NEEDED)
                    "Can't use PLAIN without encryption"

is exactly the sort of scenario which should be avoided.  Note that in the
previous example, a non-synchronizing literal was used.  Here, there is a
synchronizing literal.  Using a non-synchronizing literal, we have:

          Here is an example session where a client erroneously attempts
          to use PLAIN prior to starting TLS:

     Example:    S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS)
                 C: a001 AUTHENTICATE "PLAIN" {21+}
                 C: <NUL>tim<NUL>tanstaaftanstaaf
                 S: a001 NO (ENCRYPT-NEEDED)
                    "Can't use PLAIN without encryption"

This is not something that should ever happen.  Yes, it's a broken client.
But it's also a server whose behavior triggers the broken client.  There is no
reason for the server *ever* to advertise PLAIN outside of TLS.

(9) The text in section 7 is unconvincing, and probably has the opposite
effect from what is intended; the reader is left with the opinion that this
whole STARTTLS stuff is nonsense and he should just use imaps and pop3s.

Section 7 needs to be rewritten so that the arguments for STARTTLS are more
than handwaves.  I don't particularly want to do it (because I think that
separate ports are the better solution, that's why), but I'm willing to
swallow my personal opinions and do it if nobody else steps up.  I still won't
agree with the argument, but at least I'd make it convincing.

(10) In the text:
          A man-in-the-middle attacker can always cause a
          down-negotiation to the weakest authentication mechanism or
          cipher suite available. For this reason, implementations need
          to be configurable to refuse weak mechanisms or cipher suites.
replace "need to" with "SHOULD".

(11) In the text:
          Any protocol interactions prior to the TLS handshake are
          performed in the clear and can be modified by a
          man-in-the-middle attacker. For this reason, clients SHOULD
          discard cached information about server capabilities advertised
          prior to the start of the TLS handshake.
Perhaps the "SHOULD" should be a "MUST" instead?  Are there any clients which
do not do this?

(12) In the text:
          When the PLAIN mechanism (or the IMAP LOGIN or POP3 PASS
          command) is used, the server gains the ability to impersonate
          the user to all services with the same password regardless of
          any encryption provided by TLS or other network privacy
          mechanisms. Stronger SASL authentication mechanisms such as
          Kerberos address this issue.
replace "the PLAIN mechanism (or the IMAP LOGIN or POP3 PASS command)" with
"any form of authentication that makes a plaintext password (or equivalent)
known to the server".

The PLAIN mechanism, IMAP LOGIN command, and POP3 PASS command are not a
comprehensive list, even if you limit things to the three protocols discussed
in this document.  Besides the LOGIN mechanism, the PASSDSS mechanism, the
POP3 APOP command, and arguably CRAM-MD5 also has the same attribute.

Any attempt to have a closed list of such forms of authentication entails the
risk of document obsolescence, not to mention resuming sniping about the LOGIN
mechanism.  Let's not go down that path.  Instead, use the category of these
forms of authentication.

(13) The text:
          Use of clear-text login mechanisms (e.g., the IMAP LOGIN
          command, POP3 PASS command or the PLAIN mechanism) without a
          suitable encryption layer, such as that provided by TLS, expose
          the user's password to a common network eavesdropping attack.
          Therefore, the PLAIN mechanism MUST NOT be used unless a
          suitable encryption
          layer, such as that provided by TLS, is in use. In addition,
          this is the primary motivation for the clear-text password
          requirements in section 2.3.
Replace "expose" to "exposes".  Also, the last sentence is unnecessary and
should be deleted.

(14) Appendix A would be tolerable, if it weren't for the second paragraph of
2.3.  Also, the comment "This author believes it is preferable to abuse the
PLAIN mechanism rather than using an undocumented channel for unencrypted
passwords." has to be excised; it implies acceptability of non-compliant use
of a standards-track mechanism.  In any case, the LOGIN mechanism is much more
widely implemented and distributed than PLAIN.

In the spirit of compromise, I propose the following rewrite of Appendix A, to
go along with deletion of the second paragraph of 2.3.  This, by the way, will
be the first mention of the LOGIN mechanism in any document.  But I'm willing
to give Chris this much if he will stop revenge-attacking my server.

   A Appendix -- Non-Compliant Use of PLAIN and the LOGIN mechanism.
          RFC 2316 states that "no protocol that relies on passwords sent
          over unencrypted channels is acceptable."

          Multiple vendors have released implementations using the PLAIN
          mechanism without requiring the use of encryption, and/or an
          undocumented LOGIN mechanism (which uses clear-text passwords).

          Use of the PLAIN mechanism without requiring the use of encryption
          is not compliant with this specification.  This MUST NOT be done
          in new client or server implementations.  Existing implementations
          MUST be updated as soon as possible, and no later than xxxxxx.

          The LOGIN mechanism MUST NOT be implemented in new client or server
          implementations, and SHOULD be deprecated in existing
          implementations.  For the purposes of the security requirements of
          this document, the LOGIN mechanism is equivalent to the IMAP LOGIN
          and POP3 PASS commands, and all requirements of these commands also
          apply to the LOGIN mechanism.

          Since there will necessarily be a transition period before
          the LOGIN mechanism and non-compliant use of PLAIN are eliminated,
          this should be considered when performing a security analysis of
          a site or interpreting security warnings.

In any case, PLAIN purports to become standards-track and LOGIN does not, and
therefore PLAIN has to be held to a higher standard.

(15) The issue of a client "don't use clear-text passwords" configuration
option needs to be explored further.

There are two reasons why the user might set this:
 a) Don't want passwords transmitted in the clear.  Disable IMAP LOGIN
    command, POP3 PASS command, and LOGIN mechanism.  PLAIN is always disabled
    in the clear in compliant implementations.
 b) Don't want server to know password.  Disable IMAP LOGIN command; POP3 PASS
    and APOP commands; LOGIN, PLAIN, PASSDSS, CRAM-MD5(?) mechanisms.

There are multiple ways of doing this in the client.  For example, a client
could have an option that says "don't transmit passwords in clear-text", which
is ignored if TLS is in effect.  Another client could have separate "require
TLS" and "don't transmit passwords" options.  These should be recognized as
being equally valid, without implying that one is valid and the other isn't.