Re: returning to the previous state

At 8:41 AM -0700 5/19/97, Mark Wahl wrote:
> . . . [lots of good description of the TLS setup and teardown] . . .

>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.

I agree with you that the TLS protocol should not let one side send a TLS
message to another side that is no longer expecting it. My guess is that
this crept in due to "separate port" thinking: after the client sent it's
close_notify, it might immediately shut down the TCP connection. However,
this seems to be the only place in the TLS spec (...I say hopefully...)
that this kind of false assumption is made.

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

Well, if we haven't yet, we certainly will, unless all the TLS 1.0 API
designers take this into account and don't close the client side until
they've heard the server's close_notify. I'd certainly like to see this
change in TLS 1.1, if not in 1.0. TLS 1.0 is going to go into IESG last
call soon, so we have time to bring this up and maybe get it fixed.

--Paul E. Hoffman, Director
--Internet Mail Consortium