Thanks. I understand your concern better now. First, I think it's useful to understand what the truncation being referred to in this case is. Suppose that A has queued messages M1, M2, ... Mn and receives the close_notify after it has sent M4. If it responds to the close_notify by flushing its write queue and sending a close_notify than M5...Mn will be dropped and hence the stream will be truncated. Note that the attacker cannot forge the close_notify, so so far this isn't actually an attack, just a correctness issue, depending on the semantics of the protocol above. What the attacker can do, however, is:
- Hold the close_notify, thus causing A to send more of the messages - With a congestion controlled protocol like TCP, slow down As sending rate. Initially, this will just cause A's packets to be buffered in the kernel, but they can't be recalled, so this doesn't affect what A sends, but eventually the kernel buffers might fill up and the application might stop sending, in which case it might be possible to cause more of A's stream to be truncated. Have I missed something? However, 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? In the latter case, it makes sense for A to just flush the outgoing data (and in fact, it's not clear that B really needs A's close_notify). In the former case, 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. -Ekr On Wed, Aug 30, 2023 at 2:42 AM Ben Smyth <resea...@bensmyth.com> wrote: > > > On Tue, 29 Aug 2023, 14:31 Eric Rescorla, <e...@rtfm.com> wrote: > >> On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth <resea...@bensmyth.com> wrote: >> >>> On Mon, 28 Aug 2023, Eric Rescorla, wrote: >>> >>>> ...there are quite a few situations in which endpoints close the >>>>>> connection before receiving a close_notify, for instance, when they >>>>>> receive >>>>>> an end of data message in the application protocol or when they time out. >>>>>> The former case is generally safe, the latter is not, but extremely >>>>>> common, in fact perhaps the dominant case....I'm not sure this is an >>>>>> erratum as I think it correctly describes the situation and it's a >>>>>> judgement call whether we ought to have a requirement here or whether >>>>>> it's >>>>>> a 6919 MUST (BUT WE KNOW YOU WON'T) >>>>>> >>>>> >>> TLS 1.2 dictates: Either party may initiate a close by sending a >>> close_notify alert...The other party MUST respond with a close_notify alert >>> of its own and close down the connection immediately, discarding any >>> pending writes. >>> >>> RFC 8446-bis could simply forbid that behaviour, e.g., This does not >>> have any effect on the read side of the sender's connection; a party >>> receiving a "close_notify" alert MUST NOT respond with a "close_notify" >>> alert of its own. Note that this is a change from versions of TLS prior to >>> TLS 1.3 in which receivers were required to react to a "close_notify" by >>> discarding pending writes and sending an immediate "close_notify" alert of >>> their own. >>> >> >> I must be missing something, as I don't see how that would help. Perhaps >> you could provide an example of what it is you are concerned about? >> > > Sure: As-is the specification doesn't mandate against the old behaviour; a > specification compliant implementation may be vulnerable to the TLS 1.2 > truncation attack arising from closure in both directions. Whilst I > appreciate the issues raised in this thread, I believe the specification > could be stricter by mandating against the old behaviour. As-is, hints are > raised, guidance given, but there's no strict requirement. Perhaps I'm just > reading too rigorously, there's no need to formally forbid---as an IETF > outsider, that seems a little lax, I'd expect a change from two-way closure > to one-way closure to be mandated, thereby explicitly teaching away from a > known vulnerability. RFC8446-bis is an opportunity to polish the original > spec. > >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
