Hi,
you may be also interested in similar work done in ipsecme group:
https://www.ietf.org/id/draft-ietf-ipsecme-ddos-protection-06.txt
The draft describes various defnse methods against (D)DoS attacks in IKEv2
and, in particular, introduces puzzles. We tried to specify using puzzles
in such a w
On Wednesday, June 29, 2016 7:37 PM, Geoffrey Keating wrote:
>
> Kyle Rose writes:
>
> > Let's finish that last sentence:
> >
> > I have to think a lot more about the IoT/resource-constrained client
> > problem, but I still don't think the existence of clients that would be
> > denied service by
Kyle Rose writes:
> Let's finish that last sentence:
>
> I have to think a lot more about the IoT/resource-constrained client
> problem, but I still don't think the existence of clients that would be
> denied service by this scheme renders the concept completely inapplicable.
Perhaps for the re
Let's finish that last sentence:
I have to think a lot more about the IoT/resource-constrained client
problem, but I still don't think the existence of clients that would be
denied service by this scheme renders the concept completely inapplicable.
___
T
On Wed, Jun 29, 2016 at 5:41 PM, Christian Huitema
wrote:
> On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote:
> >
> > Raising the cost of requests has a similar problem in that you're
> punishing
> > every client, but in doing so you do allow all clients capable of
> absorbing
> > the increas
On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote:
>
> Raising the cost of requests has a similar problem in that you're punishing
> every client, but in doing so you do allow all clients capable of absorbing
> the increased cost (e.g., memory, computing power) to get access to the
> resource
On Wed, Jun 29, 2016 at 3:25 PM, Brian Smith wrote:
> Dmitry Khovratovich wrote:
> > It allows cheap and memoryless verification by the server even though the
> > puzzle solving guaranteely requires dozens of MB of RAM from a client
>
> I feel like this is impractical simply because lots of peop
On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla wrote:
> On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin
> wrote:
>
>> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote:
>>
>>> 2% is actually pretty good, but I agree that we're going to need
>>> fallback.
>>>
>>> I'd be fine with moving the 8 byte
Dmitry Khovratovich wrote:
> It allows cheap and memoryless verification by the server even though the
> puzzle solving guaranteely requires dozens of MB of RAM from a client
I feel like this is impractical simply because lots of people are
building HTTPS clients that don't even have dozens of MB
Dear all,
together with our colleagues from Akamai, we would like to pursue further
the draft on the TLS client puzzles, the first version of which was aired
in 2015. As before, the client puzzles allow a server to request clients
perform a selected amount of computation prior to the server perfor
10 matches
Mail list logo
