Works for me! Updated the PR with your suggestion (plus one extra word to be clear it's a subsequent KeyUpdate and not a random past one).
On Wed, Jun 12, 2024 at 3:56 PM Kyle Nekritz <knekr...@meta.com> wrote: > Yes, my worry is really around enforcement of a property that can’t be > strictly adhered to. How about something along the lines of: > > > > Until receiving a KeyUpdate from the peer, the sender MUST NOT send > > another KeyUpdate with request_update set to "update_requested". > > > > Note that implementations may receive an arbitrary > > number of messages between sending a KeyUpdate with request_update set > > to "update_requested" and receiving the > > peer's KeyUpdate, including unrelated KeyUpdates, because those > messages may already be in flight. > > > > I think this would make the requirement more clear, and avoid enforcement > of a requirement that can’t be strictly followed. > > > > *From:* David Benjamin <david...@chromium.org> > *Sent:* Thursday, June 6, 2024 5:48 PM > *To:* Kyle Nekritz <knekr...@meta.com> > *Cc:* Sean Turner <s...@sn3rd.com>; TLS List <tls@ietf.org> > *Subject:* Re: [TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345 > > > > 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 > > 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 > > > > 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
