On 7/12/2018 2:39 PM, Simone Bordet wrote:
Hi, On Thu, Jul 12, 2018 at 11:10 PM Xuelei Fan <xuelei....@oracle.com> wrote:In TLS 1.3 closure, receiving of the close_notify is not required: "... Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation." TLS 1.2 also has similar specification: "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." My reading the spec, the peer MUST send the close_notify, but it is not required to close the connection. If the socket cannot be closed until close_notify get received, the local may never have a chance to close the socket unless the peer agrees. It does not sound like to me. The compatibility impact could be serious as previous application work in a duplex-close manner. 1. start and establish a TLS connection. 2. client call close(), and the server will response with a close_notify in TLS 1.2. the TLS connection can be closed gracefully. While for TLS 1.3, #2 does not work if the client calling of close() closes the writing side only, and leave the reading side open. I see the benefits of half-close. I'm open to hear a better solution to take the benefit of half-close and avoid the compatibility issue.Even in TLS 1.2 you cannot be sure that the server will send the close_notify (e.g. bad server).
Yes, but normally, the server MUST respond with a close_notify.
The half close problem is present in TCP, WebSocket, etc. and it's typically solved with (idle) timeouts. Client sends the close_notify, then reads, hoping to see the close_notify from the server; if it does not see it, it closes the raw socket after a timeout. The timeout could account for receiving data (i.e. it is reset if application data arrives), or not.
I will think more about this proposal. Thanks, Xuelei
