Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[[e-mail] (Martin Rex)]

I'm sorry for the confusion.  It seems I was wrong about OpenSSL behaviour.

Watson Ladd wrote:
> Martin Rex wrote:
>>
>> If you're vaguely familiar with OpenSSL:
>> when SSL_read() has received and processed a TLS record with a
>> close_notify alert, do you know what happens to further calls
>> of SSL_write() of the same handle, which technically is
>> _the_other_ communication direction.
> 
> Is this the case?

Actually -- no, I'm sorry.

I looked at the OpenSSL code again, and it doesn't seem to do that
on receipt of CLOSE_NOTIFY.  (It's more than 10 years that
I programmed on top of OpenSSL).  CLOSE_NOTIFY seems to only be sent
after an explict call of SSL_shutdown(), and connection state
(for the other direction) does not seem to be harmed by receipt
CLOSE_NOTIFY, nor by sending of CLOSE_NOTIFY (warning-level) alerts.
Only the communication direction that carried CLOSE_NOTIFY seems
(properly) defunct (ignoring further IO requests).

It seems that I was mislead by the semantics described in the TLS 
specification.




>
> Actually alerts trigger teardown of both sides. There is
> no half open state for TLS. Nginx manages fine on OpenSSL.

Teardown of both sides applies to fatal Alerts only.  One of the
reason for warning level alerts is that they should not tear down the
connection state, and close_notify (although the semantics described
in rfc5246 suggest otherwise) should tear down only the direction
on which it was sent.

So essentially, TLS should allow half-closed state, and at least
a glance over the OpenSSL code suggests that this implementation
would support it.



>From the sequence of (data processing) events, I still want to hold
off processing of CloseNotify until all prior TLS AppData records
are properly consumed by the application caller, so that when
the code writes traces about the progress of processing a connection,
the processing of the Alert will follow the passing of all prior
AppData to the application, and never precede it.


-Martin