Re: returning to the previous state

>>After a TLS connection has been established over top of an existing protocol'
>>TCP connection, as could be done using draft-hoffman-smtp-ssl-02, is the
>>meaning of the "close_notify" alert in TLS that the sender will revert
>>back to
>>using the protocol (such as SMTP) in the state from before TLS was
>>established?
 
> That's outside of the specs. :-)
 
> But seriously, it really is. There is nothing in the TLS spec that says
> anything about the API that is used to tell the higher-level protocol (in
> our case, SMTP). So, for example, when I say in the SMTP/TLS spec "you must
> check whether the level of privacy you got from the TLS handshake is enough
> to go on", I do not say how to check this because that is an API issue.
 
I'm sorry my original message wasn't clear.  

My concern is not about APIs, but on the interaction between protocol 
components when a TLS module has been inserted into the protocol stack.  


Section 6.2.1 of draft-ietf-tls-protocol-02.txt

>   Each party is required to send a close_notify alert before closing
>   the write side of the connection. It is required that the other
>   party respond with a close_notify alert of its own and close down
>   the connection immediately, discarding any pending writes. It is not
>   required for the initiator of the close to wait for the responding
>   close_notify alert before closing the read side of the connection.

>   NB: It is assumed that closing a connection reliably delivers
>       pending data before destroying the transport.

If one were to insert the TLS module into, for example, the LDAP protocol,
then before the insertion, the protocol would be layered as:

Client     Server
LDAP        LDAP   (LDAP connection)
 |           |
TCP ------->TCP    (TCP connection)

After the two ends of TLS have negotiated, the protocol would be layered as:

Client     Server
LDAP        LDAP   (LDAP connection)
 |           |
TLS         TLS    (TLS connection)
 |           |
TCP ------->TCP    (TCP connection)

The client sends a close_notify alert.  It is not required for the 
initiator of the close to wait for the responding close_notify alert before
closing the read side of the connection.  This means the client falls back
to 

Client
LDAP  
 |    
TCP 

The server will receive the client's close_notify.  The server is required 
to send a close_notify of its own.  However, since the client has closed the 
read side of the TLS connection, this means the server's close_notify will be 
delivered to the LDAP module in the client.  This is a protocol violation 
since a TLS close_notify is not a valid LDAP response.

This appears to me to be a defect in the TLS specification. I would have 
expected it to read something like:

>   It _is_ required for the initiator of the close to wait for the responding
>   close_notify alert before closing the read side of the connection.

That way the client will drain off all TLS messages before restoring the 
protocol to its original pre-TLS state.

I wished to check with this mailing list on application use of TLS to see if
other protocol designers had encountered this same problem.

Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.