Re: [TLS] TLS Client Puzzles

On Mon, Jul 6, 2015 at 7:39 PM, Erik Nygren <erik+ietf@nygren.org> wrote:
> Sadly, even the ECDSA schemes and ECDHE key exchange still require the
> server
> to do significant work without the client needing to do any work.  For
> example on a
> sample modern processor (per core):
>
> - RSA 2048 signs       = 1,070 per second
> - ECDSA P-256 signs = 10,515 per second
> - ECDHE P-256 ops    = 6,070 per second
> - SHA-256 of 64 byte blocks = 2,136,484 per second

These numbers are far below what faster cryptography can deliver: I
have nearly a million gls254 computations per second, and 50,000 key
agreements per second on a kummer surface. Changing TLS to not require
online signing would realize this degree of performance.

At these rates you saturate gigabit ethernet connections, which
puzzles will not help with. In fact, they will make the problem worse.

>
> So even if you can ditch RSA signatures and do one ECDSA signature
> and one ECDHE op for key exchange, you're doing 3848 per core (so 3.8x over
> RSA
> which is a big boost, but not orders of magnitude of improvement).
> This helps a bunch, but there's no need for a client to do any work to get
> you to do that work.
>
> With a client puzzle and when under attack, you do some small number of
> SHA-256 ops
> and then the client will have to do some amount of work of your choosing.
> For example, giving the client ~500 SHA-256 rounds to do before you do an
> ECDSA
> signature will put the server at-parity with the client with respect to
> amount of crypto work.
>
> I'm all for simple solutions here, which is part of why anything here would
> ideally
> share as much in common with what's needed for DTLS cookies as well as use
> crypto routines already in-use in TLS as much as possible...

What about improving performance? That avoids any protocol changes,
and brings about the benefits you seem to want.

>
>          Erik
>
>
>
> On Mon, Jul 6, 2015 at 9:51 PM, Tony Arcieri <bascule@gmail.com> wrote:
>>
>> On Thu, Jul 2, 2015 at 2:40 PM, Erik Nygren <erik+ietf@nygren.org> wrote:
>>>
>>> Following a discussion last year in Denver, I've written up a proposal
>>> for a TLS Client Puzzles extension.
>>
>>
>> I'm sorry, but I think this is the wrong approach.
>>
>> I assume you're trying to solve the asymmetrical computation requirements
>> of RSA, a.k.a. the "THC DoS attack"
>>
>> If you're using RSA for key exchange, don't. It's very broken in more ways
>> than DoS.
>> If you're using RSA for signatures, it should be deprecated and phased
>> out.
>>
>> Trying to solve the latter problem by complecting TLS is likewise
>> something I oppose.
>>
>> Moving to ECC-based signatures (ECDSA or EdDSA or
>> CFRG-yet-to-be-standardized-signatures) would obviate this problem without
>> complecting the TLS protocol. ECC punts the computational burden to the
>> client, elegantly solving this problem by using the algorithms we want to
>> move to anyway.
>>
>> Complexity is the enemy of security.
>>
>> I prefer simplicity. To solve this same problem, I would prefer RSA
>> diediedie. I know that's a stretch, but I would prefer TLS gravitate towards
>> simple solutions than adding complex band-aids.
>>
>> --
>> Tony Arcieri
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.