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

Carsten Bormann <cabo@tzi.org> Tue, 01 September 2020 16:40 UTC

Return-Path: <cabo@tzi.org>
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 570A53A0975; Tue, 1 Sep 2020 09:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fyTa-SDCiwDe; Tue, 1 Sep 2020 09:40:47 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740C63A0965; Tue, 1 Sep 2020 09:40:47 -0700 (PDT)
Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Bgt9T3qp7zybs; Tue, 1 Sep 2020 18:40:45 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com>
Date: Tue, 01 Sep 2020 18:40:45 +0200
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>
X-Mao-Original-Outgoing-Id: 620671244.99362-9a273ba2c1ae6c67fd70db5b205b4498
Content-Transfer-Encoding: quoted-printable
Message-Id: <9854F0F8-A512-44DB-910C-3864106C9708@tzi.org>
References: <CALaySJJt_U+qF_xwOtJC2BD=oet-stNxoJkMYJfH=Z8BmcLc3g@mail.gmail.com> <1E09C83D-0AC1-42CA-9E2D-E5903FF775D6@ericsson.com>
To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/C_rymDvG5naWbCQqi8dFrU2Q4DY>
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: Tue, 01 Sep 2020 16:40:50 -0000

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://github.com/ietf/terminology is even more broken: An impersonation attacker doesn’t even have to be on-path.

(See also my comment on https://github.com/ietf/terminology/pull/1, 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