[TLS] Re: TLS client puzzles revival

[David Benjamin]

I'm not very excited about this DoS approach. Many user-facing clients run
on battery-constrained devices, so burning CPU on a hash puzzle in those
contexts is unappealing. Before we resort to mitigating a server's high
energy cost by increasing energy cost across the board, we should exhaust
avenues for decreasing the energy cost across the board. In particular...

I don't think the 10x figure for RSA certificates matters here. Any
approach with a new extension, like client puzzles, will only be available
in newer clients. This means, as a baseline, you're already assuming the
server can reduce service to older clients that don't support
the extension. (Or deny service if all supported clients have it.) Rather
than ask clients to implement this extension, you could instead ask newer
clients to support ECC-based server certificates[*], and then reduce or
deny service to older RSA-requiring clients instead. Client puzzle's DoS
capacity is only meaningful when you're already using more efficient server
credentials.

If, even with ECC-based server certificates, DoS is a concern, I would
suggest reviving draft-ietf-tls-batch-signing instead. That was adopted by
the WG, but it was parked because interest (including from my end) waned.
But I would be much more interested in building that than in building an
extension whose sole purpose is to burn CPU. Batch signing means the cost
of the server signature is basically irrelevant. If you get a storm of
requests from batch-capable clients, they all can be serviced with a single
signature. Even if you only have the capacity to globally generate one
signature at a time, you can still batch together all your incoming
connections to be serviced by that one batch.

David

[*] Of course, if you are a hosting provider whose customers provide keys
and certificates, they might not have provided an ECC credential. But, in
that scenario, encouraging ECC credential from your customers is a much
more impactful DoS capacity win because ECC-capable clients are already
widely deployed.

On Thu, Oct 31, 2024 at 10:14 AM David Venhoek  wrote:

> Dear TLS working group,
>
> Given recent experiences by some parties of DDoS attacks that abuse
> the TLS handshake to force a server into spending significant
> computational resources (see Eirik Øverby's talk at
> https://www.youtube.com/watch?v=pBNMWvfL05g for an example), we have
> decided to give adding handshake DDoS protections another go. The
> draft is available at
> https://github.com/tweedegolf/draft-TLS-client-puzzles already and we
> will be submitting it to the IETF datatracker shortly.
>
> In the interest of giving this effort a better shot at success, we are
> currently also working on implementing this proposal for a number of
> major TLS implementations, including OpenSSL and BoringSSL. We already
> have a near-complete implementation for RusTLS, and a working patched
> version of Chromium. We will have these available as a demo during the
> hackathon, where we will also be putting in some work to get more
> implementations working (project TLS Client puzzles:
> https://wiki.ietf.org/en/meeting/121/hackathon#tls-client-puzzles). If
> you are in any way interested in this please come say hi.
>
> Motivation for this work is that implementing this draft has, based on
> preliminary measurements on nginx, the ability to provide at least a
> 4x increase in capacity to withstand attacks when using Ed25519
> certificates (and a factor 10x for RSA certificates). Furthermore, the
> draft is written to allow for a custom TLS implementation that can
> handle the generation and checking of puzzles in a different security
> domain. So it is possible to create a third party service that parties
> can use to mitigate DDoS attacks without having to provide that third
> party with full unencrypted access to all traffic.
>
> This last point is also why we feel it is important to pursue this
> work. Although right now it is possible to mitigate DDoS attacks by
> paying a large cloud provider to handle TLS termination, this requires
> the cloud provider to handle the unencrypted data. From a privacy
> perspective, this is not always desirable, and in some industries
> (such as finance and perhaps healthcare) might not even be allowed
> because of compliance rules.
>
> Our aim is not to make these attacks entirely impossible, but rather
> to allow the defender to raise the cost for the attacker. Especially
> financially motivated attacks can be significantly deterred by this.
> This is also what motivates us to use hash functions like SHA2,
> prioritizing a low cost for the server to check puzzles rather than
> maximizing difficulty for attackers. This ease of checking together
> with the ability to offload the server side of handling the puzzles
> should avoid the problem of the puzzles themselves becoming an attack
> vector.
>
> Kind regards,
> David Venhoek
> Wouter Bokslag
> Marc Schoolderman
>
> __

[TLS] TLS client puzzles revival

[David Venhoek]

Dear TLS working group,

Given recent experiences by some parties of DDoS attacks that abuse
the TLS handshake to force a server into spending significant
computational resources (see Eirik Øverby's talk at
https://www.youtube.com/watch?v=pBNMWvfL05g for an example), we have
decided to give adding handshake DDoS protections another go. The
draft is available at
https://github.com/tweedegolf/draft-TLS-client-puzzles already and we
will be submitting it to the IETF datatracker shortly.

In the interest of giving this effort a better shot at success, we are
currently also working on implementing this proposal for a number of
major TLS implementations, including OpenSSL and BoringSSL. We already
have a near-complete implementation for RusTLS, and a working patched
version of Chromium. We will have these available as a demo during the
hackathon, where we will also be putting in some work to get more
implementations working (project TLS Client puzzles:
https://wiki.ietf.org/en/meeting/121/hackathon#tls-client-puzzles). If
you are in any way interested in this please come say hi.

Motivation for this work is that implementing this draft has, based on
preliminary measurements on nginx, the ability to provide at least a
4x increase in capacity to withstand attacks when using Ed25519
certificates (and a factor 10x for RSA certificates). Furthermore, the
draft is written to allow for a custom TLS implementation that can
handle the generation and checking of puzzles in a different security
domain. So it is possible to create a third party service that parties
can use to mitigate DDoS attacks without having to provide that third
party with full unencrypted access to all traffic.

This last point is also why we feel it is important to pursue this
work. Although right now it is possible to mitigate DDoS attacks by
paying a large cloud provider to handle TLS termination, this requires
the cloud provider to handle the unencrypted data. From a privacy
perspective, this is not always desirable, and in some industries
(such as finance and perhaps healthcare) might not even be allowed
because of compliance rules.

Our aim is not to make these attacks entirely impossible, but rather
to allow the defender to raise the cost for the attacker. Especially
financially motivated attacks can be significantly deterred by this.
This is also what motivates us to use hash functions like SHA2,
prioritizing a low cost for the server to check puzzles rather than
maximizing difficulty for attackers. This ease of checking together
with the ability to offload the server side of handling the puzzles
should avoid the problem of the puzzles themselves becoming an attack
vector.

Kind regards,
David Venhoek
Wouter Bokslag
Marc Schoolderman

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06

[Arnaud Taddei]

Good for me

Arnaud Taddei
Global Security Strategist | Enterprise Security Group

mobile: +41 79 506 1129 
Geneva, Switzerland
arnaud.tad...@broadcom.com  | broadcom.com

> On 30 Oct 2024, at 22:18, Ben Schwartz  
> wrote:
> 
> Hi Ben,
> 
> I've proposed a text change to strengthen the warning in that paragraph: 
> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/20 
> 
> 
> --Ben Schwartz
> From: Benjamin Kaduk 
> Sent: Monday, October 28, 2024 6:26 PM
> To: Ben Schwartz 
> Cc: Lucas Pardue ; 
> draft-ietf-tls-svcb-ech@ietf.org ; 
> tls@ietf.org 
> Subject: Re: [TLS] Re: Genart last call review of draft-ietf-tls-svcb-ech-06
>  
> 
> 
> On Mon, Oct 28, 2024 at 09:37:27PM +, Ben Schwartz wrote:
> >This Message Is From an External Sender
> >This message came from outside your organization.
> > 
> >On ALPNs - Yes, this is something of an open question.  There are some
> >hints about this in draft-ietf-tls-esni, e.g. Section 10.5: "A client 
> > that
> >treats this context as sensitive SHOULD NOT send context-specific values
> >in ClientHelloOuter.".
> >I've occasionally wondered if we would define an ECHConfig extension that
> >indicates a recommended "wire image" for the outer ClientHello, to
> >mask differences between clients, but we don't have anything like that
> >yet.
> >Interaction with QUIC version is also a fun question, and goes to the 
> > ALPN
> >vs. transport distinction.  This is also as-yet-undetermined, but might
> >involve a new SVCB parameter for supported QUIC versions, and/or perhaps
> >some notion of "compatible" and "incompatible" QUIC versions.
> >On 1/K anonymity - The upshot of this is "large K is better", i.e. "ECH
> >helps more if your service shares hosting with lots of other services
> >whose access patterns are similar.".  But that's a decision that must be
> >weighed against many other factors, from consolidation pressure to
> >infrastructure budget, so it seemed best to just mention the math and let
> >the operator choose as they will.
> 
> I agree that there's going to be a tradeoff between larger K's privacy 
> benefit and other considerations, but it seems to me that even the framing as 
> "1/K" is misleading.
> When the sites behind a given fronting service are of differingi popularity, 
> the attacker can do better than 1/K at guessing.  If I'm fronting for a site 
> that gets 900k hits/day and ten that get 10 hits/day, the attacker can just 
> guess that all requests are for the popular site and they'll get the right 
> answer 99.9% of the time.  I do see the disclaimer about "idealized 
> deployment" at the start of the paragraph but I think we could do more to 
> highlight just how idealized this portrayal is.
> 
> -Ben
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org