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

"Randall S. Winchester" <[email protected]> Wed, 25 Nov 1998 11:55:53 -0500 (EST)
Newsgroups gmane.ietf.apps-tls
Message-ID <[email protected]>
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. 


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.


Ditto for the POP and ACAP specifications.


3) Along a similar vein a "2" above, Section 3.1 also reads;

      The STARTTLS command is only valid in non-authenticated state.
      The server remains in non-authenticated state, even if client
      credentials are supplied during the TLS negotiation.  The SASL
      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
      client credentials are successfully exchanged, but servers
      supporting the STARTTLS command are not required to support the
      EXTERNAL mechanism.

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.

Randall