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

On Tue, 24 Nov 1998 12:07:27 -0800 (PST) Mark Crispin <[email protected]>
wrote:

> > So I'll
> > add the "NOLOGIN" IMAP4 capability to the spec, which indicates either
> > the IMAP4 LOGIN command is completely unsupported, or it's only available
> > after STARTTLS.
> 
> I agree with the intent, but this needs rephrasing.  Here are my issues:
>  1) I think that "LOGINDISABLED" is better than "NOLOGIN", particularly since
>     we are introducing a surprising behavior for a guy who just read RFC 2060.
>  2) I object to "completely unsupported"; the base spec makes no allowance for
>     LOGIN to be unsupported.  I prefer "disabled".  For the same reason, the
>     error for an attempted LOGIN should be NO, not BAD.
>  3) I object to "only available after STARTTLS" since that precludes some
>     other means by which it might be available.
> 
> Here's how I think we should deal with (3).  We should amplify the text in
> STARTTLS:
>       Once TLS has been started, the client SHOULD discard cached
>       information about server capabilities and re-issue the CAPABILITY
>       command.  This is necessary to protect against man-in-the-middle
>       attacks which alter the capabilities list prior to STARTTLS.  The
>       server MAY advertise different capabilities after STARTTLS.
> to indicate that the capabilities returned after STARTTLS *override* what was
> returned prior to STARTTLS.  As an explict example, state that LOGINDISABLED
> may disappear from the capability list after STARTTLS, thus indicating that
> LOGIN can be done under TLS.

I'll go along with this.   I also like the terminology for "disabled" 
rather than unsupported simply because of the optics.    It is in fact 
exactly what is going on in the server.   We've had a (private) capability 
for this for some time.   It works well.

Cheers.
---  
Steve