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

On Wed, 25 Nov 1998 10:08:11 -0800 (PST), Chris Newman wrote:
> On Tue, 24 Nov 1998, Mark Crispin wrote:
> > On Tue, 24 Nov 1998 12:02:35 -0800 (PST), Chris Newman wrote:
> > >  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 a user interface, not a protocol, issue.
> I'll put that text in the security considerations section of this
> specification.

I was going to offer Chris a face-saving way out of this without airing dirty
laundry, but he's forced my hand.  He's wasted entirely too much of my time in
the past few months with this stupid issue.

The sole reason for this text is an attack on c-client.  An SSL-enabled Pine
will report a security warning if the server offers PLAIN in an unencrypted
session.  Chris' employer's server is one such server; the only one I've seen.

IESG is very specific about not allowing the addition of any new plaintext
authentication mechanisms.  Chris' use of the word "implemented" is an attempt
to cause the draft to be misread so as to sneak it past IESG; I have a message
from Chris which admits as much.

Chris is quite annoyed that I've made this misleading wording public and
spoiled it.  The proposed addition of this paragraph is to cause a nuisance
for me in return.

If that wording is in place, I'm left with the following choices:
 1) either not warn users about a possibly evil man-in-middle server (see
    Randall Winchester's comment about servers which respond NO to STARTTLS)
 2) cripple Pine so that it is useless in those cases where the LOGIN command
    must be used.

There is a difference between the LOGIN command -- which all parties know is
insecure -- and the PLAIN mechanism, which is supposedly secure since it
happens only under STARTTLS.

It would be acceptable to me just to punt on the PLAIN mechanism, and simply
say "use LOGIN".  It makes the security implications much easier.  I think
that it could be possible to prevail upon IESG to allow a LOGIN command in
ACAP that is valid only under a TLS regime.

> That's part of why I was convinced not to fully deprecate the use of
> imaps/pop3s -- they'll just remain non-IETF-standard usage.

Who gave Chris the authority to make such a decision?

imaps/pop3s are operational mechanisms today, supported by at least three of
the big players in the IMAP world: Netscape Messager, Microsoft Outlook, and
SSL-enabled Pine.  There are reasons to consider imaps/pop3s to be technically
superior to STARTTLS.

Something is badly wrong if Chris has the authority to declare something used
by thousands, if not tens of thousands, of users as "non-standard".