Subject: Re: [Potential Spoof] Re: [E] DoS-ing QUIC servers is too easy

From: Roberto Peon <[email-masked]>
Date: Tue, 23 Jul 2019 15:42:20 +0000

I think Mikkel is/was saying the same w.r.t. counters.
-=R

From: QUIC <[email-masked]> on behalf of Roberto Peon <[email-masked]>
Date: Tuesday, July 23, 2019 at 11:38 AM
To: "[email-masked]" <[email-masked]>, Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Watson Ladd <[email-masked]>, "[email-masked]" <[email-masked]>, "brent.bilger=[email-masked]" <brent.bilger=[email-masked]>, Ian Swett <ianswett=[email-masked]>
Subject: [Potential Spoof] Re: [E] DoS-ing QUIC servers is too easy

If you’re in a “small” deployment that is exposed to the internet, then you’re going to be dead regardless of the tokens because the links will be full of useless packets if someone decides to do an attack at any reasonable scale.

If you’re in a “large” deployment that is exposed to the internet, then a counter-based implementation that requires any state at servers (to verify the counter) is likely to be very expensive as it either requires an RPC for each incoming packet-to-be-authenticated, or it requires that the packet be routed to a specific server, which makes the individual servers DoSable.

If you have a “large” deployment and use a time-based implementation, then you have the goldilocks-like problem of choosing the correct TTL, and that is going to be difficult as the DoS effectiveness becomes directly (inversely) related to the TTL length as TTL length determines the amount of the population that is no longer authenticated. A short TTL means very little benefit can be ascribed by having the token because few clients will remain authenticated.

The combination of time and counter doesn’t negate any of the disadvantages of either.

I don’t ultimately see a way out of having to heuristically examine 5-tuples.
-=R

From: "[email-masked]" <[email-masked]>
Date: Tuesday, July 23, 2019 at 11:19 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Roberto Peon <[email-masked]>, "[email-masked]" <[email-masked]>, Watson Ladd <[email-masked]>, "[email-masked]" <[email-masked]>, "brent.bilger=[email-masked]" <brent.bilger=[email-masked]>, Ian Swett <ianswett=[email-masked]>
Subject: Re: [E] DoS-ing QUIC servers is too easy

On Jul 23, 2019, at 7:53 AM, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:

It is not that easy to steal a token and replay, but it can happen.

Yes, it requires compromising a client and stealing the key or just using the key from a back door. In practice the latter may be advantageous to the adversary because the source of the attack will be from a normal location and because future device authorizations may include a fingerprint of the device - a fingerprint that would fail on the stolen key. But look at what we’ve done to the unauthorized adversary with the pre-authentication token - defeated resource DoS, information leakage, all vulnerabilities of the server, all configuration errors of the applications of the server. And it augments TLS to defeat man-in-the-middle attacks.

If you add a time factor such an attack will have limited value. In fact a token need not be valid for more than about 10 minutes to account for skewed clocks.

As noted on a different posting, Single Packet Authorization is based on RFC 4226 which has both a counter and a time based approach. Personally, I prefer a counter.

But again, this is all irrelevant because I’m not suggesting any one pre-authentication. I’m just using an example to show how it can stop multiple types of attacks.

Brent

On 23 July 2019 at 16.41.09, Roberto Peon ([email-masked]<mailto:[email-masked]>) wrote:
I’d assume #1 is less likely to experience crippling SYN-based DoS attacks, and could otherwise be accomplished by limiting access in IP-space (imperfect, but we’re looking for “good-enough”, here).

.. which means that I think we should consider 2+3 only, really.

For #2 and #3, which I suspect have significant overlaps (sites may provide services both to logged-in users and users who aren’t logged in), the pre-authorization either:
  a) can be DoS’d itself.
  b) can be used to do a DoS in the future.
In case b, as an attacker, you’d get or wait for the client to authenticate, then use that authentication in a replay attack, e.g. by replicating the auth token across many hosts.
In cases where you are disallowed to replicate the auth token, e.g. because it is tied to a particular IP, you can help solve the replay attack however you’ll be biasing traffic to users whose IP is stable and who are logged in/auth’d.
In the pre-shared key scenario that was described, if any one client leaks the shared-secret, then it becomes not very useful and certainly doesn’t protect against a DoS. I’d guess that the probability of the loss of a symmetric key is proportional to the breadth of the distribution of the key.

What I’m trying to point out is that this doesn’t really seem to solve the generic DoS attack.
You’ll still need to do some heuristics/rules based upon whatever is observable, at a minimum the 5-tuple.
Getting more than the 5-tuple to be visible will take more work by the server, true, but given other design constraints, I don’t see how that is avoidable.

-=R

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 23, 2019 at 9:59 AM
To: Roberto Peon <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Watson Ladd <[email-masked]<mailto:[email-masked]>>, "brent.bilger=[email-masked]<mailto:[email-masked]>" <brent.bilger=[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>
Subject: Re: [E] DoS-ing QUIC servers is too easy

There are lots of possible scenarios, so please just consider these to be examples. Let’s divide the world of servers in to 1) enterprise business-to-business websites, 2) websites meant for consumers where authentication is desirable, and 3) websites that will want to allow their users to be anonymous, therefore, pre-authentication would not apply.

Enterprise business-to-business websites could use something similar to the Software Defined Perimeter (SDP) Single Packet Authorization (SPA) protocol created by the Cloud Security Alliance. It uses the fact that clients are on-boarded to the system in a one time event to provide the clients with a shared secret key. The key is used in a counter-based HMAC calculation. Since only an authorized client can calculate the proper HMAC, the HMAC can be used for pre-authentication. Thus, the pre-authentication token could look something like this:
Client->Server: ClientID, Counter, HMAC[ClientID || Counter, Ks] where Ks is a shared secret key that both the client and server have.
On the server side, the server would recalculate the HMAC and compare it to the one provided by the client.
Note that this information is sent from the client to the server in clear text (i.e., not encrypted).
In practice, there would probably be more fields, but the important part is that the one-time on boarding enables a lifetime of pre-authentication tokens.

Websites meant for consumers would probably be handled differently - specifically, no on-boarding. That means there would be some kind of token service - similar to OAuth, but operating prior to the TCP equivalent of SYN/ACK. Perhaps CloudFlair or Google or Microsoft could invent something like this and offer it as a service???

Again, there will be other websites that will not want pre-authentication because they want to allow anonymous users to their site.

Brent

On Jul 23, 2019, at 6:26 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:

I'm trying to understand how anything was pre-authenticated without suffering from all of the same problems.
How would such pre-authentication be done in practice, especially in scenarios where the server doesn't have a whitelist of clients, and that service desires traffic from non-malicious clients?
-=R
Get Outlook for Android<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_ghei36&d=DwMF-g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=W-O0t0zwhgXHP8ujph6uz3rH0MtuaLwEr_7gE2p1X5o&m=CV-HIhbRVp-argiNrVu_DK7rONk5xt9L5r0Efmw170I&s=WXhjQ5cGfCrw6BSXdq5jydKEbOF2Pu3tjL2QZWXz6eY&e=>

________________________________
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 23, 2019 8:21:05 AM
To: Watson Ladd <[email-masked]<mailto:[email-masked]>>
Cc: brent.bilger=[email-masked]<mailto:brent.bilger=[email-masked]> <brent.bilger=[email-masked]<mailto:brent.bilger=[email-masked]>>; Roberto Peon <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Ian Swett <ianswett=[email-masked]<mailto:ianswett=[email-masked]>>
Subject: Re: [E] DoS-ing QUIC servers is too easy

On Jul 22, 2019, at 9:16 PM, Watson Ladd <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jul 22, 2019 at 5:29 PM
<brent.bilger=[email-masked]<mailto:brent.bilger=[email-masked]>> wrote:

On Jul 22, 2019, at 10:10 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:

When you’re talking about pre-authentication, are you referring to the 0-rtt stuff?

0-RTT is good stuff. It reduces time for a device that’s already known to be authorized to connect to the server.

Part of the problem is to stop resource DoS. The other part is about information leakage.

Let’s assume a time when all website use QUIC and let's take an adversary who has just learned about a vulnerability in Wordpress. The adversary wants to scan the Internet finding Wordpress sites. Now, if the QUIC connection required pre-authentication, then the server would be black to the connection and the adversary could not determine if the site uses Wordpress. But, as it stands today, in this future time, the adversary scans the Internet, connects to the server, and is handed a Wordpress login screen. Now the adversary knows where to attack.

If connection requires preauthentication then no one can see the site, no?

In the enterprise it is a little different. Companies implement reverse proxies to try to protect servers from unauthorized users. But what if the servers required a pre-authentication token. Then, reverse proxies would not be needed.

So I think there are two different things here, or maybe I'm misunderstanding:
1: We have servers that have a limited number of clients that will
ever want to connect to them, and want to enable other devices to
filter the traffic, so need some mechanism that enables a middlebox to
filter.

No middle box! Pre-authentication makes servers self-defending. Lack of pre-authentication is why we have middle boxes.

2: We have servers generally available to the public and are concerned
that the QUIC version of a SYN flood can't be dealt with (despite
evidence to the contrary).

Companies and website owners have to pay for anti-DoS services from the likes of Verizon and others BECAUSE servers listen to all clients. With pre-authentication, the need to have an anti-DoS service would be greatly reduced because servers would not respond to unauthorized clients.

And the point about information leakage is important, too.

Brent

I don't know much about how Cloudflare (my place of employment)  deals
with 2 but hopefully some people who do/implementors can speak up
about how much of a problem it is. But 1 is I think very much a
nongoal: middlebox ossification is part of the reason we have QUIC.

Sincerely,
Watson Ladd

Brent Bliger
Director-Technology Verizon SDP
[email-masked]<mailto:[email-masked]>

Brent Bliger
Director-Technology Verizon SDP
[email-masked]<mailto:[email-masked]>

Brent Bliger
Director-Technology Verizon SDP
[email-masked]<mailto:[email-masked]>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 23 Jul 2019 08:46:29 -0700

Yes

On 23 July 2019 at 17.42.25, Roberto Peon ([email-masked]) wrote:

-=R

*From: *QUIC <[email-masked]> on behalf of Roberto Peon <[email-masked]
*Date: *Tuesday, July 23, 2019 at 11:38 AM
*To: *"[email-masked]" <[email-masked]>, Mikkel Fahnøe
Jørgensen <[email-masked]>
*Cc: *Watson Ladd <[email-masked]>, "[email-masked]" <[email-masked]>,
"brent.bilger=[email-masked]" <brent.bilger=
[email-masked]>, Ian Swett <ianswett=
[email-masked]>
*Subject: *[Potential Spoof] Re: [E] DoS-ing QUIC servers is too easy

If you’re in a “small” deployment that is exposed to the internet, then
you’re going to be dead regardless of the tokens because the links will be
full of useless packets if someone decides to do an attack at any
reasonable scale.

If you’re in a “large” deployment that is exposed to the internet, then a
counter-based implementation that requires any state at servers (to verify
the counter) is likely to be very expensive as it either requires an RPC
for each incoming packet-to-be-authenticated, or it requires that the
packet be routed to a specific server, which makes the individual servers
DoSable.

If you have a “large” deployment and use a time-based implementation, then
you have the goldilocks-like problem of choosing the correct TTL, and that
is going to be difficult as the DoS effectiveness becomes directly
(inversely) related to the TTL length as TTL length determines the amount
of the population that is no longer authenticated. A short TTL means very
little benefit can be ascribed by having the token because few clients will
remain authenticated.

The combination of time and counter doesn’t negate any of the disadvantages
of either.

I don’t ultimately see a way out of having to heuristically examine
5-tuples.
-=R

*From: *"[email-masked]" <[email-masked]>
*Date: *Tuesday, July 23, 2019 at 11:19 AM
*To: *Mikkel Fahnøe Jørgensen <[email-masked]>
*Cc: *Roberto Peon <[email-masked]>, "[email-masked]" <
[email-masked]>, Watson Ladd <[email-masked]>, "
[email-masked]" <[email-masked]>, "brent.bilger=[email-masked]"
<brent.bilger=[email-masked]>, Ian Swett <ianswett=
[email-masked]>
*Subject: *Re: [E] DoS-ing QUIC servers is too easy

On Jul 23, 2019, at 7:53 AM, Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

Yes, it requires compromising a client and stealing the key or just using
the key from a back door. In practice the latter may be advantageous to the
adversary because the source of the attack will be from a normal location
and because future device authorizations may include a fingerprint of the
device - a fingerprint that would fail on the stolen key. But look at what
we’ve done to the unauthorized adversary with the pre-authentication token
- defeated resource DoS, information leakage, all vulnerabilities of the
server, all configuration errors of the applications of the server. And it
augments TLS to defeat man-in-the-middle attacks.

If you add a time factor such an attack will have limited value. In fact a
token need not be valid for more than about 10 minutes to account for
skewed clocks.

As noted on a different posting, Single Packet Authorization is based on
RFC 4226 which has both a counter and a time based approach. Personally, I
prefer a counter.

But again, this is all irrelevant because I’m not suggesting any one
pre-authentication. I’m just using an example to show how it can stop
multiple types of attacks.

Brent

On 23 July 2019 at 16.41.09, Roberto Peon ([email-masked]) wrote:

I’d assume #1 is less likely to experience crippling SYN-based DoS attacks,
and could otherwise be accomplished by limiting access in IP-space
(imperfect, but we’re looking for “good-enough”, here).

For #2 and #3, which I suspect have significant overlaps (sites may provide
services both to logged-in users and users who aren’t logged in), the
pre-authorization either:
  a) can be DoS’d itself.
  b) can be used to do a DoS in the future.

In case b, as an attacker, you’d get or wait for the client to
authenticate, then use that authentication in a replay attack, e.g. by
replicating the auth token across many hosts.
In cases where you are disallowed to replicate the auth token, e.g. because
it is tied to a particular IP, you can help solve the replay attack however
you’ll be biasing traffic to users whose IP is stable and who are logged
in/auth’d.
In the pre-shared key scenario that was described, if any one client leaks
the shared-secret, then it becomes not very useful and certainly doesn’t
protect against a DoS. I’d guess that the probability of the loss of a
symmetric key is proportional to the breadth of the distribution of the key.

What I’m trying to point out is that this doesn’t really seem to solve the
generic DoS attack.
You’ll still need to do some heuristics/rules based upon whatever is
observable, at a minimum the 5-tuple.
Getting more than the 5-tuple to be visible will take more work by the
server, true, but given other design constraints, I don’t see how that is
avoidable.

-=R

*From: *"[email-masked]" <[email-masked]>
*Date: *Tuesday, July 23, 2019 at 9:59 AM
*To: *Roberto Peon <[email-masked]>
*Cc: *"[email-masked]" <[email-masked]>, Watson Ladd <
[email-masked]>, "brent.bilger=[email-masked]"
<brent.bilger=[email-masked]>, "[email-masked]" <[email-masked]>,
Ian Swett <ianswett=[email-masked]>
*Subject: *Re: [E] DoS-ing QUIC servers is too easy

There are lots of possible scenarios, so please just consider these to be
examples. Let’s divide the world of servers in to 1) enterprise
business-to-business websites, 2) websites meant for consumers where
authentication is desirable, and 3) websites that will want to allow their
users to be anonymous, therefore, pre-authentication would not apply.

Enterprise business-to-business websites could use something similar to the
Software Defined Perimeter (SDP) Single Packet Authorization (SPA) protocol
created by the Cloud Security Alliance. It uses the fact that clients are
on-boarded to the system in a one time event to provide the clients with a
shared secret key. The key is used in a counter-based HMAC calculation.
Since only an authorized client can calculate the proper HMAC, the HMAC can
be used for pre-authentication. Thus, the pre-authentication token could
look something like this:

Client->Server: ClientID, Counter, HMAC[ClientID || Counter, Ks] where Ks
is a shared secret key that both the client and server have.

On the server side, the server would recalculate the HMAC and compare it to
the one provided by the client.

Note that this information is sent from the client to the server in clear
text (i.e., not encrypted).

In practice, there would probably be more fields, but the important part is
that the one-time on boarding enables a lifetime of pre-authentication
tokens.

Websites meant for consumers would probably be handled differently -
specifically, no on-boarding. That means there would be some kind of token
service - similar to OAuth, but operating prior to the TCP equivalent of
SYN/ACK. Perhaps CloudFlair or Google or Microsoft could invent something
like this and offer it as a service???

Again, there will be other websites that will not want pre-authentication
because they want to allow anonymous users to their site.

Brent

On Jul 23, 2019, at 6:26 AM, Roberto Peon <[email-masked]> wrote:

I'm trying to understand how anything was pre-authenticated without
suffering from all of the same problems.

How would such pre-authentication be done in practice, especially in
scenarios where the server doesn't have a whitelist of clients, and that
service desires traffic from non-malicious clients?

-=R

Get Outlook for Android
<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_ghei36&d=DwMF-g&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=W-O0t0zwhgXHP8ujph6uz3rH0MtuaLwEr_7gE2p1X5o&m=CV-HIhbRVp-argiNrVu_DK7rONk5xt9L5r0Efmw170I&s=WXhjQ5cGfCrw6BSXdq5jydKEbOF2Pu3tjL2QZWXz6eY&e=>

------------------------------

*From:* [email-masked] <[email-masked]>
*Sent:* Tuesday, July 23, 2019 8:21:05 AM
*To:* Watson Ladd <[email-masked]>
*Cc:* brent.bilger=[email-masked] <
brent.bilger=[email-masked]>; Roberto Peon <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked] <
[email-masked]>; Ian Swett <ianswett=[email-masked]>
*Subject:* Re: [E] DoS-ing QUIC servers is too easy

On Jul 22, 2019, at 9:16 PM, Watson Ladd <[email-masked]> wrote:

On Mon, Jul 22, 2019 at 5:29 PM
<brent.bilger=[email-masked]> wrote:

On Jul 22, 2019, at 10:10 AM, Roberto Peon <[email-masked]> wrote:

When you’re talking about pre-authentication, are you referring to the
0-rtt stuff?

0-RTT is good stuff. It reduces time for a device that’s already known to
be authorized to connect to the server.

Part of the problem is to stop resource DoS. The other part is about
information leakage.

Let’s assume a time when all website use QUIC and let's take an adversary
who has just learned about a vulnerability in Wordpress. The adversary
wants to scan the Internet finding Wordpress sites. Now, if the QUIC
connection required pre-authentication, then the server would be black to
the connection and the adversary could not determine if the site uses
Wordpress. But, as it stands today, in this future time, the adversary
scans the Internet, connects to the server, and is handed a Wordpress login
screen. Now the adversary knows where to attack.

In the enterprise it is a little different. Companies implement reverse
proxies to try to protect servers from unauthorized users. But what if the
servers required a pre-authentication token. Then, reverse proxies would
not be needed.

So I think there are two different things here, or maybe I'm
misunderstanding:
1: We have servers that have a limited number of clients that will
ever want to connect to them, and want to enable other devices to
filter the traffic, so need some mechanism that enables a middlebox to
filter.

No middle box! Pre-authentication makes servers self-defending. Lack of
pre-authentication is why we have middle boxes.

Companies and website owners have to pay for anti-DoS services from the
likes of Verizon and others BECAUSE servers listen to all clients. With
pre-authentication, the need to have an anti-DoS service would be greatly
reduced because servers would not respond to unauthorized clients.

Brent

Sincerely,
Watson Ladd

Brent Bliger

[email-masked]

Brent Bliger

[email-masked]

Brent Bliger

[email-masked]