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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

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