Re: Outstanding operations after TLS closure/renegotiation

Kurt and I chatted last night about this and here's a proposal:

1) 
Change the following language in 4.14.3 from:
> The initiating protocol peer sends the TLS closure alert. If it 
> wishes to leave the LDAP message layer intact, it then MUST cease to

> send further PDUs and MUST ignore any received LDAP PDUs until it 
> receives a TLS closure alert from the other peer. 

to this:

"The initiating protocol peer sends the TLS closure alert and MUST wait
until it receives a TLS closure alert from the other peer before sending
further LDAP PDUs."

This seems to say, more simply and without being overly prescriptive,
what the original text meant to address. Note there are cases where
receiving LDAP PDUs is reasonable (i.e. a notice of disconnection was in
transit when the client sent the TLS closure alert)

2)
Remove the last paragraph from 4.14.3 which reads:
>   After the TLS layer has been removed, the server MUST NOT send 
>   responses to any request message received before the TLS closure 
>   alert. Thus, clients wishing to receive responses to messages sent

>   while the TLS layer is intact MUST wait for those message responses

>   before sending the TLS closure alert.  

This is overly prescriptive, was added by the working group (not part
of the original text), and will now be covered in the security
considerations section.
 
3)
Merge Kurt's suggestion (earlier in this thread) to the paragraph
already in Security Considerations which says the same thing but in less
words. The new statement would read like this:
 
"Implementors should note that various security factors, including
authentication and authorization information and data security services
may change during the course of the LDAP session, or even during the
performance of a particular operation.  For instance, credentials could
expire, authorization identities or access controls could change, or the
underlying security layer(s) could be replaced or terminated. 
Implementations should be robust in the handling of changing security
factors.
In some cases, it may be appropriate to continue the operation even in
light of security factor changes.  For instance, it may be appropriate
to continue an Abandon operation regardless of the change, or to
continue an operation when the change upgraded (or maintained) the
security factor. In other cases, it may be appropriate to fail, or alter
the processing of the operation. For instance, if confidential
protections were removed, it would be appropriate to either fail a
request to return sensitive data, or minimally, to exclude the return of
sensitive data."