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

- Proof of work is a mitigation for an attack... where the server is
obliged to perform cryptographic computations during negotiations that
expend energy... and instead requests that the clients perform an
analogous amount of work in order to mitigate the attack

- Certainly requiring the server to perform all of the computations
isn't more environmentally friendly than requiring the client to do
the same work, right?

- So that's not really an issue here

- Nor should it ever be a concern.  1) Governments, not protocol
developers, should be responsible for improving carbon capture.   2)
We cannot know that the efficiency gained by these mitigation of
attacks isn't greater than the presumed efficiencies lost.  3) Bitcoin
is a good example of a protocol where proof of work clearly saves more
energy than it expends - even though the analysis is not trivial.

On Mon, Aug 9, 2021 at 10:28 PM Erik Nygren <erik@nygren.org> wrote:
>
> On Mon, Aug 9, 2021 at 8:20 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>> It probably isn't, but just in case this is a bit of less
>> well known history...
>>
>> On 10/08/2021 01:00, Martin Thomson wrote:
>> > Most of these never went anywhere for a range of reasons.  One of
>> > those being that proof of work is an abomination (and I don't say
>> > that lightly).
>> I think there were also ideas of less onerous proofs that
>> went by the name "client puzzles" but that also fell by the
>> wayside, IIRC due to what's by now likely expired IPR.
>
>
> As an example see:
>
>     https://datatracker.ietf.org/doc/html/draft-nygren-tls-client-puzzles-02
>
> A real challenge is finding a balance that can let a range of legitimate clients
> through while blocking a range of attackers.  (For example, that draft
> has both CPU-hard and memory-hard puzzles.)
>
> To avoid battery-life and environmental / energy impact, these would
> presumably only get employed during attack scenarios, but figuring
> out when that is is a challenge.
>
> The protocol side of this isn't hard, but it adds some real complexity
> and understanding how to use it effectively isn't straight-forward.
>
> In one of the TLS WG interims, a request was for a deeper
> analysis of the scenarios where client puzzles would and wouldn't help,
> which seems like a great academic modeling project for someone
> so-inclined.
>
>     Erik
>
>
>
>
>
>
>
>

Received on Friday, 3 September 2021 00:00:18 UTC