[mile] Secdir last call review of draft-ietf-mile-xmpp-grid-09

[Matthew Miller <[e-mail]>]

Reviewer: Matthew Miller
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Document: draft-ietf-mile-xmpp-grid-09
Reviewer: Matthew A. Miller
Review Date: 2018-01-23
IETF LC End Date: 2019-01-14
IESG Telechat date: 2019-01-24

Summary:

This document defines an architecture for distributing security
information using publish-subscribe semantics over XMPP.  It is
well written and addressed many (but not all) known concerns
of a publish-subscribe 

This document has issues that should be addressed before it is
ready to be published as a Proposed Standard.


Major Issues:

The document does not explicitly discuss the implications of the
Controller and Broker having plaintext access and control of the
published data.  It seems to be implied in the section 8.2.3 for
the Controller (and, for those proficient with XMPP, the Broker).
I am not strongly recommending any sort of end-to-end protections
be proscribed (since existing protections are likely unsuitable
for this architecture).

The document does not have any real discussion around persistence
of node items.  if they are expected or desired to be persisted,
then there should be some discussion about retention policies
(meaning: deployments ought to have one), and behaviors when a
Platform subscribes to the Topic (e.g., should or may automatically
send the last published item to the recent subscriber).  If not,
then some discussion on the implications of existing/historic
data being unavailable through this mechanism.

Minor Issues:

XMPP pubsub is complex, and node configuration reflects that.
Relying on XEP-0060 is something of a disservice to implementers,
in my opinion.   I suggest that an addition Topic creation
example be added that demonstrates the recommended configuration:
* pubsub#access-authorize or access-whitelist
* pubsub#persist_items = ?? (1 or 0)
* pubsub#send_last_published_item = ?? (on_sub? never?) 

Nits: N/A