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

> That's not exactly the situation that we are discussing: RFC 2487
> allows the client to continue without even having really attempted to
> start a TLS handshake -- the client sends STARTTLS, the server replies
> 220, and the client sends any other SMTP commands (intended use is to
> send QUIT only, but there's no such restriction in the specification)
> in clear where one would expect a client hello message.

The relevant text from the LDAP-TLS spec
(draft-ietf-ldapext-ldapv3-tls-05.txt) is:

  4.2.  Starting TLS

  The server will return an extended response with the resultCode of suc-
  cess if it is willing and able to negotiate TLS.  It will return other
  resultCodes, documented above, if it is unable.

  In the successful case, the client, which has ceased to transfer LDAP
  requests on the connection, MUST either begin a TLS negotiation or close
  the connection. The client will send PDUs in the TLS Record Protocol
  directly over the underlying transport connection to the server to ini-
  tiate TLS negotiation [TLS].

So in the LDAP case the client is constrained to only doing the TLS
negotiation after the server indicates it can do so, as Bodo suggests for
SMTP.  So, I agree with the proposed change.  If a client is so
ill-designed that it would decide to abort the TLS startup immediately
after requesting it, it can do that via simply closing the underlying
transport connection, it seems to me.

I was looking for text in ldapv3-tls saying that upon successful
negotiation both sides must only send TLS-format data (the point Jeffrey
was making about Telnet), and it doesn't seem to be there, unfortunately.
I guess we assumed this was obvious ... 8^).

 - RL "Bob"