Re: [TLS] TLS client puzzles

[Kyle Rose]

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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS client puzzles

[Kyle Rose]

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 increased cost (e.g., memory, computing power) to get access to the
> > resources they need if the user is willing to accept that cost (e.g.,
> energy,
> > latency).
>
> The obvious issue with the "proof of work" defense against DDOS is that
> the bot nets can do more work than many legitimate clients. The puzzle
> approach will cut off the least capable legitimate clients, such as old
> phones or IOT devices. It will not cut off the PC enrolled in a bot net. It
> will merely slow it down a little. But then, you could have the same effect
> by just delaying the response and enforcing one connection per client.
>

I agree with you that the above seems equivalent in theory, but in practice
it might not be feasible.

The biggest obstacle seems to be enforcing one connection per client. Let's
say rate limiting on a per-client basis doesn't work because many of your
clients are behind a NAT; or because the attacker is using IPv6 and
generates a ton of temporary addresses that make the situation
indistinguishable from many legitimate clients in the same subnet. So you
can either serve one (or a small N) of them at a time, or you drop that
restriction and allow a single client to mount an asymmetric attack.

Alternatively, what if you have lots of geographically-distributed servers
and can't share client rate limiting state among them quickly enough to
detect and blacklist attackers?

It's possible there are additional asymmetric attack vectors I'm not
thinking of, which is why I like this as a general defense against a class
of attacks. I mostly agree it's mostly worthless when you have one server
facing a botnet of 100,000 machines, but frankly that one server is a
sitting duck regardless of countermeasures. OTOH, what if you have 20,000
servers facing such a botnet? Client puzzles effectively become a mechanism
for enforcing distributed rate limiting, and could be used to dramatically
raise the cost of mounting such an attack.

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  by
this scheme

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS client puzzles

[Christian Huitema]

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 
> resources they need if the user is willing to accept that cost (e.g., energy, 
> latency).

The obvious issue with the "proof of work" defense against DDOS is that the bot 
nets can do more work than many legitimate clients. The puzzle approach will 
cut off the least capable legitimate clients, such as old phones or IOT 
devices. It will not cut off the PC enrolled in a bot net. It will merely slow 
it down a little. But then, you could have the same effect by just delaying the 
response and enforcing one connection per client.

-- Christian Huitema




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Downgrade protection, fallbacks, and server time

[David Benjamin]

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 bytes to the end, but I wonder if it would
>>> be better to
>>> instead have the *client* indicate its max version and the server check.
>>> That would
>>> have the advantage that it would leave more of the server random intact.
>>>
>>
>> That sounds reasonable to me. I'd probably suggest still putting it at
>> the end since there's no reason to risk things, but I'm not aware of
>> anything that uses the client timestamp. (None of the clients I maintain
>> send it.)
>>
>
> Putting it at the end of the client gives the client options, so that
> would be fine.
>

To get this thread back on the original point, I put together a PR here for
the minimal change which just moves it to the end of server_random. This
would be sufficient to fix the problem which prevents today's 1.2 servers
from implementing 1.3.

https://github.com/tlswg/tls13-spec/pull/508

I don't particular care whether it's moved to the client or not. If you
think that's better, I'm happy to change it or defer to a different PR. (I
wasn't sure exactly what construction you were thinking for the
client_random version.)

David


>
>
>>
>>> -Ekr
>>>
>>> P.S. The FALLBACK_SCSV isn't a substitute because it isn't signed by the
>>> server.
>>>
>>
>> Yeah, FALLBACK_SCSV only gives us TLS 1.0-1.2-level downgrade protection
>> (otherwise the version fallback even loses that one). I only mean in terms
>> of mitigating the additional damage done by the fallback, not replacing the
>> entire mechanism.
>>
>> (Although, do we actually get the stronger protection if the client
>> accepts plain RSA key exchange? I've never been very clear on that.
>> Realistically, clients will be accepting plain RSA for a long while.)
>>
>
> Yes, that's correct. I don't believe we have a good plan for plain RSA.
>
> -Ekr
>
>
>> David
>>
>>
>>>
>>> On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin 
>>> wrote:
>>>
 In case folks hoped we could bump the ClientHello version without those
 dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much
 exists. (Maybe we should just give up on ClientHello.version and use an
 extension? Extensions have rusted less.)

 I picked a large list of top sites and tried connecting to them. Just
 under 2% of them could handle a TLS 1.2 ClientHello, but not the same
 ClientHello with the version switched to 1.3 (no other changes, so I
 haven't tested a real 1.3 ClientHello). They're not unknown hosts either. I
 expect if you probe any top site list, you'll very quickly find some.

 Fortunately, the ServerHello.random trick fixes this. But it currently
 clobbers the old server timestamp which tlsdate[1] uses for clock
 synchronization. There really should be a less silly secure timestamping
 protocol, but, today, tlsdate has users. Any servers which expect to be a
 tlsdate target can't honor this MUST without tlsdate gone.

 (FALLBACK_SCSV works fine as well, but I gather people prefer the
 ServerHello.random one and would be unhappy having to implement both in
 clients with a fallback because not all servers do the latter.)

 I mentioned this before, but rather than clobbering the first 8 bytes,
 the last 8 bytes seems as reasonable and avoids this unnecessary
 complication to TLS 1.3 deployment. If folks agree now that the
 fallback's resurrection is more certain, I'm happy to put together a PR.

 David

 [1] https://github.com/ioerror/tlsdate

 ___
 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

[TLS] TLS client puzzles

[Dmitry Khovratovich]

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 performing
expensive cryptographic operations such as signature computation.

The distinction of the current version is that it includes, besides the
well-known SHA-2 puzzle, a memory-hard puzzle called Equihash. The latter
is a recent development by our team in Luxembourg, presented at this year
NDSS. It allows cheap and memoryless verification by the server even though
the puzzle solving guaranteely requires dozens of MB of RAM from a client
(time, memory, and client-server asymmetry are tunable parameters).
Equihash has been recently adopted as primary proof-of-work in the
privacy-enhanced cryptocurrency protocol Zcash.

The draft is available at
https://datatracker.ietf.org/doc/draft-nygren-tls-client-puzzles/
and the Equihash paper at
https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf

We would appreciate comments and discussion, and would like to present the
draft at the upcoming IETF meeting in Berlin.


-- 
Best regards,
Dmitry Khovratovich
University of Luxembourg
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls