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

On Tue, 24 Nov 1998 00:25:06 -0500 (EST), Randall S. Winchester wrote:
> Interesting. Mark's wording appears to me both stronger and broader at the
> same time. Stronger in that it makes clear that unequivocally no PLAIN SASL
> may go out unencrypted. Broader in that by dropping the "This MUST NOT be
> implemented unless strong ... also implemented" it opens the door for
> wrappers like a modified "stunnel" to go infront of a server with a
> -plain_sasl flag.

Yes, both were intentional, but I didn't mention stunnel since I was
developing internal ssleay support in c-client (since finished, operational,
and working quite nicely; whether it can ever be distributed is another
matter...).

> Is this desireable? It sure makes implementing current imaps and pop3s
> servers a breeze.

I agree.  stunnel isn't all that bad; I ran that way for a while.  The main
disadvantage is if you want to do Kerberos authentication under encryption;
that won't work under stunnel but it will with an integrated package.

> Otherwise I thought you were both trying to say the same thing...

Actually, not; Chris' wording says (confirmed by Chris) that it is alright to
do PLAIN outside of an encrypted session as long as TLS is implemented (not
clear if "implemented" means via STARTTLS or imaps).  Chris' server permits
PLAIN in unencrypted sessions.

I contend that PLAIN should not be permitted.  It's alright that PLAIN does
not show up in CAPABILITY while unencrypted, since STARTTLS requires that a
new CAPABILITY command be issued.

I'm not convinced that STARTTLS is a good idea compared to imaps/pop3s/etc.
but now that I have imaps/pop3s/etc. it wouldn't be too hard to add STARTTLS.