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

Eric Rescorla <ekr@rtfm.com> Sun, 04 October 2020 02:58 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 D469C3A0AC5 for <saag@ietfa.amsl.com>; Sat, 3 Oct 2020 19:58:54 -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 XQkQotkICCAA for <saag@ietfa.amsl.com>; Sat, 3 Oct 2020 19:58:53 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 029DC3A08CA for <saag@ietf.org>; Sat, 3 Oct 2020 19:58:53 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id h6so54954lfj.3 for <saag@ietf.org>; Sat, 03 Oct 2020 19:58:52 -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=UCJdATqffL8JrMPvCdPIm8JY8At2rd238OvMNniPlWQ=; b=niGZiDn1zHsYuxAkCHrIURJswDqtsejogl9kD8TG+ijcB0wDVKHXgCMs/QrrfVvs/n bolhfMTPFc7PbV4WdlwZaRRVt+hOPi1Rc/tV0rJkazPkGOKTtiIaHJf7NhSDrOoXJS1L dtuN6KF9lY5csNo13+IqasRAb4L1346vt7VKuwQ5RmckptnbRcFA+YfcITIPS8JC88tc IYa7/tN4oF5ErXisB35IRYlBjdz1Nu8hesuazks4quKj91VBtpmvLNMLBtovh1HFcoLB YSqc6mAGZ73FOxeIIG8JsK0CxHSHyc4nmyYSh9LIU4rv4fTCwICEkAgk8EicgFezEw9a b+1Q==
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=UCJdATqffL8JrMPvCdPIm8JY8At2rd238OvMNniPlWQ=; b=K/8AIMvXWo9YEQqoXyApyBo2bk2TCN+umrBb48ZWfdzec8RcOELe1ZoUvRr9dt+D5r qI1J9uxEdcNT0380/7Jsyl0vWMMnq8OxNOQegCM8oe2Vr3OOZXZu9ff3zkM8wmTa99ls ci72ZVmgxXgmLsudFykkYDsdOF7W7yXL777ZwgNY2QyOUKSIOtajQ90iL6rVTwsagN3x gBrkeqRceZe2gqAQYsTi7PtD0VhR9y7omDvBj8f6oio1nJHPz6ORx3O+s07utJulrJ3C rgjUItuR+BKETUZSxIqJQ0oOQbtSqO3g7o0yREotD7uZb0BC9fj/DtxPDkhIADHzWNcR 8ing==
X-Gm-Message-State: AOAM533A8Mke3mz7y0rRVD9KnvJ1k9rGFkVefTAH/N3ax1Ap4v7w708E pzsjWk+sbylqdEcBYFMRAgHoaL+0nREIQz37WyiClVb4fMxL7g==
X-Google-Smtp-Source: ABdhPJw0vfJrRck6bTEcLyZnoT5J0gIkBvo+kV10y0jDvskWVrUFcQKFEJAhA443fzPWF0sFlTDegbRTDYzZcrUA6c4=
X-Received: by 2002:a19:dd5:: with SMTP id 204mr3134306lfn.579.1601780331126; Sat, 03 Oct 2020 19:58:51 -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>
In-Reply-To: <6be61826-6467-ba49-c88e-c20e717a3b41@lounge.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 3 Oct 2020 19:58:15 -0700
Message-ID: <CABcZeBO3sZTVL002FzHnpuqpAxe45_3JBZPRYRFScML8JCDUqg@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: Fernando Gont <fernando@gont.com.ar>, Michael Richardson <mcr+ietf@sandelman.ca>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a5338b05b0cf8ba9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/N08S-C1LiV1swopF8EHVFIGjn74>
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 02:58:55 -0000

On Sat, Oct 3, 2020 at 6:14 PM Dan Harkins <dharkins@lounge.org> wrote:

>
> On 10/2/20 7:03 AM, Eric Rescorla wrote:
> [snip]
> >
> > For capabilities, our basic assumption is what is often called a
> > Dolev-Yao attacker, in which the attacker has complete control of the
> > channel (this is what 3552 describes as the Internet Threat model
> > [0]). However, it's also useful to try to consider more limited
> > attackers such as those who can only read from the wire and those who
> > cannot remove packets.
>    Why? If we want to develop protocols that are secure in the presence of
> a powerful attacker who has complete control of the medium what value
> is there in considering a "more limited attacker"?
>

>    It sounds like you're making a distinction between a passive attacker
> and an active attacker. Which is fine but what use do you see in a protocol
> that is secure against this "limited attacker" but not against the more
> powerful attacker?
>

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.

-Ekr