Re: I-D ACTION:draft-hoffman-rfc2487bis-02.txt

> At 01:13 AM 9/13/1999 +0200, Bodo Moeller wrote:
> > > The client might have to stop after the 220, such as if it realized 
> > that it
> > > couldn't really start TLS. Thus, the client should be able to issue a 
> > QUIT.
> > > Your proposed MUST NOT would prevent that.
> >
> >Deliberately, because forcing server implementations to be able to
> >recognize both protocols (clear SMTP and TLS handshake) complicates
> >implementation without really having any significant benefit: The 220
> >response to STARTTLS should not come as much of a surprise to the
> >client, or it should not have sent the STARTTLS command in the first
> >place.
> >
> >Is there really any (alleged) RFC 2487 server implementation that
> >continues as specified when the client sends clear SMTP commands after
> >the 220 answer to STARTTLS?
> 
> These are good questions. If no one *could* handle a text QUIT at that 
> point, Bodo's MUST NOT seems sensible. It would mean that, if a client 
> wanted to say "whoops", the only way would be to drop the connection, but 
> that is probably better than confusing the TLS stack with unexpected garbage.

I'm sorry that I have not been paying attention to this thread.  The
rule is: 

. if the START_TLS negotiation fails, then the server should should 
  drop the connection.

. if the client's policy is to allow a non-TLS connection, the client 
  should reconnect and refuse to negotiate START_TLS.

This is necessary because:

. after a TLS negotiation failure there is no guarrantee that the 
  channel has been cleared.

. allowing the automatic drop from TLS to plaintext on failure opens
  the door for a man in the middle attack.

It should also be noted that any information that is exchanged before
the negotiation of START_TLS should be forgotten once START_TLS is
attempted.  The list of services the server makes available over a
secure connection should not necessarily be the same as those provided
over the insecure connection.

These are the rules that are followed in the START_TLS Telnet Option.


  

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email protected]