Variant of your example: A receives a request, buffers M1,..., M5, receives close_notify after sending M4; A's peer sent the request before closing their write side. Half closure supports request-then-close. (Related thread in archive: https://mailarchive.ietf.org/arch/msg/tls/V47DfS4qdsdrF2QLHogsw_aNp9M/.)
Suppose the response is a wire transfer instruction with M4||M5 being "Charlie||'s Angels". With full closure the attacker's goal is to delay close_notify such that M5 is dropped. On Thu, 31 Aug 2023, 17:48 Eric Rescorla, <e...@rtfm.com> wrote: > Have I missed something? > I think we're on the same page. it seems to me that this is actually a somewhat complicated question that > is about application semantics more than about TLS itself. Specifically, > what sementics does the application think the close_notify embodies, half > close or full close? > RFC8446 leans towards half closure but doesn't mandate it. [For full closure,] it makes sense for A to just flush the outgoing data > Yes. [For half closure], we want A to continue sending and then eventually send > a close_notify when it has drained its queue. > But this suggests that we can't have a one size fits all rule in TLS and > rather should explain the situation and punt it to the application binding. > Why is this suggested? >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
