Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange
RFC 8600

Note: This ballot was opened for revision 09 and is now closed.

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-03-26 for -10)
I have discussed my concerns with the authors and am satisfied that my concerns
will be addressed; in the interest of expediency I am clearing my ballot position
now, so as to not introduce unneeded delay.
Thank you for helping to address my points!

Martin Vigoureux No Objection

Warren Kumari No Objection

Comment (2019-01-23 for -09)
No email
send info
Thank you for writing this.

I would have liked to have seen even more on why XMPP versus any of the other distribution systems, but that's just an editorial comment.

(Adam Roach; former steering group member) Yes

Yes (2019-01-22 for -09)
Thanks for such a well-written and clear document. I particularly liked the
extensive and methodical security analysis. I have two substantive comments
about the mechanism that I'd like to have a conversation about prior to moving
towards publication. I am balloting "yes" in anticipation of coming to an
understanding around these two topics.



>  (The payload in the foregoing example is from [RFC7970]; payloads for
>  additional use cases can be found in [RFC8274].)

This format appears to be only exemplary, rather than a requirement of the
mechanism. At the same time, these formats appear to be oriented toward
automatic processing. The presence of a schema indication in the top-level
element of the report does at least allow distinction between different report
formats, but that doesn't allow software to handle a schema that it doesn't
otherwise understand. How does a subscriber know which topics have schema
that they can handle?



>  Another consideration for deployers is to enable end-to-end
>  encryption to ensure the data is protected from the data layer to
>  data layer and thus protect it from the transport layer.

It's not clear what implementors are expected to do with this recommendation.
Options presumably include RFC 3923, XEP-0380, XEP-0373, XEP-0364, XEP-0027, or
maybe something I'm not aware of. I note that the XEPs I mention are
Historical, Obsolete, Experimental, and Deferred, none of which seem appropriate
for use. And it's my understanding that XMPP implementors are... to put it very
mildly, not enthusiastic about RFC 3923.

If I've missed an appropriate mechanism, please cite it as an example of how the
recommendation can be implemented. If not, please add text indicating that a
means for end-to-end encryption is a matter for future study.

(Alexey Melnikov; former steering group member) Yes

Yes ( for -09)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2019-01-23 for -09)
Please respond to the Gen-ART review.

I'm not quite seeing what part of this is a standards-track specification. The workflow in Section 4 is described as "typical" but not normative and the exchanges listed in sections 5 and 6 are listed as examples. For a standards-track specification I would have expected something more like "Implementations of XMPP-Grid adhere to the following workflow ..." and for service discovery and pub-sub to be described as *the* way to do those things in XMPP-Grid, not just illustrated by examples. Otherwise this seems like it could be an informational document.

In the subsections of Section 8.3 I can't readily discern why some of the requirements that relate to protections outside the protocol stack are listed with normative keywords and some are not. It seems like none of them having normative weight would make more sense, or perhaps there is an explanation I'm missing?

(Ben Campbell; former steering group member) (was Discuss) No Objection

No Objection (2019-03-25 for -10)
Thanks for addressing my DISCUSS points in email. I am clearing now under the assumption the right things will happen in the draft text.

My original non-blocking comments are listed below for reference. I leave it to the authors and AD to decide if any further actions are needed.

*** Substantive Comments ***

Figure 1: I fail to understand the meaning intended by extending "data plane" to the right under the peer-to-peer data flow.

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

§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?

§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? 

§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)

- Can you elaborate on the concept of honey tokens?

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

§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"?)

§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?)

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

*** 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?

§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"?

- list item "e":  What does "in real time" mean in the context of a provider submitting data to the grid?

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

- "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")

§8.1.4: It's a bit confusing to find CA security considerations before any mention that there are CAs involved.

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

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

§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?

§8.3.3: "Administrators SHOULD NOT use password-based
authentication but should..."
Should the second "should" be a "SHOULD"?

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Eric Rescorla; former steering group member) (was Discuss) No Objection

No Objection (2019-03-20 for -10)
Thank you for addressing my Discuss

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-01-21 for -09)
Thanks for the good and extensive analysis in the security considerations sections. I would probably say  that we often/usually only see discussions in the security consideration section about the counter-measures (and partly attacks), but not really about the trust and thread model. I think that is probably the case because the basic trust and thread model, as you also describe it, is mostly valid for many communication protocols we specify in the IETF. As such, to make the security considerations more crisp, you could consider moving section 8.1 and 8.2 to the appendix instead. However, that's just an editorial idea and fully at your discretion.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -09)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -09)
No email
send info