[oefrha]

The only thing in this protocol that prevents the reuse of Authorization header is keeping track of nonce:

> Validating that the nonce has not been used already for this session. Important: at this point, the nonce should be added to the ‘seen’ set, because nonces should be invalidated whether the signature validation passes or fails. Failure to do so can allow attackers to brute-force a valid signature for a single nonce.

That's one extra db row / kv pair for every single request, including read requests, for very little benefit.

Request signatures incorporating timestamp and optionally path/payload are stronger, can be statelessly validated, and are already in use today on certain sites.

[tfigueroa]

I thought I was misreading this. It seems onerous to keep track of every nonce, even scoped to a given session. Maybe I’m missing something.

[kortex]

A Bloom or cuckoo filter would allow for efficient tracking of nonces (depending if the security model prefers false positives with 4xx/resend, or false negatives)

[cryptonym]

Still not ideal in a distributed environment, a request may have to synchronously go around the world to hit that nonce db.

[dcow]

Yeah I think the proposal should add some optional binding of the web session to http resource semantics.

Also re nonces if you only keep track of active nonces and have the server return a next-nonce, or use a counter like TLS, then you avoid the ugly need to keep track of seen nonces and only need to remember currently active nonces.

[janosdebugs]

The server returning the next nonce sounds like a huge headache when requests are run in parallel.

[apitman]

Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?

[oefrha]

What clock attack? You validate the timestamp on the server and reject if the timestamp is too far off. The same request being repeatable within say 30s isn’t a problem in 99% of cases.

[apitman]

I'm referring to threat models where the attacker might be able to manipulate time on the server, either directly or through NTP servers, etc. Personally it's not something I would worry about but I've heard it discussed and was wondering how big a concern it is.

[oefrha]

Well, then you still end up more secure than a regular session token.

[kortex]

That interferes with the ability to send multiple requests in-flight at the same time.

[apitman]

Good point. Timestamps probably have a much better set of tradeoffs.

[tommiegannert]

There could be a window: the last N sequence numbers are kept in a set, where N is higher than the number of concurrent requests.

[willvarfar]

Doesn't the server discarding requests with the timestamp beyond a threshold already do windowing but statelessly?

[tommiegannert]

I responded to this:

>> Timestamps can be vulnerable to clock attacks, right? Why not just include a monotonically increasing request number along with the nonce in each request?

> That interferes with the ability to send multiple requests in-flight at the same time.

I.e. it was assumed there was a sequence number, and I refuted that it disallows concurrent requests.

In general, I agree a signed timestamp is fine.