Re: [core] AD review of draft-ietf-core-echo-request-tag-10

Barry Leiba <barryleiba@computer.org> Wed, 02 September 2020 12:56 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4A3A0C9C; Wed, 2 Sep 2020 05:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 nNLV8mn3PE0r; Wed, 2 Sep 2020 05:56:40 -0700 (PDT)
Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (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 A33C83A0C9B; Wed, 2 Sep 2020 05:56:40 -0700 (PDT)
Received: by mail-il1-f169.google.com with SMTP id w3so4852367ilh.5; Wed, 02 Sep 2020 05:56:40 -0700 (PDT)
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:content-transfer-encoding; bh=SimXlO7t7809u+EDO+BGdjtLRtdqVgtuES2IBeZR+Ns=; b=RN6gkEkoATQQgJa+l8C8f1XW0mGrbjwJ2QIyjn+ogGWh+h6K42XbGP7GdpWxxHrcr5 IqezvKgD7TuznAm2OWSWZLuxV1JVLmXaCZNWbeuF4g6QQKqiw2UDPkJEDEXA0+0OHutx LvKpuMKB5buvb8R3ZUYh3CnsfiiwBdwcDeQFOM8qgxE9vaYZs9/QT4Ux/L4AE1QMOBkh piAetcrgGJFwkJyoxkgWxw2bygrjSbjTCrbeFUtEAONaW7dKvSx6hueKJkGjpYh6kOrU C/7Hk6EUWdUiVRFEkbl1hn/Q3Kr3K3lhvyiVG+kDigAwtCBWf9hLMIGjUxy7oOlSlWZB qfcg==
X-Gm-Message-State: AOAM531ClNXUlLPUkwkOkAmA2x6F1FePbavc7EzxxDBR01AK9rs6bOfu 6PWO0UbBKhgsXS+vtypScnbVckajKLHzWPo2nhA=
X-Google-Smtp-Source: ABdhPJwSpeji4S2EJia9Ve3dOEn0eApAFVpM2ZVDOEg84U9767S6XOioZ34JYSTABCzMrht+WNETc64KVwrtjA2Cz0w=
X-Received: by 2002:a92:dc03:: with SMTP id t3mr3301438iln.59.1599051399568; Wed, 02 Sep 2020 05:56:39 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJJt_U+qF_xwOtJC2BD=oet-stNxoJkMYJfH=Z8BmcLc3g@mail.gmail.com> <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com> <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org> <3216C47B-D9A9-4EAD-B68F-D2FAB7E0376B@ericsson.com> <CALaySJLU3-39SPDu9F-y3BUCJXYfKJQUeWhcDoFZF0RxcPh9ig@mail.gmail.com> <CF9FD971-16E5-42DD-B443-1D1A4B6A04EE@ericsson.com>
In-Reply-To: <CF9FD971-16E5-42DD-B443-1D1A4B6A04EE@ericsson.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 02 Sep 2020 08:56:28 -0400
Message-ID: <CALaySJ+U3sFzdhp1DUZQ1ynGu6quVqKptQcAckYB=ZJ1GopZ0g@mail.gmail.com>
To: Göran Selander <goran.selander@ericsson.com>
Cc: John Mattsson <john.mattsson@ericsson.com>, Carsten Bormann <cabo@tzi.org>, "core@ietf.org" <core@ietf.org>, "draft-ietf-core-echo-request-tag.all@ietf.org" <draft-ietf-core-echo-request-tag.all@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/2P8o3OIt2vICi8TlGKJvIA94_7I>
Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2020 12:56:42 -0000

For what it's worth, I just reviewed a routing document that uses the
phrase "an attacker in the middle of the network", which is another
option.

Barry

On Wed, Sep 2, 2020 at 8:52 AM Göran Selander
<goran.selander@ericsson.com> wrote:
>
> Hi,
>
> As I understand "replace" and Carsten's provided definitions, an on-path attacker does not necessarily have that capability. But I agree with John's proposal and updated the github version accordingly. In the same way I also replaced the only use of "on-path attacker" in the draft with "attacker". The commit is here:
>
> https://github.com/core-wg/echo-request-tag/commit/29969c4
>
> Any other comments on the recent changes? We plan to submit a new version on Friday.
>
> Göran
>
>
> On 2020-09-01, 21:29, "Barry Leiba" <barryleiba@computer.org> wrote:
>
>     John has a good point here, and I support his proposal.
>
>     That said, remember: I did say that it's not a big deal and I'm
>     leaving it to y'all's best judgment.  All I wanted was for you to
>     consider the issue... not to rehash "fun" discussions from elsewhere.
>     And whichever way you choose isn't going to block this document.
>
>     Barry
>
>     On Tue, Sep 1, 2020 at 3:13 PM John Mattsson <john.mattsson@ericsson.com> wrote:
>     >
>     > In this sentence I think on-path attacker works quite well or even better. It already follows from the sentence that the attacker is able to replace one block with another. The attacker in this case does only needs to be able to reorder packets flowing in one direction of the communication.
>     >
>     > We could also just use the word attacker, e.g.
>     >
>     > "it is still possible for an attacker able to reorder packets on the path from client to server to maliciously replace a later operation's blocks with an earlier operation's blocks."
>     >
>     > Cheers,
>     > John
>     >
>     > -----Original Message-----
>     > From: Carsten Bormann <cabo@tzi.org>
>     > Date: Tuesday, 1 September 2020 at 18:40
>     > To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
>     > Cc: Barry Leiba <barryleiba@computer.org>, "draft-ietf-core-echo-request-tag.all@ietf.org" <draft-ietf-core-echo-request-tag.all@ietf.org>, "core@ietf.org" <core@ietf.org>
>     > Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10
>     > Resent from: <alias-bounces@ietf.org>
>     > Resent to: <christian@amsuess.com>, John Mattsson <john.mattsson@ericsson.com>, <goran.selander@ericsson.com>, <jaime@iki.fi>, <marco.tiloca@ri.se>, <barryleiba@gmail.com>, <superuser@gmail.com>, <barryleiba@computer.org>, Marco Tiloca <marco.tiloca@ri.se>
>     > Resent date: Tuesday, 1 September 2020 at 18:40
>     >
>     >     On 2020-09-01, at 16:19, Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org> wrote:
>     >     >
>     >     >
>     >     >    — Section 3.5.1 —
>     >     >
>     >     >       is still possible for a man-in-the-middle to maliciously replace a
>     >     >       later operation's blocks with an earlier operation's blocks
>     >     >
>     >     >    Not a requirement here, and I will accept your best judgment:  in the
>     >     >    spirit of recent discussion on inclusive vs exclusionary language, I ask
>     >     >    you to consider changing “a man-in-the-middle” to “an on-path attacker”.
>     >     >
>     >     > [GS] I thought there was a slight difference between "on-path attacker" and "man-in-the-middle”, in that the latter has access to the message flow whereas the former need not have. For example, an on-path attacker may only be able to inject messages. In this case ("replace") the latter would then be more precise. If I'm right then I propose we use available distinctions pending a new dictionary, otherwise I'm fine with changing.
>     >
>     >     Oh, so we are getting to have this fun discussion on *this* draft.
>     >
>     >     A MITM can read, inject, delete, and modify data.
>     >
>     >     An on-path attacker can read and inject, but not necessarily delete or modify data.
>     >
>     >     I would not use the latter as a synonym for the former.
>     >
>     >     The other proposal in https://protect2.fireeye.com/v1/url?k=8bc8ba21-d57827b9-8bc8faba-861fcb972bfc-afe20b2d89bbd667&q=1&e=406fbb72-b2f0-4844-bd11-3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology is even more broken: An impersonation attacker doesn’t even have to be on-path.
>     >
>     >     (See also my comment on https://protect2.fireeye.com/v1/url?k=a110182c-ffa085b4-a11058b7-861fcb972bfc-2890999e614b0870&q=1&e=406fbb72-b2f0-4844-bd11-3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology%2Fpull%2F1, which fell by the wayside in the recent lull on this topic.)
>     >
>     >     In the mid-2000s, there was an attempt to replace MITM attack by “middleperson attack”.  That utterly failed, a simple Google search says “man-in-the-middle” (54100 hits on dl.acm.org) is overwhelmingly still the term of art and not “middleperson” (31 hits on dl.acm.org).
>     >
>     >     Wikipedia at least knows about the other established word for MITM, Janus attack https://en.wikipedia.org/w/index.php?title=Janus_attack&redirect=no — not very successful either (9 hits on dl.acm.org).
>     >
>     >     One word that already has the right semantics and does not require the cultural background of “Janus attack” is “Interposer attack”.  0 hits on dl.acm.org, but has all the right properties.  So in the above we would replace MITM by “interposer”:
>     >
>     >     >       is still possible for an interposer to maliciously replace a
>     >     >       later operation's blocks with an earlier operation's blocks
>     >
>     >     WFM, even if this is blazing a new trail.
>     >
>     >     Grüße, Carsten
>     >
>     >
>     >
>     >
>