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

Ben Campbell <ben@nostrum.com> Wed, 23 January 2019 03:14 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mile@ietf.org
Delivered-To: mile@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7B4130E0E; Tue, 22 Jan 2019 19:14:25 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mile-xmpp-grid@ietf.org, mile@ietf.org, mile-chairs@tools.ietf.org, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, mile-chairs@ietf.org, takeshi_takahashi@nict.go.jp, mile@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.90.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154821326562.13271.17282561556237229622.idtracker@ietfa.amsl.com>
Date: Tue, 22 Jan 2019 19:14:25 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/q8bdvLrzv8MoPI-k7B64O8wQpEc>
Subject: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2019 03:14:26 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-mile-xmpp-grid-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/



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

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


*** Substantive Comments ***

General: I expected to find a discussion of the "never

Figure 1: I fail to understand the meaning intended by extending "data plane"
to the right under the peer-to-peer data flow.

§3: It would be nice to somehow include authentication and authorization in
Figure 1.

§4: Figure 2 shows the consumer delaying the topic list request until after the
provider has created the topic. I realize that's just for illustrative
purposes, but I wonder what would have happened if the consumer requested the
topic list sooner? Would it ever learn about the new topic?  Do you have
thoughts about how often new topics will be created in the field?

§5: "a Platform would send an XMPP "disco#info" request to each Topic:"
Have people thought about how this might work if there are a _lot_ of topics?

§8.1.3: Is the controller trusted to see data and to be able to modify that
data? Or more to the point: It _can_ do those things. Is it trusted to not
improperly use, store, or share data, and to not improperly modify data? (See
further comments below)

§8.3.2:
- Can you elaborate on the concept of honey tokens?

- The requirement that the grid controllers SHOULD keep auditable logs of
platform behavior has privacy implications that need to be discussed in the
privacy considerations. In particular, could there be some guidance around not
logging more information than is needed for the purpose?

§8.3.3: "permanent read-only audit logs of security-relevant
information (especially administrative actions) should be maintained."
Really permanent, as in forever?  (also, should that "should" be a "SHOULD"?)

§8.3.5: I wonder if this guidance creates a new DoS opportunity. Could a
malicious provider insert so much data into a topic to make it impossible to
receive data from that topic due to these size limits?  (That brings up a
question: Can multiple providers insert data to the same topic?)

§8.3.6: Can you cite something or otherwise elaborate on certificate pinning?

*** Editorial Comments:

§2: In most of the definitions, you treat the XMPP-specific terminology inside
the definition of the abstract term. Was there a reason to treat "Node"
differently?

§3: "be a Provider or
Consumer of interested Topics at the Broker"
I'm not sure topics are capable of being interested. Perhaps "topics of
interest"?

§4:
- list item "e":  What does "in real time" mean in the context of a provider
submitting data to the grid?

- "XMPP-Grid implementations MUST adhere to the mandatory-to-implement
and mandatory-to-negotiate features as defined in [RFC6120]."
It's not generally necessary to say that an implementation MUST implement the
mandatory bits of a spec. That's up to that spec to do itself.

- "The Service Discovery per [XEP-0030] SHOULD be implemented"
There appears to be a missing word after "Discovery". Or perhaps the use of
"The" is incorrect. (i.e. "The Service Discovery Mechanism" vs "Service
Discovery")

§8.1.4: It's a bit confusing to find CA security considerations before any
mention that there are CAs involved.

§8.2.2: "... if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data
deserves to be ignored." "deserves" has connotations that I don't think apply
here. I suspect you probably mean "... should be ignored", but were trying to
avoid the non-normative use of "should". Such use is fine given the draft uses
the RFC 8174 boilerplate for normative keywords.

§8.3.X: There are a number of statements that systems need to be "well
managed", "hardened against attack", and "reduce their attack surface".  Some
of them use normative language. These seem like glittering generalities, unless
specific practices can be recommended or cited.

§8.3.1:  "(with the SCRAM-SHA-256-PLUS variant being preferred over the
SCRAM-SHA-256 variant and SHA-256 variants [RFC7677] being preferred over SHA-1
varients [RFC5802]" Should that be stated normatively?

§8.3.3: "Administrators SHOULD NOT use password-based
authentication but should..."
Should the second "should" be a "SHOULD"?