A few further thoughts from a co-author but not primary author.
On 3/4/19 4:00 PM, Nancy Cam-Winget (ncamwing) wrote:
> 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.
Matt's point about "this architecture" is relevant. We should make it
clearer in the document that the XMPP-Grid is not intended to be an open
system that any arbitrary entity can join; instead, it is a private
network (not connected to the public XMPP network) to which only
authorized entities are allowed access.
> 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.
In addition, we should mention the "pubsub#last-published" configuration
option.
Preservation or reconstruction of the history of messages sent to a
Topic strikes me as a service that a Broker isn't required to provide
(e.g., because the history might become quite large), just as a message
archive for an email discussion list might be provided by an entity
other than the delivery service.
> 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.
Given the generic publish-subscribe pattern required here, it felt more
appropriate to re-use an existing XMPP extension (of which there are
numerous implementations) than to invent something new.
> 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).
Yes, on_sub ('When a new subscription is processed') seems appropriate.
Peter
