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

On Sun, 20 Dec 1998 00:31:35 -0800 (PST), Chris Newman wrote:
> Mark insisted I close all gaps in the spec allowing insecure unencrypted
> plaintext password mechanisms.

No, Mark insisted that you follow the rules established by IESG.  No more, no
less.

>  And I have done so.  Now Mark seems to be
> asking me to leave an exception for one server's non-standard behavior.

It is impossible for a standard to define the behavior of an additional
facility which is non-standard.  It is absolutely reprehensible to do this ex
post facto, but that is exactly what Chris Newman is attempting to do.

> The answer is no, I will not weaken the rules to leave an opening for an
> undocumented channel leaking unencrypted passwords.

Chris is presuming to do something that he does not have the power to do; to
decide that a server can not implement a standards-track facility if it also
has an different, independent, non-standard facility.

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

There is no IESG directive stating that Internet protocols govern non-standard
and undocumented extensions, and especially that state that an implementation
may not implement a standard command if it has a particular non-standard and
undocumented extension.

Furthermore, you claim of "more secure" is a lie, because your latest draft's
Appendix A specifically blesses the use of PLAIN outside of encryption.  PLAIN
is "more secure" the way that Clinton "did not have sexual relations" with
Monica.

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

You can not hide behind the veil of decorum when you play revenge games.

It is necessary to call your credibility into question when your motives are
ones of petty revenge and not technical.  You made it quite clear in email
that this was to be your revenge for my "ruining" your opportunity to have a
standard way of doing unencrypted plaintext authentications in ACAP.

You are doing you damnedest to protect your implementation -- which will
definitely be in violation of IESG directives if PLAIN becomes standards
track.  That is alright, but not through attacking another person's
implementation that does not violate IESG directives at all.

I have no particular interest in breaking your implementation -- it is merely
the inevitable consequence of PLAIN becoming standards track due to IESG
directives.  The obvious thing to protect your implementation is to punt PLAIN
to non-standard status, and do something new that everybody can implement
according to IESG directives.  You somehow seem to be incapable of this.  Why?