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

Jeffrey Altman <[email protected]> Mon, 13 Sep 99 12:56:11 EDT
Newsgroups gmane.ietf.apps-tls
Message-ID <[email protected]>
> 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^).

That isn't exactly the point I was making.  In Telnet we have two
problems:

. Telnet protocol has it own requirements for byte processing.  IAC
  (0xFF) indicates the the following bytes are a Telnet Command.
  If 0xFF is to be sent on the wire as data it must be quoted.  CR
  must be followed either by NUL or by LF (unless BINARY mode has
  been negotiated.)  So there are potentials for conflict between
  TLS messages and  Telnet.

. we assume that most clients and servers are not going to
  re-implement TLS but instead will call down to a TLS library.
  Therefore, the application does not have access to all of the
  state information about the TLS negotiation.

When a telnet client connects to a server that supports START_TLS a
Telnet negotiation takes place:

  <other telnet negotiations might be sent or received>
  TELNET RCVD DO start-tls
  TELNET SENT WILL start-tls
  <other telnet negotiations might be sent or received>
  TELNET SENT SB start-tls FOLLOWS IAC SE
  <other telnet negotiations might be received - ignore them>
  TELNET RCVD SB start-tls FOLLOWS IAC SE
  <reset telnet engine to initial state - no longer use telnet protocol>
  [TLS - handshake starting]
  [TLS - success or failure]
  <if ok, restart telnet protocol and negotiations over secure channel>

When TLS negotiations fail the library returns control to the calling 
application.  At this point the application has no idea what the state
of the wire is.  If there is data there is it left over messages from 
the aborted TLS negotiation or is it telnet data.  Since that question
cannot be answered by the application, the connection cannot be used
to continue a plaintext connection.  Therefore, it must be dropped.



    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]