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

[Matthew Miller <[e-mail]>]

Thank you Nancy and Peter for your replies.  I look forward to the next
revision.

On Mon, Mar 4, 2019 at 7:39 PM Peter Saint-Andre <[e-mail]>
wrote:

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

Thanks, I think both clarifications will be very helpful.


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

I think all of that will help.


>
> >     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 could have phrased this concern better; my intent was to try to pave the
path for implementers a little better.  I absolutely agree using pubsub is
the right choice.


> >  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.
>
>
Thanks for this.


- m&m
Matthew A. Miller