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

On Thu, 26 Nov 1998, Chris Newman wrote:
> 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.

This is not the issue.  The issue is a server that advertises PLAIN
without TLS in effect, and a client that fails to check for TLS in effect
prior to using PLAIN.

In other words, this is the situation of an evil server and a naive
client.  You are attempting to forbid a non-naive client to issue any sort
of warning about an evil server, without crippling the client so that it
can not ever use insecure authentication.  The implication is that nobody
will ever write a naive client, and that therefore it's unnecessary to
provide security administrators with any sort of warning about evil
servers since evil servers can't cause harm.

I don't accept either implication.

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

This is still irrelevant.  There is no chance of a client ever being
tricked into using LOGIN or PASS, whereas that is a very real concern with
a SASL authenticator, particularly a standards-track SASL authenticator.

This new wording is still objectionable bullshit.  You are making
unacceptable demands of a client implementor that have nothing to do with
the protocol, and the only apparent reason for these demands is to make it
unfeasible to issue any sort of warning.  If you would change the "MUST"
to a "SHOULD" then it just becomes bullshit; since an implementor can
ignore it, it's no long objectionable.

Like it or not, people are going to assume that SASL is safe, just as they
assume that LOGIN/PASS are unsafe.  The standards-track form of SASL must
be safe.  What's done in non-standard SASL is irrelevent.