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