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

[Peter Saint-Andre <[e-mail]>]

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" <[e-mail]> 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