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

On Wed, 25 Nov 1998, Randall S. Winchester wrote:
> 1) I have a concern about the lack of clarification after a NO is returned
> for a STARTTLS request. Here is an example of what I am concerned about:
> 
>    Example:    C: a001 CAPABILITY
>                S: * CAPABILITY IMAP4rev1 STARTTLS
>                S: a001 OK CAPABILITY completed
>                C: a002 STARTTLS
>                S: a002 NO security layer already active [Man-in-the-middle]
>                C: a004 LOGIN joe password               [Gotcha]
>                S: a004 OK LOGIN completed 
> 
> I do not see anything in the language preventing a NO from turning off TLS
> negotiation. This to me is a primary concern with not sticking with the
> dedicated SSL ports, which MUST use SSL/TLS. Of course the POP and ACAP
> language is terse as well. 

Exactly the same attack as having an attacker generate a rejection for the
SYN on the separate port.  The attack can be mitigated by (1) the client
having a "must use TLS" mode, and/or (2) the client remembers servers to
which it has successfully negotiated TLS and complains if negotiation
fails for any reason, and/or (3) make the fact that TLS is active visible
in the UI.

> 2)  In section 3.1:
> 
>       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.
> 
> If this is *necessary to protect* then why would you not have it read:
> 
>       Once TLS has been started, the client MUST discard cached
>       information about server capabilities and MUST 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.

"SHOULD" is used instead of "MUST" when there is a legitimate reason not
to take the action.  In this case, the legitimate reason is that the
client isn't using any protocol extensions or security mechanisms other
than STARTTLS.  I could change it to "MUST discard cached information
about server capabilities (excluding the presence of the STARTTLS
capability) and SHOULD re-issue the CAPABILITY command," but I prefer the
simpler wording unless others feel this is important. 

> This implies to me that the "CAPABILITY" before and after STARTTLS will
> always be different, unless you are allowed to advertise non "valid"
> capabilities. You should never see a "STARTTLS" in a CAPABILITY list after a
> sussesful TLS negotiation.

True.  I'll clarify the wording.

		- Chris