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, 02 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 >
- [saag] can an on-path attacker drop traffic? Michael Richardson
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Christian Huitema
- Re: [saag] can an on-path attacker drop traffic? Behcet Sarikaya
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Nico Williams
- Re: [saag] can an on-path attacker drop traffic? Carsten Bormann
- Re: [saag] can an on-path attacker drop traffic? Dan Harkins
- Re: [saag] can an on-path attacker drop traffic? Carsten Bormann
- Re: [saag] can an on-path attacker drop traffic? Fernando Gont
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Dan Harkins
- Re: [saag] can an on-path attacker drop traffic? Michael Richardson
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Peter Gutmann
- Re: [saag] can an on-path attacker drop traffic? Christian Huitema
- Re: [saag] can an on-path attacker drop traffic? Dan Harkins
- Re: [saag] can an on-path attacker drop traffic? Paul Hoffman
- Re: [saag] can an on-path attacker drop traffic? Carsten Bormann
- Re: [saag] can an on-path attacker drop traffic? Alan DeKok
- Re: [saag] can an on-path attacker drop traffic? Dan Harkins
- Re: [saag] can an on-path attacker drop traffic? Michael Richardson
- Re: [saag] can an on-path attacker drop traffic? Nico Williams
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Eric Rescorla
- Re: [saag] can an on-path attacker drop traffic? Michael Richardson