Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

Ben Campbell <> Sun, 24 March 2019 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACC1912006D; Sun, 24 Mar 2019 12:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y06plXil1Z7s; Sun, 24 Mar 2019 12:32:51 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C509C12006E; Sun, 24 Mar 2019 12:32:51 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x2OJWjqU032652 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 24 Mar 2019 14:32:47 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1553455971; bh=TC8PPYV9/fwvINAf2CCK2rECossroPIExInQcvqa1Bc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=oNT6InObS7i9v1Y06U0kLEGL1hhRF/wgOInhWzU9pqMQLr79v2coukGhhbKb/tdBY MmnFPWFrYkYW04j/cIf0kuynK55fpc1nacYZsojKREvys3CHbUqyL5rN5k+DrCP9Nt mb1k2oCwYf6ZH5LKZ7+xRWOfzIr2fwr8QGV/YoOw=
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_BDA019BD-4D8B-466C-8AA2-FB5D9C49707A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sun, 24 Mar 2019 20:32:43 +0100
In-Reply-To: <>
Cc: The IESG <>, "" <>, "" <>, "" <>, Takeshi Takahashi <>, "" <>
To: "Nancy Cam-Winget (ncamwing)" <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Mar 2019 19:32:54 -0000

Hi, apologies for not getting back to this sooner. I’m trying to close or clarify my DISCUSS points prior to stepping down from the IESG this week. Please see inline:



> On Mar 4, 2019, at 6:49 PM, Nancy Cam-Winget (ncamwing) <> wrote:
> Hi Ben,
>     Thanks for the careful review and comments, please see answers below:
>     On 1/22/19, 19:14, "Ben Campbell" < <>> wrote:
>         ----------------------------------------------------------------------
>         DISCUSS:
>         ----------------------------------------------------------------------
>         Hi, thanks for the readable approach to this. I like the plain English approach
>         to the security considerations, in particular. But I do have some comments,
>         including a couple that I think needs to be resolved before progressing the
>         draft:
>         1) I was surprised not to see a discussion of the "never-meet" problem. That
>         is, what happens if a provider and a consumer never connect with the controller
>         at the same time. Is the controller expected to store-and-forward items
>         submitted to a topic prior to when the consumer connects? IIRC (and I apologize
>         that I did not have time to refresh my memory on the referenced XEPs), that
>         sort of behavior is optional under XEP-0060. Is it required for this use case?
>         Is support for delayed delivery (xep-0203) or something similar required? Or
>         perhaps platforms are expected to keep long-lived connections?
>     [NCW] I think this is an implementation detail, but we've added a sentence in section 4
>     To describe that it is an option per XEP-0060.

I’m not sure that’s enough to solve the isssue. I think this is more than an implementation detail. I think there’s some implicit assumptions about how and when providers and consumers connnect to the server that are required for interoperation. These should be explicit. For example, do you expect that consumers will maintain long-lived connections to the server, or just connect occasionally to download any waiting data? If there are several new pieces of data published while a consumer is not connected, do they expect to download all the changes or just the latest? (i,e does this require the server to be configured for persistent items?)

>         2) The security considerations suggest that the use of TLS mitigates  all of
>         the "network attacks". However, the potential or eavesdropping or data
>         modification are only mentioned in terms of such "network attacks". It is also
>         possible for the controller (aka XMPP server) to do those things unless some
>         sort of e2e protection is used. This is not discussed in the sections about how
>         the controller is trusted, nor is it discussed in the countermeasures sections.
>         There is a mention of e2e protection in the privacy considerations, but I think
>         that really needs treatment under the security considerations.
>     [NCW] Section 8.2.3 does try to delineate the controller attacks, but we can add the
>     Notion of eavesdropping and modification attacks there as well.  As to the considerations,
>     We can add in 8.3.3 a sentence to the effect of using e2e protection to address this attack.

Unless you expect to really have e2e protection, it’s more important to discuss the effects of not having it.

[I leave my non-blocking comments to the discretion of the authors and responsible AD]