On Wed, Mar 17, 2021 at 08:15:53AM +0100, Ben Smyth wrote:
> > Do I understand that right? And if so, what is the point of the
> > language in the RFC that appears to permit a half-close?
>
> Specifications don't define systems, they guide design. The specification
> does not "requir[e] an end to hold off sending a Close alert until after if
> has received all data that the far end is expected to send," the
> specification merely allows such behaviour. Perhaps one scenario where that
> behaviour is useful: An endpoint is about to be comprimised and raises an
> alert to avoid secrets being leaked.
FWIW, I largely part ways with Ben's assessment, and particularly the
strawman scenario above. TLS 1.3 does in fact make it possible to
support half-close in mutually cooperative applications, and there
is no expectation that a close-notify on one side must immediately
be accompanied by a similar action on the other, the other side
can continue to send applicatoin data traffic.
However, what I don't read into 8446 is an obligation or expectation
that applications will routinely support half close. Some probably
should (e.g. an HTTPS server should probably continue with its response
even after a half-close on the client-side following the request).
However, if applications don't support half-close, and fail to respond
to prior requests upon receipt of close-notify, I don't think they're
violating the specification, they're merely not half-close compatible.
If some application protocol is expected to support half-close, that
should be specified in some relevant application-specific standard.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
