This is also what is still proposed in the -01 version at the top of this
thread:
https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-01
By leveraging the HelloRetryRequest in TLS 1.3, it provides client puzzles
as an extension mechanism to TLS without requiring changes to the state
machine
or protocol itself. (Clients indicate support via an extension, and then
puzzles
are challenged with a HelloRetryRequest extension, and then the ClientHello
retry
contains the updated extension.)
Note that the -01 version still needs some updates to match up to more
recent TLS 1.3 drafts. (Some of the specifics may be a little out-of-date
and will be updated in the next revision.)
Erik
On Thu, Jul 7, 2016 at 5:36 PM, Kyle Rose <kr...@krose.org> wrote:
>
> I agree, and I think it is clear that client puzzles can be a useful
>> addition to the DDoS defense toolbox. However, most of this can be handled
>> at the higher levels above TLS, or possibly as a custom extension that does
>> not complicate TLS.
>>
>
> A custom extension is a promising approach: this is what Erik Nygren
> proposed in nygren-tls-client-puzzles-00 following discussions with some
> IETF folks and Akamai colleagues. That draft has expired and doesn't
> reference any of the recent work on memory-hard puzzles, but it might be a
> good starting point.
>
> Except at the pre-TLS stage for applications that use STARTTLS-style
> mechanisms, I'm not sure how this could work at levels above TLS: the
> primary attack targeted by client puzzles would be a client doing almost no
> work in order to force the server to do expensive crypto, which means it
> must be engaged prior to the handshake.
>
> Kyle
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
