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

On Wed, 25 Nov 1998, Chris Newman wrote:

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

Well (3) is the visable outcome of (2), or otherwise "successfully
negotiated TLS" having been achieved. I belive the draft should be changed
to say something more like;

      A TLS negotiation begins immediately after the CRLF at the end of
      the tagged OK response from the server.  Once a client issues a
      STARTTLS command, it MUST NOT issue further commands until a
      server response is seen and the TLS negotiation is complete.

      If instead of the tagged OK response from the server, a NO
      server response is seen to a client issued STARTTLS command,
      the client MUST NOT issue further commands until it verifies
      the current session has a successfully negotiated TLS connection.
      If the client can not verify the current session has a successfully
      negotiated TLS connection, then it MUST NOT issue any clear text
      authentication schemes.


The Kerberos Telnetd from MIT has encryption turned off because it was shown
that this sort of attack makes the "encryption" option a false hope.

The client really needs to know when it has an active TLS connection to a
server, or not. Reliance on message over the net in the form of a "NO" is
not sufficient.


Randall