[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TLS and ACAP/IMAP/POP
Ok, the text may be simple, but I'm not convinced the issue is simple.
The following questions come to mind:
(A) Do most or all current SSL/TLS API's support closing TLS without
closing the underlying socket? If they don't it adds significant extra
complexity to require it.
(B) Is it really useful to close TLS and continue the connection with no
connection? With LDAPv3 it is likely useful since writes are infrequent
and reads of public information are frequent. With IMAP/POP/ACAP I'm far
from convinced since there is less public information and mixed read/write
access is the norm. Does 3DES by itself result in servers becoming
CPU-bound rather than I/O bound? Would it be useful to support use TLS in
a mode where the security layer is only active during authentication to
make it slightly easier to integrate into an app protocol?
I'm inclined to remain silent on this issue until we're confident "yes" is
the answer to these questions. Does anyone strongly object to this
On Sat, 18 Apr 1998, RL Bob Morgan wrote:
> The ldapv3-tls draft spec has the following:
> 5.1. Graceful Closure
> Either the client or server MAY terminate the TLS connection on an LDAP
> association by sending a TLS closure alert. This will leave the LDAP
> association intact.
> Before closing a TLS connection, the client MUST either wait for any
> outstanding LDAP operations to complete, or explicitly abandon them
> After the initiator of a close has sent a closure alert, it MUST discard
> any TLS messages until it has received an alert from the other party.
> It will cease to send TLS Record Protocol PDUs, and following the
> reciept of the alert, MAY send and receive LDAP PDUs.
> The other party, if it receives a closure alert, MUST immediately
> transmit a TLS closure alert. It will subequently cease to send TLS
> Record Protocol PDUs, and MAY send and receive LDAP PDUs.
> Similar language would presumably work in the IMAP/POP/ACAP draft.
> I suggest that dealing with the connection-closing issue is easy, and
> should just be done.