MBOX-Line: From guenther+imap at sendmail.com  Tue Mar  8 13:58:18 2011
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Pipelined commands before completion of STARTTLS
In-Reply-To: <4D7690AE.8020003@andrew.cmu.edu>
References: <4D7690AE.8020003@andrew.cmu.edu>
Message-ID: <alpine.BSO.2.00.1103081341530.1958@morgaine.smi.sendmail.com>

On Tue, 8 Mar 2011, Ken Murchison wrote:
> Pursuant to http://www.kb.cert.org/vuls/id/555316
> 
> I was wondering what the proper server behavior should be if a client 
> sends commands between STARTTLS and the server response.  RFC 3501 
> states that this is a client MUST NOT but doesn't discuss how the server 
> should handle it.
>
> I can see two possibilities (maybe there are others):
> 
> 1. Send a BAD response if a command is pipelined after STARTTLS.  
> Should BAD be sent in response to STARTTLS or the following command?
> 
> 2. Ignore the pipelined cleartext commands.

3. immediately close the connection

4. Treat data after the CRLF as data for the TLS handshake (i.e., to shave
   an RTT off in the success case).  I seem to recall a proposal for an
   SMTP extension to indicate that the server would guarantee that 
   STARTTLS would succeed and that it could handle having the client's
   handshake message pipelined with the STARTTLS request.  (QTLS was it?)

The standard places no requirements on the server's behavior if the client 
violates that MUST NOT.  Common sense says "don't be insecure", but since 
it's a non-obvious problem it probably should be called out if/when the 
standard is revised.

However, I don't think the standard should _require_ behavior (1), (2), or 
(3), as behavior (4) should be permitted going forward.


> Questions:
> 
> - Should this be done regardless of whether TLS is negotiated successfully?
> - Can/Should the connection be immediately terminated?
> - Should the behavior be any different for POP3, NNTP, SMTP/LMTP?

I would say:
 - don't care, as long as it doesn't use insecure data
 - behavior (3) seems legal to me (client violated a MUST NOT, so even 
   nasal daemons may be summoned), so "can", but I don't think that's
   the best way to handle it
 - I see no particular reason for the protocols to differ, but neither
   do I think a common behavior is required


Philip Guenther
guenther@sendmail.com

