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

Göran Selander <goran.selander@ericsson.com> Wed, 02 September 2020 12:52 UTC

Return-Path: <goran.selander@ericsson.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 02DB03A0C6B; Wed, 2 Sep 2020 05:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 nkjYHKMd6d1W; Wed, 2 Sep 2020 05:52:06 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00043.outbound.protection.outlook.com [40.107.0.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A27A3A0C68; Wed, 2 Sep 2020 05:52:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CmFRxs/5a7RSKxPygc+HyrmywbuqcNqX7H5/iGD4CzOguPsPDZOdvumc0keRNpkS0VzPT39cceOG5ygtj7NHVU8T4sf58N0TG46iTFqKorxCSLKi0O99/764N16nhcEWvBJt/s39RfOEoNH7NbDhco+dn4NMwdbNxkWxlLsKD6xDj+w4BoPSD0XZ5OboOmsPxgpwmz/fKRDwa2AZjXWnhorzhl5q9l984TC4N/cGWw8+fJOls7dH30eH2RBfIn80BJ/grdBaGDNUTGe+29m1UdYXXeFixJMf26AX88s5HVMTDT2JkSTMM349cW6XfCZgHfBksxs21oKubEdgkltbvA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vksudDmPSYVQI+yc1dsFCf8hxpfoCkB2sjZzbieexp4=; b=jKDHKg/dCr2jLbhvC/fkA0oQeSgBOjN7u0Rb9ksBLrefqZYeWvvfUF2+bD3mExZf+X7389J1Ii19yQMcji/24LcIpU8b95ApjAW/Vdy5DNspjk7EQFuSgJ2Biv6zwZFtXH46DX5QBlTbbX/lunj+8rZfUyrG8P07AhUGfsS0SeCu9Bf5pg9buAd1RMSW6xWBQxvoSSVgkKxEzy26KmUXj0/QZa0vBEirn63uI+qBV655J4llrjxtyAVMRredFBZgBSWc2MAeYz7FOM0nWCC3033wmRg5/cdq2lq+WJmyFBu4J1ARppFvW3J9JqpCMO+K8n2nCGXfuXO8H8ed+fJI/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vksudDmPSYVQI+yc1dsFCf8hxpfoCkB2sjZzbieexp4=; b=B1hMYsuaA/Fko14dfgTiOPKc4rsCZXmAnP/iIL5FbgTaJEn0uAq2B0ME8BGyQlGRlhR/NCEaDASfQGhY1YXmXvtFOf4xaluueDQ8qMaI8Mf8C4IwwM4MbK86KsrSgwqJgFeULipdkUOErrseMLS50nmO5QC9h0iZJQswxuf2Gsg=
Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR07MB3068.eurprd07.prod.outlook.com (2603:10a6:7:32::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Wed, 2 Sep 2020 12:52:02 +0000
Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::3168:e1aa:8f49:6de3%7]) with mapi id 15.20.3348.015; Wed, 2 Sep 2020 12:52:02 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: Barry Leiba <barryleiba@computer.org>, John Mattsson <john.mattsson@ericsson.com>, Carsten Bormann <cabo@tzi.org>, "core@ietf.org" <core@ietf.org>
CC: "draft-ietf-core-echo-request-tag.all@ietf.org" <draft-ietf-core-echo-request-tag.all@ietf.org>
Thread-Topic: [core] AD review of draft-ietf-core-echo-request-tag-10
Thread-Index: AQHWag2783ig3eTTLEWqbjvVPkqoAKlTipYAgACelYCAACq/gIAABEgAgAFE7gA=
Date: Wed, 02 Sep 2020 12:52:02 +0000
Message-ID: <CF9FD971-16E5-42DD-B443-1D1A4B6A04EE@ericsson.com>
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>
In-Reply-To: <CALaySJLU3-39SPDu9F-y3BUCJXYfKJQUeWhcDoFZF0RxcPh9ig@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.40.20081000
authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b44dd7d2-94c9-48fa-f23e-08d84f3efd42
x-ms-traffictypediagnostic: HE1PR07MB3068:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB3068EFAA2B5110B93B610EDFF42F0@HE1PR07MB3068.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 434tLTfjDEBq5vvjVueXtS0Ds+FOn9W7u5iU2JeRMID49mI4FlEoA1nqn1b8f+WAXBdPPFS5wEGizFi3HWNg++mlNCTrQmPjnRZDcDoM26dxk4EhwGIa8KMVSqF2e8qVIkFWobeMjVWBg7rXU0SG1vlBwOr+IQqJeU/l3CVHD4MiSFtXaAZONSaO62v8+u9Ko1CslrgozF/46HhzF6FgQlUZetqxUQCshC4q2SeAyM38ubjll2Rt8QmIYLQSOrOGnmbs7sOVn6wD0oRPFOF52hp2Mqx0rjbWhUGFCp8Qtj2WOPY86ycYgt/lfRTa9kDcaUngSDTRR7tLMD4xYqw1w9D3S5XUafn5DvaC/By1zGE0va9I7d5ltQbLPkB5GRyt9KryU9fW5qSRV4Av9F5nsA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(39860400002)(396003)(376002)(36756003)(85202003)(6486002)(66446008)(16799955002)(53546011)(64756008)(91956017)(6512007)(66946007)(2616005)(66476007)(66556008)(4326008)(76116006)(5660300002)(85182001)(66574015)(478600001)(186003)(8676002)(6506007)(86362001)(8936002)(2906002)(71200400001)(26005)(83380400001)(110136005)(316002)(966005)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: a0L3MhIArzaEcO8iI5fD5W0m4lRVYLbgJd7BnUIdKeMrcmgkfs3E1RpWVPnA7oBZE/otedLhAXQyBqDaitoZMluZeeTzwAAl2vjaiZ5NYLWPu6EupnJH5WBe5s5RC9XPwwc01OCX0QpSH+6cbmRf/30L83mqhbHEmVw1JWgT7vn8Ukz0gqv/AI0OF902gQQaDw/ts9JnvZWHJ/qth1JzjD2dwWKFkUOje25lRRJ0N59ZPqLH5L35xexjfuU8kL/5l4DPkZ9DMkGIouZboHdkjqn3rfDX1Js9xJa2CP+SAoRd/3p1K356tUkuA442RAIuBSblSoiYQpCnlq4xsyxBYyHq6j3bhy3mPyVulWyR/3/wLSqN40dEydUWuvWxmk9R6CHWapjGpQcJ1K8wdEioTQ1fQQlB2TecYweI+4m9E7a7dMFZAmXHs/ink3EsC09RgmT2yqKYNyj/40vBxvL6Atbui5aocNOYdoE8+UKlYKW03yAcYj71rKIyNodc3O3LG5dRTxd7RzrJbdW36Z3gbtUPPamDYD6AsDXCpsxhwxV12VAm1N+TCSQFMN0Ivzwi8m3HLSeVDXkIHrvt8qP8DZSCT530yOg205gU7BXguoB4tnBWG3CRjwFoldW+Lihp95Ewgyf7vCHNQyvMgnmvCw==
Content-Type: text/plain; charset="utf-8"
Content-ID: <F69D53097C2A5F45B5940F780217F31B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b44dd7d2-94c9-48fa-f23e-08d84f3efd42
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2020 12:52:02.7085 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GGPLsRVuw1S34lvKfjiCRaCnTruvHTBTxV1nuApyN+PxGzK1oYGxypVZB/2GXdc5J0TPRbG6lTFFmtmDAbZDYNpufFIbJA6PzVpJce9aq7Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3068
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/nUAHKqMvBdJuYskH0NbZSSXh178>
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:52:08 -0000

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
    >
    >
    >
    >