zlacker

> And the flaw here is that the proposal doesn't do enough. If that signed blob allowed you to uniquely ID the device it would help solve a lot more problems.

This is more or less what the proposal does? It's akin to the same shady stuff seen here [1] except this time some third party gets to sign it.

> That would end DDOS for the most part and make managing abuse a lot easier.

Not every bot that I'm defending against is a DDoS but I can probably figure out a way to overwhelm the "pre-content" filter that's trying to figure out if a token is legit or not.

[1] - https://fingerprint.com/demo/

>>baby_s+(OP)
>Not every bot that I'm defending against is a DDoS but I can probably figure out a way to overwhelm the "pre-content" filter that's trying to figure out if a token is legit or not.

That's true of every DDOS filter. It doesn't mean that having a cryptographically secure way to make requests more expensive to produce isn't a tremendous help.

>This is more or less what the proposal does? It's akin to the same shady stuff seen here [1] except this time some third party gets to sign it.

The fingerprint isn't unique to the extent that you can rely on it always correctly identifying a single user. So you can't ban based on the fingerprint or automatically log someone in.

>>treis+fb
> It doesn't mean that having a cryptographically secure way to make requests more expensive to produce isn't a tremendous help.

A malicious actor wouldn't bother. They'll tap `/dev/random` when it comes time to send the blessed token to the origin. The onus is going to be on the origin to figure out that it's _not_ a valid/signed token. If it's as easy for the origin to do this as it is for the adversary to tap a RNG then what was the point? If it's harder for the origin to figure out my token isn't legit than it was for me to generate one, how is the origin better off?

In any case, you're filtering the DDOS out *after* you've managed to set up the TCP/TLS/HTTP connection. That seems to be a rather late/expensive point to do so!

>>baby_s+Xj
>If it's as easy for the origin to do this as it is for the adversary to tap a RNG then what was the point? If it's harder for the origin to figure out my token isn't legit than it was for me to generate one, how is the origin better off?

Because it's less computational intense than serving responses and/or trying to fingerprint malicious actors. It also tells you with near certainty that the request is malicious and future requests from that IP can be blocked.

>>treis+mr2
> It also tells you with near certainty that the request is malicious and future requests from that IP can be blocked.

So I can still use this to DDOS. My malware running somewhere on your network just needs to submit a bogus request from your IP address. Origin sees the bogus requests from your IP and now that IP is on the bad list. Later - your legit requests from the same IP are ... denied.

I don't know that an "inverse" DDOS is novel, but it's certainly not been common. Perhaps that may change in the future...