W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

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

From: Erik Nygren <erik@nygren.org>
Date: Mon, 9 Aug 2021 22:25:18 -0400
Message-ID: <CAKC-DJi8119nVsni0r7vpt08+Y_YJ7qB+LD9s=t-LeOe5SyY7w@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Martin Thomson <mt@lowentropy.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 Tuesday, 10 August 2021 02:25:43 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 10 August 2021 02:25:45 UTC