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
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
<knekritz=40meta....@dmarc.ietf.org<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 <s...@sn3rd.com<mailto:s...@sn3rd.com>>
Sent: Monday, June 3, 2024 11:38 AM
To: TLS List <tls@ietf.org<mailto: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<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________
TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
