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

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

I'll put that text in the security considerations section of this
specification.  User interface for security services has a grave impact on
the security of the protocol, so not only is there no problem having it in
a protocol specification, but there's quite a bit of precedent for this in
the IETF.  If anything, we should be doing more of this given the problems
one has distinguishing between export-crippled crypto and real crypto. 
I've explained 40-bit crypto to laymen and they were shocked to find out
their browser wasn't secure when it claimed to be. 

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

All excellent points.  I'll write the text accordingly.

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

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.

Some thought should probably be put into STARTTLS-style support in an
stunnel-like model.

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

Netscape 4.5 uses STARTTLS for smtp, but the problems with the "smtps"
port (now de-registered) are a bit more serious than those with respect to
imaps/pop3s.

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

The main point is that there are three useful modes for TLS:
* Never use it
* Always use it
* Use it when available

The third mode is the correct default, IMHO, as it interoperates with the
installed base, but gracefully upgrades security.  Furthermore, the third
mode is the natural mode for STARTTLS.

There's also the issue with URL schemes.  If I have a server which
supports TLS and non-TLS, but I'd prefer people use TLS, the
"http"/"https" model doesn't allow that to be expressed.  In fact,
real-world usage of "https" has intruded heavily into the user interface
forcing users to make security decisions they shouldn't have to make.

		- Chris