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

Eric Rescorla <ekr@rtfm.com> Sun, 04 October 2020 23:56 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 76F6A3A0AA4 for <saag@ietfa.amsl.com>; Sun, 4 Oct 2020 16:56:25 -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 o0pJELHWA7sB for <saag@ietfa.amsl.com>; Sun, 4 Oct 2020 16:56:23 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 44E823A0AA3 for <saag@ietf.org>; Sun, 4 Oct 2020 16:56:23 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id y11so8725453lfl.5 for <saag@ietf.org>; Sun, 04 Oct 2020 16:56:23 -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=4h/IDnyWq9R+YsXmYXGp2Z5NZBqrgsQcLPdv2rUENnE=; b=uLiBneo9IBOAetZSVuzOR2shN6PDdnVj/g8mbfe6FYkz8hHp3yqfYC2p/eVcS/uefi dPhWZmBQWqg77ypKMM3iHx/BBCETab130efJE9r0ej9EpvH0SP6ZD9oKljIU+qxu1dfU gkJf34YmpxPqnwhntXw3IZGDsiofKtbO6B4QLflmq6vGS28nS+OKwG1lT6056VCdUwGX JokLNXm4kqGA3r2z8qDLuiiQgkxhRoV9jv0Z+UX9K0GWTOU/U42wfzn0GDVMV6c9OjTa QPllP/6/TcsSEsCjgiX3N/HNlpvjY6Mrbuc388aJcrJqpDvnVbOostFmd3FKIKvgIRjI /Zuw==
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=4h/IDnyWq9R+YsXmYXGp2Z5NZBqrgsQcLPdv2rUENnE=; b=knb3LJHsZHv6A3EE5/2QLnQFibh5m8JGKLzTH1c+RQ7NnD9jSJFxNozZqU5z7j+uZQ fvy+FiQEhAT7fDwCFTMIYxmdJPqQmR/fJ2+yeyaYx9OnBgIC42lxQCUPhuv/pFZyc2Cf 1M70BBwJq5s1aDfwu8zyh8Fp4zfpw7p2lJnM7XKbGyZUTEUBcjysYXlmTYh9713w9qrd uFVljdfphpUAFWlLzlx+9lMGMqSdY+EfJIxwYajTglQk33hBgnVgEbpajSQ+6j16ptmP O9sU+VODqVeNNngAmdlwtPTTcQcWYD/oA56SHC+9z+6/zp72UOsfc1EN7aIePCBzf9LD Y28g==
X-Gm-Message-State: AOAM530JMciTT+iYrs0KBepWhboFLMS0Vd86mQvpvXcUodkZlujpBDQz 0f/0AHPqgxnCpGmwlpi0pRx+g4kpUbnzk479ZEtxkQ==
X-Google-Smtp-Source: ABdhPJyTFDkhIz14JgcUZTt/dDshe9wDlMxjHSz144T8D/Ik88vZIg7YeSbsWzMrUgjS5bdVQz0ApTMlzWhQHAeyf0Y=
X-Received: by 2002:a19:5e15:: with SMTP id s21mr91944lfb.579.1601855781355; Sun, 04 Oct 2020 16:56:21 -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> <CABcZeBMNT_gqc2aBCgH5XmcXb9LTjjT7Yf8rsYPqRDRNrLrgHQ@mail.gmail.com>
In-Reply-To: <CABcZeBMNT_gqc2aBCgH5XmcXb9LTjjT7Yf8rsYPqRDRNrLrgHQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 04 Oct 2020 16:55:45 -0700
Message-ID: <CABcZeBN7XH4EmGTFxR7exKSB=ts4aS4Td03hGTVu2o+bdpvzfg@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="000000000000d45b7405b0e11c7b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/d3EsauBBK87VVXdMNhvfSQIJHzU>
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:56:25 -0000

On Sun, Oct 4, 2020 at 4:47 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> 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.
>

Correcting my bad writing here: "While it is believed to be possible to
build anonymity protocols under the stronger 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

>