Regarding 1343, the PR is a rule on the sender, not the receiver. After all, it says "The sender MUST NOT". It is not a rule on the receiver.
We have interop problems *today* when one side sends too many KeyUpdates, triggered by data received. The PR does not ask receivers to enforce stuff, but (mostly) prevents senders from tripping receiver DoS limits and thus causing an interop problem. I say mostly because the scenario you mention is a good one. I hadn't thought of that. But that scenario is not an interop problem introduced by 1343. It's a scenario that 1343 doesn't fully solve, but* still dramatically improves*. Prior to 1343, a server with a buggy update_requested policy would send 3GB / 16K = 196,608 KeyUpdates for every 4 GB of data sent by the client, assuming full records. This will very, very easily trip DoS limits and quickly cause the connection to fail. 1343 clarifies that this update_requested policy is wrong sender behavior. You're right that 1343 doesn't completely solve the problem. The server will misinterpret the client's own KeyUpdates as response and send 1 KeyUpdate for every 4 GB of data. That is, however, an improvement by a factor of 196,608x. It would take a lot more traffic to trip a DoS limit under that scenario. Ideally we'd come up with an even better sender rule, but I suspect we cannot do so without completely redesigning updated_requested. During TLS 1.3's development, my position was that update_requested was a mistake and we should remove it, precisely due to its propensity for DoS and interop problems. I think that position has proven to be the right one, but it's too late to remove the feature now. 1343 is the best option I see to fix it right now. On Thu, Jun 6, 2024 at 1:46 PM Kyle Nekritz <knekritz= 40meta....@dmarc.ietf.org> wrote: > I object to 1343 because I don't think it can be implemented without > risking interop problems. There is nothing tying a KeyUpdate response to > the KeyUpdate that requested it, or distinguishing it from an unrelated > KeyUpdate. As an example of how this can cause practical problems, say we > have two peers with the following policies: > > Client: sends KeyUpdate with update_not_requested every 4GB of data sent > (which is a reasonable policy, effectively making sure the client doesn't > violate its own data limits, and letting the peer handle theirs) > Server: sends a KeyUpdate with update_requested every 1GB of data sent by > either peer (similar to the motivating example in the issue) > > If, like in the example in the issue, the client is sending a large amount > of data, and not reading anything from the server until it's done, and the > server isn't sending any response application data, the server will send an > update_requested KeyUpdate after 1GB of data from the client. The server > will then be blocked from sending more KeyUpdates due to the proposed > requirement. However once the client sends 4GB of data, it will send an > update_not_requested KeyUpdate. To the server, this will appear to be a > response to it's KeyUpdate request, and it will be free to send another > update_requested KeyUpdate. However, to the client, this will appear as a > redundant KeyUpdate, since the KeyUpdate it sent wasn't actually in > response to the server's first KeyUpdate. If the client enforces the MUST > NOT added in the PR, this will cause a failure. > > -----Original Message----- > From: Sean Turner <s...@sn3rd.com> > Sent: Monday, June 3, 2024 11:38 AM > To: TLS List <tls@ietf.org> > Subject: [TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345 > > !-------------------------------------------------------------------| > This Message Is From an External Sender > > |-------------------------------------------------------------------! > > Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been > submitted (and discussed) that include changes to normative language: > > - #1343: Forbid the sender from sending redundant update_requested > KeyUpdates > https://github.com/tlswg/tls13-spec/pull/1343 > > - #1345: Forbid the sender from sending duplicate supported groups entries > https://github.com/tlswg/tls13-spec/pull/1354 > > The discussion so far seems to support consensus to merge these PRs. If > you object, please do so on the issue or in response to this message. > Absent any pushback, we will direct the editors to incorporate them in two > weeks' time. > > Cheers, > spt > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
