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

Eric Rescorla <ekr@rtfm.com> Fri, 02 October 2020 14:03 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 682453A1637 for <saag@ietfa.amsl.com>; Fri, 2 Oct 2020 07:03:55 -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 Iw70lLTVn9CM for <saag@ietfa.amsl.com>; Fri, 2 Oct 2020 07:03:53 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 E12353A163A for <saag@ietf.org>; Fri, 2 Oct 2020 07:03:52 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id z19so2009284lfr.4 for <saag@ietf.org>; Fri, 02 Oct 2020 07:03: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=9/5/jsJKD0Xz0XVfDUWlXSJX60PhRSXSkFvj1q+4c84=; b=csuMcqXuNdz5rFkn6ASkRzN+nAzMHWZV2qSblfNtvgk7mu4vxVS2rI8cEsYw+crjZF 2wvpNKQ1x94WrcD4jyDVmM8Ysx3/DdJV92YjvqNc0RoqEnHWR2uz0bxRUVUqQjmNgDY6 amkvSNBofqcCasqSG+hGWZwqsJJLPg/V+3ycUO/2iBHZ7zvfDN3PCmLkKytKVRCsS3A+ Fsf59VVYfqUri7ImkUcOvUB1Epkzy8+4bEa+E2lIRHuRpWNhwOgBeaHkDZJhCq0LRQz5 jfZV/GWcWRcILEfm4x/S8n0PXKbyNDvcn3GUiIm74VHl9iImPHAoEtov6EVzplQnV6i6 6F8A==
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=9/5/jsJKD0Xz0XVfDUWlXSJX60PhRSXSkFvj1q+4c84=; b=DxK6nStE8hE+WKFLbdgnheqrQx2aVVkdHTMAhAp6q2WJsSqcvVPmIzkYBk41aoUvx1 XUwVKhQDDp2ek5A3NkCGk6oNMokeYsZ2GgHposnmku+X/cS6798jPZ/I7caPox7F80D4 PTq4oQLBtLkbqlFPC5X3RCnsL6UMxd6ZejTeTkegiE0yd52j0mGyDJ0h/baGl8yUmeeK LBb+p3nPqyZpAn6D05lb4QIXwVeWbH68h31jWXmGFpuCdgNLg2M3hbdBz4k4DqeguZ3M zvSjbCivMeIngi0uu6DnyiYz2PLhPoIy8W6oUPo294+sS8th1YnbX6bO6mkqXv1LluZR 6q6Q==
X-Gm-Message-State: AOAM530bx0Rr5oi/5pLsEFHOz9kf78qPm6fdPu3tKY3aRxmjP78KaY6n Pak1YRy/N00vfNhYzClrpqjgQyn80aYJwdpSMXFHJg==
X-Google-Smtp-Source: ABdhPJzg5hHzSyxEtOTNEvYOQSbe+plpi+TLuWFGMAGyEUmSLYyFAoIHR1mxX3zCJFGXstar7LLjD1yhIh/NdhH1Df8=
X-Received: by 2002:ac2:4e92:: with SMTP id o18mr925509lfr.543.1601647431036; Fri, 02 Oct 2020 07:03:51 -0700 (PDT)
MIME-Version: 1.0
References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar>
In-Reply-To: <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 2 Oct 2020 07:03:14 -0700
Message-ID: <CABcZeBNuBhu8KUoZJsY3VR8LzDa78_n53rRZ-5nMrpCbqh_6KQ@mail.gmail.com>
To: Fernando Gont <fernando@gont.com.ar>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ec57805b0b09ab3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/_M9XDgWyLg-Mi2XSsVtjudQTDX0>
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: Fri, 02 Oct 2020 14:03:55 -0000

As I think this discussion reveals, we don't have a really precise
description of MITM, in part because it's quite an old term from an
era where we had much less ability to analyze security protocols than
we do today. One result of improvements in analysis is the need for
precise definitions so that we can formalize the guarantees of systems
against those definitions. This process is rather further along in in
cryptography where there are very precise definitions for both the
assumptions that our primitives depend on (RO, CDH, etc.) and the
security guarantees they provide (IND-CCA2, etc.), but it is happening
in communications security as well.

In general, we need terms for both attacker capabilities and attacks.

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. To my knowledge, we don't have a consensus set
of precise definitions for these yet, though both 3552 and QUIC [1]
make a stab at this). Similarly, some attacks are well-defined
(reflection, identity misbinding, KCI, impersonation etc.) and some are
not.

This brings us to MITM which is often used both for a set of
capabilities (usually roughly a Dolev-Yao attacker) and for a class of
active attacks including straight up impersonation to various kinds of
relay attacks). This broad a scope of usage isn't that useful and
rather than trying to give it a precise definition, it's probably time
to retire the term and replace it with a set of terms (perhaps
including some new terms) that do have precise definitions.

-Ekr


[0] https://tools.ietf.org/html/rfc3552#section-3
[1]
https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-31#section-21.13.3



On Thu, Oct 1, 2020 at 8:01 PM Fernando Gont <fernando@gont.com.ar> wrote:

> On 2/9/20 13:27, Michael Richardson wrote:
> [...]
> >
> > A firewall or router is a potential on-path attacker, but it can also
> drop packets.
> > What do we call this?
> > This was historically called a MITM, and it implied all the attributes of
> > on-path.  But it is unclear to me if MITM > on-path, or MITM == on-path.
>
> FWIW, I'd call this "man in the middle", and I'd say MITM > on-path.
>
> MITM implies the attacker receives the packets, and then it's up to the
> attacker to just inspect and pass on, or inspect & drop, or simply drop.
>
> Thanks,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>