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

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 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.

This is a user interface, not a protocol, issue.  As such it is inappropriate
for a protocol specification such as the TLS + IMAP/POP/ACAP draft.

It may be an appropriate statement for some other document, such as a
"security requirements" document.

> 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

Agreed.

> 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.

I agree with the intent, but this needs rephrasing.  Here are my issues:
 1) I think that "LOGINDISABLED" is better than "NOLOGIN", particularly since
    we are introducing a surprising behavior for a guy who just read RFC 2060.
 2) I object to "completely unsupported"; the base spec makes no allowance for
    LOGIN to be unsupported.  I prefer "disabled".  For the same reason, the
    error for an attempted LOGIN should be NO, not BAD.
 3) I object to "only available after STARTTLS" since that precludes some
    other means by which it might be available.

Here's how I think we should deal with (3).  We should amplify the text in
STARTTLS:
      Once TLS has been started, the client SHOULD discard cached
      information about server capabilities and re-issue the CAPABILITY
      command.  This is necessary to protect against man-in-the-middle
      attacks which alter the capabilities list prior to STARTTLS.  The
      server MAY advertise different capabilities after STARTTLS.
to indicate that the capabilities returned after STARTTLS *override* what was
returned prior to STARTTLS.  As an explict example, state that LOGINDISABLED
may disappear from the capability list after STARTTLS, thus indicating that
LOGIN can be done under TLS.

> 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.

That's the purpose of my text that flatly prohibits a client from attempting
to negotiate PLAIN unless an encryption layer is in use.

> 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.

Once again, this is a user interface issue which is inappropriate for this
document.

> > 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.

Basically, there's a lot of imaps/pop3s software already deployed.  More
importantly, stunnel (available from Poland) plus ssleay (available from
Australia) makes it possible to make existing worldwide public server software
play the imaps/pop3s game without running afoul of the reprehensible US
government regulations.

Any server implementation with STARTTLS or internal imaps/pop3s support is
classified as a munition under US law.  This means that US based free software
implementors can not distribute it.

With a great deal of work, I have created a mechanism under which I can
distribute a completely sanitized IMAP toolkit, yet by applying the "SSL IMAP
Toolkit" it becomes completely imaps/pop3s/nntps/smtps-capable.  STARTTLS is
easy enough to implement, but the mechanism to apply it to sanitized code
requires a bit of thought to get right.

I don't see much point in bothering with implementing STARTTLS until clients
start using it.  The popular ones all use simap, and arguably using simap
saves a few RTTs.

I'm not even sure that I understand the point of STARTTLS, unless it's just to
reduce the number of ports assigned.