What is a "valid time window"? Acceptable difference in Date headers?

[edent]

I'm slightly confused about the purpose of the Date header in validating signatures.

7.2.4 of https://datatracker.ietf.org/doc/rfc9421/ says:

Applications processing
signatures for valid time windows should use the created signature
parameter for such calculations. An application could also put
limits on how much skew there is between the Date field and the
created signature parameter, in order to limit the application of
a generated signature to different HTTP messages.

What is a valid time window? How much skew should be acceptable?

I've set my software to reject anything beyond a ±30 second difference. Is that a sensible limit? Should I also look at the difference between the date in the signature and the date I received the request?

[snarfed]

Yes! I think 30s is the most common answer, iirc that's what Mastodon does, but I don't know many details yet, or which additional timestamps things to compare, etc. Definitely good fodder for this report.

[edent]

I think Mastodon does it differently.

They do:

CLOCK_SKEW_MARGIN       = 1.hour

...

return false if created_time.present? && created_time > Time.now.utc + CLOCK_SKEW_MARGIN

From:
https://github.com/mastodon/mastodon/blob/82c2af0356ff888e9665b5b08fda58c7722be637/app/controllers/concerns/signature_verification.rb#L11

https://github.com/mastodon/mastodon/blob/82c2af0356ff888e9665b5b08fda58c7722be637/app/controllers/concerns/signature_verification.rb#L183

To me, that looks like they're comparing the Date in the header, and seeing whether it is over one hour different to the time on the receiving server.

They don't compare the signature to the published date at all.

[snarfed]

Ah, thanks for the sleuthing! I saw something about their sig handling and a 30s window recently, but either I misread it or it must have been wrong.

[snarfed]

Here's the language I ended up using:

Compare the request's Date header to the current time. If they differ significantly, eg more than an hour, the verification fails.

Personally, I don't really think the exact window here is a big deal. It's hard to imagine an attack based on replaying or otherwise misrepresenting the exact time someone sent a given activity, if they otherwise did send it legitimately in that approximate time window. I'm open to feedback though.