Explain the reasoning for the gap in verifying the Date value

[evanp]

I'm not seeing a lot of reason to have a 1-hour gap, if the sender is signing at sending time instead of queuing time, and the receiver is verifying at receiving time instead of queued delivery time. That seems like a big gap to account for TCP/IP lag or clock drift!

[evanp]

I should probably diagram what I think typical steps are here:

user creates content -> content is queued for remote delivery -> HTTP request is made -> HTTP request is received -> content is queued for local delivery -> remote user gets content

The time between when the first user creates the content and when the remote user gets the content can vary wildly based on the queues on both sides. But if the signature is made just before the request is initiated, and the signature is verified just when it is received, the only delay is going to be the time it takes for the request to get from the sending server to the receiving server -- probably a handful of seconds.

[snarfed]

We discussed this in #32 too. Mastodon's current window is an hour, https://github.com/swicg/activitypub-http-signature/issues/32#issuecomment-2002610607 . Clock skew over the internet can be surprisingly wide, and time zones and daylight savings time end up configured differently across networks and systems in all sorts of ways. That might be one argument for at least an hour, plus some buffer.

I don't feel strongly about the size of this window. I haven't seen concrete numbers in ay of the related standards, nor have I seen deep dive analyses elsewhere on how to determine it. (They may exist, I just haven't personally seen them.)

I'm hard pressed to come up with a threat vector that a narrow time window satisfies. Ie, what's the situation where an attacker can generate a valid signature that's an hour off of the target server's clock, or a day, but not closer? Compromised key, maybe, but then all bets are off for signatures with that key. Otherwise...?

[snarfed]

An easy answer here is to just not give a concrete number. That's unsatisfying, especially given the explicit request for it in #32, but it is an option.

[nightpool]

Mastodon originally had a 12 hour look-back window, allowing for payloads to fail and be redelivered without necessarily needing to be resigned, but not accounting for forward clock-skew. When Claire revamped the code in 2020 to support the more modern hs2019 draft, we separated that into two different checks: one for the expires param (that it is no more than 1 hour different from the current time in either direction) and one for the created param (that the signature is valid for no more than 12 hours total, preventing reuse attacks and allowing servers to choose whether or not they wish to re-use signatures when payloads are queued for redelivery due to network or transient application failure).

[evanp]

We discussed this in #32 too. Mastodon's current window is an hour, #32 (comment) . Clock skew over the internet can be surprisingly wide, and time zones and daylight savings time end up configured differently across networks and systems in all sorts of ways. That might be one argument for at least an hour, plus some buffer.

This is a great argument; I think including it in the text is a good idea!