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

I don't have time to review Mark's comments in detail at the moment as I'm
about to go on vacation.  I'd be interested in hearing from anyone who
thinks any of the proposed changes merit another document revision.  Some
of them seemed quite reasonable, but may not be worth holding up the
document given there has been ample time to comment previously.

I'll comment on one point:

On Fri, 18 Dec 1998, Mark Crispin wrote:
> (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.
> 
> This text has the following consequences:
>  (a) PLAIN is permitted without TLS encryption the instant PLAIN becomes
>      standards-track, in direct contradiction of sections 6 and 9.

It doesn't contradict the rules for PLAIN.  The document is quite clear
that PLAIN has the same restricitons that this places on non-standards
track mechanims.  I would not oppose a clarification to this effect, but I
don't think such a clarification is necessary.  The document states A
implies B, but does not state that !A implies !B (and in this case, the
latter is false).

>  (b) it declares my server broken (and is a blatant attack on my server)

Mark insisted I close all gaps in the spec allowing insecure unencrypted
plaintext password mechanisms.  And I have done so.  Now Mark seems to be
asking me to leave an exception for one server's non-standard behavior.
The answer is no, I will not weaken the rules to leave an opening for an
undocumented channel leaking unencrypted passwords.

>  (c) it defines non-standard behavior?!?  This itself is self-contradictory.

No, it places a restriction on servers implementing STARTTLS which makes
them more secure and makes them better follow the IESG/IAB security
guidelines.

		- Chris

P.S. I will not publicly respond to comments speculating on the
motivations for my behavior, as such comments and responses can't happen
in a technical forum where proper decorum is followed.