[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Hi! Thanks all to those who participated! We have consensus to land these two PRs; #1343 got tweaked during this call. ekr - merge when you get a chance. spt > On Jun 12, 2024, at 16:23, Sean Turner wrote: > > Hi! Just reminder to get any concerns about merging these in by 17 June 2024. > > spt > >> On Jun 3, 2024, at 11:38, Sean Turner wrote: >> >> 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]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Hi! Just reminder to get any concerns about merging these in by 17 June 2024. spt > On Jun 3, 2024, at 11:38, Sean Turner wrote: > > 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]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
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 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 > *Sent:* Thursday, June 6, 2024 5:48 PM > *To:* Kyle Nekritz > *Cc:* Sean Turner ; TLS List > *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 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, sinc
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
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 Sent: Thursday, June 6, 2024 5:48 PM To: Kyle Nekritz Cc: Sean Turner ; TLS List 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 ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd 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 mailto: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 mailto:s...@sn3rd.com>> Sent: Monday, June 3, 2024 11:38 AM To: TLS List mailto:tls@ietf.org>> Subject: [TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345 !---| This Message Is From an External Sender |
[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 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 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 > Sent: Monday, June 3, 2024 11:38 AM > To: TLS List > 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
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
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 Sent: Monday, June 3, 2024 11:38 AM To: TLS List 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]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Gentle reminder about these two PRs. I should note there are now others. spt > On Jun 3, 2024, at 11:38, Sean Turner wrote: > > 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
