> > >> > My point is that the relevant semantics here are application semantics, > not TLS semantics. > > Regardless of what TLS says, nothing stops an application protocol from > allowing A to decide it doesn't care what B has to say and sending > close_notify then closing the transport connection. At this point, whatever > the B does is irrelevant because A isn't listening. >
Agree. TLS 1.2 imposed full close semantics. > Agree. What TLS 1.3 does is allow applications to choose *either* full close or > half close semantics, > (That is unclear to me from RFC 8446.) but doesn't have a TLS-level signal of which one the application wants. So, > the application can either have: > > - Once the other side sends close_notify, just stop sending ASAP (full > close) > - Once the other side sends close_notify, don't expect anything else, but > send what you want to send (half close). > TLS implementations with full close don't provide high-level applications with such choice (e.g., Bouncy Castle) whilst implementations with half close do (e.g., OpenJDK).
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
