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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 4 Mar 2019 23:00:16 +0000

Hi Matt, thanks for the review.  Please see below for comments:

On 1/23/19, 10:01, "Matthew Miller" <[email-masked]> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 4 Mar 2019 19:39:55 -0700

A few further thoughts from a co-author but not primary author.

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

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

>     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

Yes, on_sub ('When a new subscription is processed') seems appropriate.

Peter

---

From: Matthew Miller <[email-masked]>
Date: Tue, 5 Mar 2019 18:27:57 -0700

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

> authorized entities are allowed access.

Thanks, I think both clarifications will be very helpful.

> other than the delivery service.

I think all of that will help.

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

> > [NCW] That seems reasonable, I will add it as an option (as the current
> section does state it is the minimal for topic creation).
>
Thanks for this.

- m&m
Matthew A. Miller