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

On Thu, Sep 2, 2021 at 5:03 PM Erik Aronesty <erik@q32.com> wrote:

> - 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
>

Proof of work requires the client to do additional work for the sake of
doing work. The server still has to do the same amount of work it would
have done had the client not done the proof of work (and in fact needs to
do slightly more work to verify the proof of work). This is not a zero-sum
game where some work is moved from the server to the client; it is a net
increase in the amount of work done.

>
> - 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.
>

[citation needed]

>
> 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
> >
> >
> >
> >
> >
> >
> >
> >
>
>