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
