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

On Fri, 20 Nov 1998, Mark Crispin wrote:
> Chris, I have already told you that I do not consider the current wording to
> be acceptable.  You are, in effect, adding another clear-text password
> mechanism to be transmitted unencrypted over the network.

While I recall your attitudes on the topic, I don't recall you specificly
objecting to the text in the draft.  Please suggest specific replacement
text so we may debate the relative merits.  The current text on this issue
is in section 6:
----
     This defines the "PLAIN" SASL mechanism for use with ACAP and other
     protocols with no clear-text login command.  This MUST NOT be
     implemented unless strong TLS encryption or an equivalent strong
     encryption layer is also implemented.
----
and section 9:
----
     Use of clear-text login mechanisms (e.g., the IMAP4 LOGIN command,
     POP3 PASS command or the PLAIN mechanism) without a suitable
     encryption layer such as that provided by TLS expose the user's
     password to a common network eavesdropping attack.  Therefore, the
     PLAIN mechanism MUST NOT be implemented unless a suitable
     encryption layer, such as that provided by TLS is also implemented.
----

If there is rough concensus for your alternative text, we can move forward
with that.  If you fail to suggest alternative text, I'll assume the
current text is adequate and go forward with asking for a last call.

> By your own admission, your "clear-text password requirement" is worthless.
> You have admitted that a POP3 server which does not have PASS, or an IMAP
> server which does not have LOGIN, will not function well in the overwhelming
> majority of contemporary installations.

I strongly disagree.  It won't be long before all IMAP clients under
active development will support either CRAM-MD5 or TLS.  At that point,
this will be a very important option.  Futhermore, it is currently the
correct option, IMHO, for connections from outside the local network and
is the option I use for such connections when I travel.

> That is not an excuse for allowing PLAIN in a non-TLS session.  The
> requirement already exists for doing a new CAPABILITY command after STARTTLS.
> Why, then, do you feel compelled to allow PLAIN in a non-TLS session?

Personally, I'd like to get rid of all unencrypted clear-text mechanisms
(particuarly the undocumented ones).  But when writing a spec my
preference is to match the spec as closely to real-world deployed code as
possible while making the security considerations clear.  Now if you push
on this issue and we get rough concensus, I'm sure we can make the
restrictions sufficiently strict that they no longer match reality.  Such
compromises are sometimes necessary in a standards body, so I can live
with that.

While we're on the subject, why does your code permit the undocumented
LOGIN mechanism when TLS isn't active?

> Furthermore, as I also discussed with you, the syntax of the data transmitted
> in PLAIN is quite poorly designed.  PLAIN has the concept of a separate
> authorization and authentication identity.  In actuality, the authorization
> identity is optional and gets defaulted from the authentication id.  Instead
> of this optional field coming after the mandatory fields (opening the
> possibility that it not be sent at all), it is the first field.

There's too much interoperable deployed code from multiple vendors to
change the syntax, nor do I 100% agree with your analysis.  I'd generally
rather have a mandatory & empty field than an optional field in a
protocol.  It is not uncommon to implement against a test server/client
while ignoring the spec, and such implementations have a tendancy to
totally forget optional protocol elements and cause interoperability
problems down the road.

> Without a
> careful reading, a programmer is misled to believe that the arguments to PLAIN
> are
> 	username NUL password
> or	username NUL NUL password
> instead of what PLAIN actually wants, which is
> 	NUL username NUL password

Actually a programmer just has to read the third paragraph of
section 6, glance at the first line of the formal syntax or read the
example to get this right.

However, you're welcome to suggest specific wording clarifications.

		- Chris