re: Revised TLS + IMAP/POP/ACAP draft-06 (fwd)

For some reason, Bill Yeager's postings aren't making it to the IMAP list.
I'm therefore posting it for him:

-- Mark --

* RCW 19.149 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

---------- Forwarded message ----------
Date: Wed, 23 Dec 1998 09:22:35 -0800 (PST)
From: Bill Yeager <[email protected]>
To: Chris Newman <[email protected]>
Cc: IMAP Discusson List <[email protected]>, [email protected]
Subject: re: Revised TLS + IMAP/POP/ACAP draft-06

| (3) The text in the second paragraph of 2.3 is completely unacceptable:
|           Furthermore, a server which implements both STARTTLS and a
|           clear-text password mechanism which is not documented in a
|           standards track RFC MUST NOT permit use of that mechanism
|           unless suitable TLS encryption is active.

Hi Chris,

I have excised the above from Mark's message, and I find myself in complete
technical agreement with Mark on the above text. It has several weakness, and
is politically harmful to the IMAP effort, the IETF itself, and renders this
draft, as written, unimplementable by a large body of (perhaps the majority
of) the IMAP community.

Why? It does not consider legacy. As Mark points out, without exageration, we
know there are millions of clients and servers out there that are c-client
based, and probably others that are not, that use clear-text password
mechanisms that are not documented  in a standards track RFC. These are as
harmless as any such documented mechanism. 

You do understand the cost of upgrading clients and servers in both time and
$$$. And, thus, as Mark said, we must always provide a migration path that is
sensible, has minimal cost, and considers the large, installed user base.

If I were to implement STARTTLS, I would simply ignore (3) above until all
clients that the server implementation support no longer used, for example,
AUTH=LOGIN. Doing so causes no harm, and gives the users all of the benefits
of the added security you propose, a sound migration path, and minizes the
incredible cost of user support that both Universities and companies MUST pay
to stay in business. 

I do believe your draft MUST address the above issues in a reasoned manner.
And, the above paragraph MUST at least be changed as follows:

|           Furthermore, a server which implements both STARTTLS and a
|           clear-text password mechanism which is not documented in a
|(*)        standards track RFC SHOULD NOT permit use of that mechanism
|           unless suitable TLS encryption is active.

Thanks for your attention to this matter,

Bill