Re: Idea: DoS prevention by proof-of-work in Initial packet

[Erik Nygren <[e-mail]>]

If you're looking for something stronger to also protect the TLS handshake,
we also had this draft a few years back that leveraged some TLS 1.3 features
and might either be adaptable to QUIC or "just work":

  https://datatracker.ietf.org/doc/html/draft-nygren-tls-client-puzzles-02

There was insufficient interest in it at the time, and that was even
when RSA signings were dominant.  Now with ECDSA key signings
being widely supported it's unclear how much it is needed vs
just a Retry approach.

     Erik



On Fri, Sep 2, 2022 at 2:59 AM libor.peltan <libor.peltan=
[e-mail]> wrote:

> Hi all,
>
> I'm developing DNS-over-QUIC implementation in authoritative Knot DNS.
> I'm highly concerned about DoS resistance. According to our findings so
> far, the situation around authoritative DNS-over-QUIC (ADoQ) is following:
>
>   - The server can try to defend by requiring Retry packet, which
> prevents source address spoofing and too simple Initial packet floods,
> but also cripples legitimate connections by an additional RTT for the
> whole duration of attack (possibly all the time).
>
>   - A determined attacker can simply proceed with complete connections,
> including Retry packets. We have developed even the tools to perform
> such attacks.
>
>   - Opposed to plain DNS, the bottleneck is no longer any connection
> bandwidth. When both sides encrypt and decrypt all the packets, what
> matters is the CPU power.
>
>   - QUIC protocol seems to be balanced in the way that it gives no
> advantage to client or server side. If (and only if) the attacker has
> more CPU power available, it's able to exhaust the server computing
> resources, leading to DoS.
>
> I must admit I'm a "DNS guy" and I might have imperfect insight in QUIC
> nuances. Is there any tactic that would help defend the server against
> DoS? I always think that HTTP-over-QUIC servers must face the same
> issues. But it's also possible that they just rely on CDNs and stuff,
> which is not really appliable on common authoritative DNS.
>
> I looked also at Retry packet offload, but this does not make much sense
> for ADoQ.
>
> Thank you for any replies, suggestions and ideas!
>
> Libor
>
>
>