re: New version of TLS + IMAP/POP/ACAP draft

On Mon, 23 Nov 1998, Mark Crispin wrote:
> OK, fair enough.  My proposed changes are very simple and small.

I see you want to make this spec an all out attack on clear text password
mechanisms in IMAP, POP and ACAP.  That's fine with me under the condition
that we do a complete job.  First, I think it's important to prevent
misleading security warnings:

 Clients and servers MAY generate a security warning whenever an
 unencrypted clear-text password mechanism is advertised or used.
 However, such warnings MUST be applied to all clear-text password
 mechanisms equally, including but not limited to the PLAIN mechanism, the
 IMAP4 LOGIN command and the POP3 PASS command.  This is important because
 it prevents users from being misled into a false sense of security if
 they disable one unencrypted clear-text mechanism, but leave another
 active.

Second, if we're really serious about making this spec promote the
elimination of clear-text passwords, it's about time we added a capability
to IMAP4 which advertises that the LOGIN command is disabled so that
clients don't try it unnecessarily (this doesn't eliminate the need for
clients to have a "don't use unencrypted clear-text passwords" option, but
it prevents useless transmission of the password by a client in
backwards-compatibility mode). ACAP doesn't have a LOGIN command, so it
doesn't need this, and POP3 gets this facility from the "CAPA" command
since the "USER"/"PASS" commands are optional in the base spec.  So I'll
add the "NOLOGIN" IMAP4 capability to the spec, which indicates either
the IMAP4 LOGIN command is completely unsupported, or it's only available
after STARTTLS.

Finally, flatly prohibiting a server from advertising PLAIN raises the
interesting security consideration of how to deal with an active attacker
adding "PLAIN" to the list of available mechanisms.  I'm thinking that a
client MUST either ignore any advertisement of the PLAIN mechanism when
no encryption layer is active, or if it is configured to generate a
security warning for advertisement of unencrypted clear-text mechanisms,
it will generate the same security warning for the presence of PLAIN that
it does for the absense of NOLOGIN in IMAP or the presence of USER in
POP3.

If you agree to these conditions, Mark, I'll go ahead an make the changes
you want.  If you'd prefer the wording in the current spec, that's fine
with me as well.

> The key word is "contemporary".  Note, however, that "support CRAM-MD5" does
> not necessarily mean that CRAM-MD5 is desirable, due to the requirement to
> store (the equivalent of) plaintext passwords on the server.

Dicussing the merits of CRAM-MD5 is out-of-scope for this discussion --
although I agree there are deployment issues and concerns with using the
class of mechanisms incluing CRAM-MD5, CHAP, HTTP Digest, APOP, etc.  The
key point is that those software developers who can't implement & release 
TLS for some reason _can_ implement & release CRAM-MD5 or related
mechanisms, and that's exactly what's happening in practice.  Thus a
server which offers both CRAM-MD5 and clear-text under TLS interoperates
well with recent software releases.  So having the ability to turn off
all clear-text mechanisms is useful at sites running only recent releases
of mail clients and will only become more useful in time.

> If by "option" you mean "the ability to disable all plaintext authentication",
> I already have that in my server.  It's a simple build option.

Precisely the option I wish to promote in both clients and servers.  I see
no problem with it being a build option for an open-source server.

I'm going to avoid responding to some of your comments publicly as I
don't think it would be beneficial to the technical debate.

> I'm not convinced that STARTTLS is a good idea compared to
> imaps/pop3s/etc. but now that I have imaps/pop3s/etc. it wouldn't be too
> hard to add STARTTLS.

That's interesting, Mark.  I'd like to hear your concerns.

		- Chris