Re: [saag] can an on-path attacker drop traffic?

Eric Rescorla <ekr@rtfm.com> Sun, 04 October 2020 23:48 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074153A0A9D for <saag@ietfa.amsl.com>; Sun, 4 Oct 2020 16:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8sup8knVqg5 for <saag@ietfa.amsl.com>; Sun, 4 Oct 2020 16:48:36 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE243A09A4 for <saag@ietf.org>; Sun, 4 Oct 2020 16:48:35 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id a22so5768794ljp.13 for <saag@ietf.org>; Sun, 04 Oct 2020 16:48:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oXTZx/WreLK1uhFk568mLBT0yNn3anPsW816Wq52iD8=; b=i6Pz71AJp1ipwTiwGpXGxzXlAbDnnSlJknSMhOj+tDkuui+5/Klzfn2F7MngX6bIeo Naz6sxqkILQ5/AkxOKx8emCeAIuYAB4Np1tPAMH9bMVzvlIu1FCGk0uBUPiBIqH/yx8c rATTQnsUC9n0RZjrN95EZlxmw7WnccDuKjki+hOA+XfBDA6U/YccgZzEyaM2ZAmlFfYw EIO6tsW5Qck0sLuLl8eqy1YwkItg6w2AuZlixQDX0VNZMeuJVYc2ttlZBF3sxkmNEANu GWoA0t08iKcr0G6YqSBuNpPycRWEPkt0fcu+sz13xv9mEFEqrFWCC9/uX03KmU2qoEJu Fjdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oXTZx/WreLK1uhFk568mLBT0yNn3anPsW816Wq52iD8=; b=HhXLJDOh4wpLSdvvnGY6kPlsRfz/VR4eHcn8qO8Mn5OCX+GI6a3ABKycv5SPsdoPn8 qi6m6douSuExZBlcelEuVcz1Mgs6vFtPrkVZNGf1SqIMQfQEN7xOOqU7cNCO4rU5PZkS ZxOdXaMRCz5YROs93Evqhozjfwifn4sezkkcY3N+teDEL7htlxIeTDaSSSwpEhcqw7nu RYRrpW2Mv8nebjyPtPM/TjCjAel/lLF9QDqOD0cIqHzrOBsmbewcqLJ83nwPDguc4PLJ cPiEcLQ+t0HMEuKNFbZHCBLlXQyczs4OmHMoPgrqUEn/3QS9Y3QFP5hLpeYke4MoAWKx 3a7g==
X-Gm-Message-State: AOAM531pGVsWqYkVyMzASuK+EDjTWPLD7rNciEaVal5hklzYSJIqudIG +S7hed/aSJi8Ybzjj9oRWZr5xXStKZAChysB6N8jDg==
X-Google-Smtp-Source: ABdhPJzltRrXQZ+caMqLVEUTa0niTLY+M70W3nHmrWu1Ix7RBD5AigpVsqvKvKXPv11iptEfhhg7HnDhgtFLlDeh/Eo=
X-Received: by 2002:a2e:9849:: with SMTP id e9mr3287770ljj.184.1601855313875; Sun, 04 Oct 2020 16:48:33 -0700 (PDT)
MIME-Version: 1.0
References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <CABcZeBNuBhu8KUoZJsY3VR8LzDa78_n53rRZ-5nMrpCbqh_6KQ@mail.gmail.com> <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org> <CABcZeBO3sZTVL002FzHnpuqpAxe45_3JBZPRYRFScML8JCDUqg@mail.gmail.com> <20201004221715.GB3100@localhost>
In-Reply-To: <20201004221715.GB3100@localhost>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 4 Oct 2020 16:47:57 -0700
Message-ID: <CABcZeBMNT_gqc2aBCgH5XmcXb9LTjjT7Yf8rsYPqRDRNrLrgHQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Dan Harkins <dharkins@lounge.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Fernando Gont <fernando@gont.com.ar>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f72c3305b0e1007c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/NZ_ZKLFQ4AgGtGv2DzoF4XGNcQU>
Subject: Re: [saag] can an on-path attacker drop traffic?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2020 23:48:38 -0000

On Sun, Oct 4, 2020 at 3:17 PM Nico Williams <nico@cryptonector.com> wrote:

> On Sat, Oct 03, 2020 at 07:58:15PM -0700, Eric Rescorla wrote:
> > IMO the primary reason is that (!) there are some attacks which we do not
> > presently know how to defend against in the case of a Dolev-Yao attacker,
> > but which we can defend against a weaker attacker and (2) weaker
> attackers
> > exist.
> >
> > As a concrete example, it is possible for such an attacker to terminate
> > even connections which are cryptographically protected (e.g., QUIC) by
> > simply refusing to carry any packet, so in this respect, QUIC and TCP are
> > similar. However a weaker attacker (e.g., an off-path attacker) can
> > terminate TCP connections by forging RSTs, which does not work against
> QUIC
> > because the connection termination signals are cryptographically
> protected.
> > I believe this is of some security value -- though perhaps you don't
> agree,
> > but we can only properly analyze it by considering a range of attacker
> > capabilities.
>
> This is a DoS attack.  It is true that many DoS attacks cannot be
> defeated cryptographically.  For example, a physical cable cut cannot be
> protected against with crypto.  What kinds of active attacks other than
> DoS attacks cannot be defended against?
>

I'm not sure that I would characterize connection termination as DoS
(arguably, this is another case of terminological imprecision). For
instance, sometimes it's a piece of another attack, such as in ABP+13 [0]
or BDF+14 [1].

In any case, another example of an attack that is difficult to defend
against cryptographically is IP address spoofing attacks. For instance, an
on-path attacker can force QUIC migration (how useful this is is not clear)
but an off-path attacker cannot and an on-path attacker who cannot delete
packets is supposed to be able to cause a hiccup but not permanent
migration.

Finally, another example of a limited threat model is one in which the
attacker has Dolev-Yao access to only some set of network segments. This is
often used in the analysis of anonymity protocols like Tor. While it is
believed to be possible to build low latency protocols which provide
anonymity under this threat model, AFAIK it is not known how to do so
efficiently.

-Ekr

[0] http://www.isg.rhul.ac.uk/tls/RC4biases.pdf
[1] https://www.mitls.org/pages/attacks/3SHAKE