On Tue, 16 Mar 2021, 20:03 Jeremy Harris, <j...@wizmail.org> wrote: > On 16/03/2021 07:53, Ben Smyth wrote: > > Further, is it reasonable for the above first end to > >> expect the above second end to continue processing and > >> sending data that would have been sent in the absence of > >> such a first Close Alert? > >> > > > > The endpoint should expect their interlocutor to ignore any data received > > after the alert: Any data received after a closure alert has been > received > > MUST be ignored. > > > > The endpoint should expect any data sent before raising alert > close_notify > > to be delivered: It is assumed that closing the write side of a > connection > > reliably delivers pending data before destroying the transport. > > > > Whether an interlocutor processes data sent before alert close_notify is > > seemingly not governed by the specification, which seems reasonable. > > So, that doesn't directly answer that portion of my question - but > does appear to make a half-close useless, by requiring an end > to hold off sending a Close alert until after if has received all > data that the far end is expected to send. > > 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
