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

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

Good point.  I missed the case where the client has apriori knowledge that
the server is supposed to be configured to not advertise a given
clear-text mechanism.  Here's a second try at the wording:

  Clients and servers MAY generate a security warning whenever an
  unencrypted clear-text password mechanism is advertised or used.
  However, if such warnings are implemented they MUST be available for all
  clear-text password mechanisms, 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.

Does that address the technical concerns with my first wording attempt?
Or is there a counter-proposal?


As for the political concerns that were raised, this is obviously an issue
involving strong feelings.  Rather than debate it further, I'm inclined to
add a non-normative appendix putting all cards on the table, and let the
IESG decide if the Appendix is appropriate:

Appendix: PLAIN Mechanism and Security Analysis of Deployed Sites

  RFC 2316 states that "no protocol that relies on passwords sent over
  unencrypted channels is acceptable."  Implementations of the PLAIN
  mechanism which don't require use of encryption have been released by
  multiple vendors and some vendors have even released support for an
  undocumented mechanism which sends passwords over unencrypted channels.
  Such use of the PLAIN mechanism is incompliant with this specification,
  but should be considered when doing a security analysis of an installed
  site or when interpreting security warnings.

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

I'd  prefer not to add an extra authentication path to ACAP (and SMTP)
as it simplifies security analysis and reduces protocol-specific security 
code.  The IMAP4 LOGIN command doesn't provide the proxy-authentication
facility (for server->server authentication) that PLAIN includes.

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

I obviously don't have any authority beyond my input to IETF rough
concensus.  I was just stating what convinced me personally.

The fact that imaps & pop3s will remain non-IETF-standard usage is also
not my decision, but rather the decision of IETF rough concensus and the
IESG.  My interpretation of the rough concensus is that the IETF won't
standardize such usage but will standardize STARTTLS.  This has happened
for SMTP.

		- Chris