Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)

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

Hi Ben,

    Thanks for the careful review and comments, please see answers below:



    On 1/22/19, 19:14, "Ben Campbell" <[e-mail]> wrote:





        ----------------------------------------------------------------------

        DISCUSS:

        ----------------------------------------------------------------------



        Hi, thanks for the readable approach to this. I like the plain English approach

        to the security considerations, in particular. But I do have some comments,

        including a couple that I think needs to be resolved before progressing the

        draft:



        1) I was surprised not to see a discussion of the "never-meet" problem. That

        is, what happens if a provider and a consumer never connect with the controller

        at the same time. Is the controller expected to store-and-forward items

        submitted to a topic prior to when the consumer connects? IIRC (and I apologize

        that I did not have time to refresh my memory on the referenced XEPs), that

        sort of behavior is optional under XEP-0060. Is it required for this use case?

        Is support for delayed delivery (xep-0203) or something similar required? Or

        perhaps platforms are expected to keep long-lived connections?

    [NCW] I think this is an implementation detail, but we've added a sentence in section 4

    To describe that it is an option per XEP-0060.



        2) The security considerations suggest that the use of TLS mitigates  all of

        the "network attacks". However, the potential or eavesdropping or data

        modification are only mentioned in terms of such "network attacks". It is also

        possible for the controller (aka XMPP server) to do those things unless some

        sort of e2e protection is used. This is not discussed in the sections about how

        the controller is trusted, nor is it discussed in the countermeasures sections.

        There is a mention of e2e protection in the privacy considerations, but I think

        that really needs treatment under the security considerations.

    [NCW] Section 8.2.3 does try to delineate the controller attacks, but we can add the

    Notion of eavesdropping and modification attacks there as well.  As to the considerations,

    We can add in 8.3.3 a sentence to the effect of using e2e protection to address this attack.







        ----------------------------------------------------------------------

        COMMENT:

        ----------------------------------------------------------------------





        *** Substantive Comments ***



        General: I expected to find a discussion of the "never



        Figure 1: I fail to understand the meaning intended by extending "data plane"

        to the right under the peer-to-peer data flow.

        [NCW] The intent is to distinctly outline the different ways in which data may be transferred.

    There were some use cases in which the data bypasses the controller and goes directly from provider to consumer.



        §3: It would be nice to somehow include authentication and authorization in

        Figure 1.

    [NCW] We have revised this figure many times and at some point had the flow for authentication/authorization

    But given the text figure nature, it made it almost unreadable.  If you feel this really must be addressed, then we would

    Have to bring back a previous figure that described that process (previous commenters had us remove it ergo its absence).



        §4: Figure 2 shows the consumer delaying the topic list request until after the

        provider has created the topic. I realize that's just for illustrative

        purposes, but I wonder what would have happened if the consumer requested the

        topic list sooner? Would it ever learn about the new topic?  Do you have

        thoughts about how often new topics will be created in the field?

    [NCW] If the consumer requests a Topic that is not recognized by the controller, then the controller would return an error.

    The flow shows the consumer effectively doing a "discovery" of available topics thru the "Request Topic List" (XEP-0030)

    As that is also the means to discover new topics....

    I can't speak in general, but in our implementation of the XMPP Controller, we find that while new topics are created dynamically, their frequency is not that high in fact, it is very infrequent.



        §5: "a Platform would send an XMPP "disco#info" request to each Topic:"

        Have people thought about how this might work if there are a _lot_ of topics?

    [NCW] That is a good question, in general, consumers that we run across have a small limited number of topics of interest (especially in the threat/security sharing domain).



        §8.1.3: Is the controller trusted to see data and to be able to modify that

        data? Or more to the point: It _can_ do those things. Is it trusted to not

        improperly use, store, or share data, and to not improperly modify data? (See

        further comments below)

    [NCW] In general, it is trusted to NOT touch the data; in the implementations we see, it is possible that the controller can eavesdrop but I do not know of any  XMPP Controller implementation that eavesdrop today.



        §8.3.2:

        - Can you elaborate on the concept of honey tokens?

    [NCW] The intent was to provide a means by which the controller, acting as the broker could effectively generate "fake" entries or messages to detect rogue providers or consumers.  However, the efficacy of such a countermeasure I think is minimal so we will remove that sentence.



        - The requirement that the grid controllers SHOULD keep auditable logs of

        platform behavior has privacy implications that need to be discussed in the

        privacy considerations. In particular, could there be some guidance around not

        logging more information than is needed for the purpose?

    [NCW] That is a fair point.  Will add a paragraph to that effect.



        §8.3.3: "permanent read-only audit logs of security-relevant

        information (especially administrative actions) should be maintained."

        Really permanent, as in forever?  (also, should that "should" be a "SHOULD"?)

    [NCW] Yes, thank you for catching that.



        §8.3.5: I wonder if this guidance creates a new DoS opportunity. Could a

        malicious provider insert so much data into a topic to make it impossible to

        receive data from that topic due to these size limits?  (That brings up a

        question: Can multiple providers insert data to the same topic?)

    [NCW] Given that it is guidance, am not sure how this presents a DoS?  The

    Search or subscription in XMPP does provide filtering capabilities to allow access

    Data subsets.

    A Topic is an abstract managed by the Controller, the controller doesn't store all of the data, the data is managed by the providers; but yes, multiple providers can publish data of the same topic.



        §8.3.6: Can you cite something or otherwise elaborate on certificate pinning?

    [NCW] The intent was to use the certificate pinning as the means for the xmpp platform to have the authorized controller(s) it should connect with....we've added a sentence to that effect.



        *** Editorial Comments:



        §2: In most of the definitions, you treat the XMPP-specific terminology inside

        the definition of the abstract term. Was there a reason to treat "Node"

        differently?

   [NCW] We called out "Node" differently as the XML examples we provided in the document reference Topic as Node.



        §3: "be a Provider or

        Consumer of interested Topics at the Broker"

        I'm not sure topics are capable of being interested. Perhaps "topics of

        interest"?

[NCW] Thanks for catching that. Will fix it in the next revision of the document.



        §4:

        - list item "e":  What does "in real time" mean in the context of a provider

        submitting data to the grid?

[NCW] There are several message exchange patterns such as real-time notifications,

request-response etc between a consumer and a provider. We meant to say that the
providers sends a real-time notification to a broker on a topic.



        - "XMPP-Grid implementations MUST adhere to the mandatory-to-implement

        and mandatory-to-negotiate features as defined in [RFC6120]."

        It's not generally necessary to say that an implementation MUST implement the

        mandatory bits of a spec. That's up to that spec to do itself.

[NCW] XMPP-Grid builds on RFC6120 and therefore it is a MUST for implementations to adhere to RFC6120.



        - "The Service Discovery per [XEP-0030] SHOULD be implemented"

        There appears to be a missing word after "Discovery". Or perhaps the use of

        "The" is incorrect. (i.e. "The Service Discovery Mechanism" vs "Service

        Discovery")

[NCW] Thanks for pointing this out. We changed the statement to -

Implementations SHOULD implement Service Discovery  as defined in XEP-0030 to facilitate

the means to dynamically discover the available information and namespaces (Topics) to be published or consumed.



        §8.1.4: It's a bit confusing to find CA security considerations before any

        mention that there are CAs involved.

[NCW] Our intent was to have the first paragraph in 8.1.4 describe the role of the CA in XMPP-Grid with the following. Perhaps we can clarify the first sentence to state:  “To allow XMPP=Grid Platforms to mutually authenticate with XMPP-Grid Controllers, it is expected that a CA is employed to issue certificates.”



        §8.2.2: "... if the XMPP-Grid Platform assumes that old XMPP-Grid Platform data

        deserves to be ignored." "deserves" has connotations that I don't think apply

        here. I suspect you probably mean "... should be ignored", but were trying to

        avoid the non-normative use of "should". Such use is fine given the draft uses

       the RFC 8174 boilerplate for normative keywords.

[NCW] Thanks for pointing this out. Will fix it in the next revision of the document.



        §8.3.X: There are a number of statements that systems need to be "well

        managed", "hardened against attack", and "reduce their attack surface".  Some

        of them use normative language. These seem like glittering generalities, unless

        specific practices can be recommended or cited.

[NCW] Your comment is appreciated, the intent was to state recommended practices and did where we indicate examples, impose some normative language is needed.  Is there a suggestion you could make to improve on this?



        §8.3.1:  "(with the SCRAM-SHA-256-PLUS variant being preferred over the

        SCRAM-SHA-256 variant and SHA-256 variants [RFC7677] being preferred over SHA-1

        varients [RFC5802]" Should that be stated normatively?

[NCW] Thanks for pointing this out. Per your suggestion, we changed the text from “being preferred” to “SHOULD be preferred”



        §8.3.3: "Administrators SHOULD NOT use password-based

        authentication but should..."

        Should the second "should" be a "SHOULD"?

[NCW] Thanks for pointing this out. We changed it to SHOULD.