Re: PoW (Re: Attack research on HTTP/2 implementations)

Pow is only one tool serving to delay clients, not a solution. It is useful
> to
> protect against small attacks but not against large ones.
>

Correct.

A useful tool, that allows smaller companies to host with fewer resources.

I can imagine large hosting companies might like the profligate waste that
people purchase in order to defend themselves these days.

But I think most smaller companies would prefer this.

The act of delivering the challenge can be simply a bit flipped in a header
packet.  The challenge itself can be a hash of some of the initial stuff
that's sent anyway.  I was thinking about a way to make sure that the
entire proposal consisted of a single bit.

Correct it only shifts the offset.  At most it improves things about a
hundred to one.  After that the attacker wins unless you have other tools.

ECDSA certs are a poor proof of work.  The best ratio you get is three to
one.  You're requiring a small amount of additional work for the client but
also for the server and it's quite significant what the server has to do.

Also you're making it so that you cannot serve your site to the public.
Which is not useful in many circumstances.

Your assertion about hosting providers is strange to me.


If POW gives small hosts  a 100/1 advantage over not having POW, protecting
them from all but the largest attacks, this clearly allows smaller hosting
providers to compete with larger ones in situations where they currently
cannot.

Obviously it can only be one tool.  But it's still an effective one in many
scenarios.

I run a relay network where we use this technique after https is
established on a websocket.  I can tell you that it is defended our network
admirably against more targeted/smaller attacks dozens of times this year
alone.






> In addition, the simple act of delivering the challenge to the client
> requires some work, and this work is a non-negligible ratio of the
> TLS calculation (typically 1/10 to 1/100), so that it remains very
> easy to take down a server by forcing it to just deliver many
> challenges. And in this case the client-to-server work ratio comes back
> to 1:1 approximately. This is even why attacks such as SYN floods, ICMP
> floods or UDP floods remain so popular these days.
>
> When you only want to deal with low-capacity attacks (those that PoW
> can help against), there are other, much simpler approaches, which
> already offset the client-to-server work. Just use ECDSA certificates.
> From what I've seen in field, they require about 5 times less work on
> the server while at the same time the client requires roughly 15 times
> more than the server. This simply allows to significantly raise the
> server's limits and bring them closer to other subsystems that are
> involved (e.g. the TCP stack and/or stateful firewalls).
>
> > but i'm arguing with people who have conflicts of interest, so i'm done.
>
> This assertion is particularly strange considering that all of us here
> have for interest to keep our respective components interoperable around
> the same protocol definition in order to minimize our bug reports and
> keep users happy.
>
> However, keep in mind that your approach of PoW would only be effective
> for very large operators, those that can deploy 100s to 1000s of servers
> to absorb moderately large botnets, and would not help single-server
> sites that remain trivial to knock down. I personally don't think we
> should encourage all internet hosting to be brought to ultra-large
> companies who could afford to protect it, and that's what your approach
> would inevitably result in because it is the only one that can be
> demonstrably effective there. It is not internet I'm dreaming of,
> personnally.
>
> Regards,
> Willy
>