Hi Matt, thanks for the review. Please see below for comments:
On 1/23/19, 10:01, "Matthew Miller" <linuxwolf+ietf@xxxxxxxxxxxxxxxx> wrote:
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).
[NCW] We have added a sentence in 8.3.3 to address protection
against controller/broker to employ end-to-end encryption.
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.
[NCW] Fair point. We added the following statements to the document to address this -
Note that the control plane may optionally also implement XEP-0203 to facilitate delayed
delivery of messages to the connected consumer as described in XEP-0060. Since information
may be timely and sensitive, capability providers should communicate to the controller
whether its messages can be cached for delayed delivery during configuration; such function
is out of scope for this document.
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?)
[NCW] That seems reasonable, I will add it as an option (as the current section does state it is the minimal for topic creation).
Nits: N/A
