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

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

Hi Ben,

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

    On 1/22/19, 19:14, "Ben Campbell" <[email-masked]> 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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 4 Mar 2019 20:18:56 -0700

Inline.

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

As with any one-to-many or many-to-many communication pattern, e2e is
hard and has not been defined yet for XMPP publish-subscribe. Eventually
perhaps we can use the output of the MLS WG to address this concern.

>     There were some use cases in which the data bypasses the controller
> and goes directly from provider to consumer.
> 
>    
> 
>     [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).
> 
>         
> 
>     [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)
> 
>     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.
> 
>        
> 
>     [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).
> 
>         
> 
>     [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.

Here again, we might want to mention that the XMPP-Grid architecture
assumes a small number of trusted providers, not any sort of public network.

Naturally, such a private network does not guarantee that a Controller
(server) will not engage in eavesdropping, but more than likely the
Controllers will be run by entities that are also providing and
consuming the security incident reports in the first place...

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

These logging suggestions don't seem necessary for interoperability on
an XMPP-Grid network and thus seem to be a matter of local policy
(outside the scope of this document).

>     Search or subscription in XMPP does provide filtering capabilities

These aren't public networks, so one hopes that the likelihood of
malicious publishers is lessened. That said, any endpoint can be hacked
and turned into a malicious entity. It would be reasonable for the
Broker to refuse excessively large payloads and we can add text to that
effect (see Section 7.1.3.4 of XEP-0060, which defines the
<payload-too-big/> error condition).

Peter

---

From: Ben Campbell <[email-masked]>
Date: Sun, 24 Mar 2019 20:32:43 +0100

Hi, apologies for not getting back to this sooner. I’m trying to close or clarify my DISCUSS points prior to stepping down from the IESG this week. Please see inline:

Thanks!

Ben.

> On Mar 4, 2019, at 6:49 PM, Nancy Cam-Winget (ncamwing) <[email-masked]> wrote:
> 
> Hi Ben,
>     On 1/22/19, 19:14, "Ben Campbell" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 

I’m not sure that’s enough to solve the isssue. I think this is more than an implementation detail. I think there’s some implicit assumptions about how and when providers and consumers connnect to the server that are required for interoperation. These should be explicit. For example, do you expect that consumers will maintain long-lived connections to the server, or just connect occasionally to download any waiting data? If there are several new pieces of data published while a consumer is not connected, do they expect to download all the changes or just the latest? (i,e does this require the server to be configured for persistent items?)

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

Unless you expect to really have e2e protection, it’s more important to discuss the effects of not having it.

[I leave my non-blocking comments to the discretion of the authors and responsible AD]

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 24 Mar 2019 15:14:57 -0600

On 3/24/19 1:32 PM, Ben Campbell wrote:
> Hi, apologies for not getting back to this sooner. I’m trying to close
> or clarify my DISCUSS points prior to stepping down from the IESG this
> week. Please see inline:
> 
> Thanks!
> 
> Ben.
> 
>> On Mar 4, 2019, at 6:49 PM, Nancy Cam-Winget (ncamwing)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Ben,
> I’m not sure that’s enough to solve the isssue. I think this is more
> than an implementation detail. I think there’s some implicit assumptions
> about how and when providers and consumers connnect to the server that
> are required for interoperation. These should be explicit. For example,
> do you expect that consumers will maintain long-lived connections to the
> server, or just connect occasionally to download any waiting data? If
> there are several new pieces of data published while a consumer is not
> connected, do they expect to download all the changes or just the
> latest? (i,e does this require the server to be configured for
> persistent items?) 

The "never-meet" problem isn't really a problem in XMPP - all servers
implement support for so-called "offline messages" and the message
delivery semantics defined in Section 8 of RFC 6121 take full account of
eventual delivery by servers to clients that are not online at the time
the message was created. A reference to RFC 6121 should be sufficient to
correctly specify this behavior.

> discuss the effects of not having it.

True. I'll draft text about that (probably later today).

Peter

---

From: Ben Campbell <[email-masked]>
Date: Sun, 24 Mar 2019 22:55:58 +0100

> On Mar 24, 2019, at 10:14 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

I agree referencing RFC 6121 would help.  I had missed the fact the examples use ‘message' stanzas (although if there is normative text that says to do that, I have still missed it.)  Am I mistaken to remember that offline-storage is still optional even for message stanzas?

In any case, a mention of the use of offline-storage as described in 6121 would be sufficient to for me to clear on this point. It would be nice for it to suggest (normatively or otherwise) the use of offline-storage, or at least point out the consequences of not using it.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 24 Mar 2019 16:06:17 -0600

Hi Ben, thanks for continuing to engage on these topics. Replies inline.

On 3/24/19 3:55 PM, Ben Campbell wrote:
> I agree referencing RFC 6121 would help.  I had missed the fact the examples use ‘message' stanzas (although if there is normative text that says to do that, I have still missed it.)

XEP-0060 uses message stanzas for content delivery.

> Am I mistaken to remember that offline-storage is still optional even for message stanzas?
> 

Specifying that servers MUST support offline storage for these use cases
seems appropriate. I can't remember why we said it was only SHOULD-level
in the updated XMPP RFCs (6120 & 6121) - that was silly of us.

Peter

---

From: Ben Campbell <[email-masked]>
Date: Sun, 24 Mar 2019 23:15:27 +0100

> On Mar 24, 2019, at 11:06 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

For better or worse, you’ve got me until the plenary :-) (After which my discuss will be moot unless someone else wants to take it on.)

> XEP-0060 uses message stanzas for content delivery.

Ah, okay.

> in the updated XMPP RFCs (6120 & 6121) - that was silly of us.

If I read 6121 §8.5.2.2.1. correctly, it says SHOULD either store offline _or_ return an error.  That is, rejecting the message with an error is given equal billing.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Mar 2019 07:32:43 -0600

> in the updated XMPP RFCs (6120 & 6121) - that was silly of us.

I propose that we add the following paragraph at the end of Section 6
("Publish-Subscribe"):

   Note that [XEP-0060] uses the XMPP <message/> stanza for delivery of
   content.  To ensure that messages are delivered to the Consumer even
   if the Consumer is not online at the same time that the Publisher
   generates the message, an XMPP-Grid Controller MUST support "offline
   messaging" delivery semantics as specified in [RFC6121], best
   practices for which are further explained in [XEP-0160].

Peter

Peter

---

From: Ben Campbell <[email-masked]>
Date: Mon, 25 Mar 2019 14:34:57 +0100

Hi Peter,

That works for me. I will clear under the assumption this and the comments about the consequences of not having e2e security will make it into the final text.

Thanks!

Ben.

> On Mar 25, 2019, at 2:32 PM, Peter Saint-Andre <[email-masked]> wrote:
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Mar 2019 07:52:12 -0600

>>> <mailto:[email-masked]>> wrote:

<snip/>

> True. I'll draft text about that (probably later today).

I propose adding a new subsection under "Countermeasures":

8.3.6.  End-to-End Encryption of Messages

   Because it is expected that there will be a relatively large number
   of Consumers for every Topic, for purposes of content discovery and
   scaling this document specifies a "one-to-many" communications
   pattern using the XMPP Publish-Subscribe extension.  Unfortunately,
   there is no standardized technology for end-to-end encryption of one-
   to-many messages in XMPP.  This implies that messages can be subject
   to eavesdropping, data injection, and data modification attacks
   within a Broker or Controller.  If it is necessary to mitigate
   against such attacks, implementers would need to select a messaging
   pattern other than [XEP-0060], most likely the basic "instant
   messaging" pattern specified in [RFC6121] with a suitable XMPP
   extension for end-to-end encryption (such as [RFC3923] or a more
   modern method such as [XEP-0384]).  The description of such an
   approach is out of scope for this document.

Peter

---

From: Ben Campbell <[email-masked]>
Date: Mon, 25 Mar 2019 14:53:32 +0100

Looks good, thanks!

I have cleared.

Ben.

> On Mar 25, 2019, at 2:52 PM, Peter Saint-Andre <[email-masked]> wrote:
>

---

From: Florian Schmaus <[email-masked]>
Date: Mon, 25 Mar 2019 16:31:07 +0100

>    approach is out of scope for this document.

I'd like to point out that XEP-0384 can sadly, in its current state, not
be used for this, as it only allows encryption of the <body/> element
content. But there is the series of "OpenPGP for XMPP" XEPs (XEP-0373,
-0374), which do support the encryption of arbitrary extension elements
and hence is suitable for this use case. Full disclaimer: I am one of
the authors of those XEPs and therefore should be considered biased.

- Florian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Mar 2019 16:50:40 -0600

> the authors of those XEPs and therefore should be considered biased.

The proposed text says that if you want one-to-many encryption, you'd
need to NOT use pubsub and instead mimic that functionality using the IM
pattern - i.e., each XMPP-Grid "Publisher" and "Consumer" would need to
be a user@host JID, the Consumers would (likely) subscribe to the
presence of each Publisher they want to receive information from, and
the Publisher would send a 1:1 (not 1:many) end-to-end encrypted message
to each Consumer. We're not recommending that model, but it's something
that *could* be done.

Peter

---

From: Dave Cridland <[email-masked]>
Date: Mon, 25 Mar 2019 23:11:20 +0000

On Sun, 24 Mar 2019 at 22:06, Peter Saint-Andre <[email-masked]> wrote:

> > I agree referencing RFC 6121 would help.  I had missed the fact the
> examples use ‘message' stanzas (although if there is normative text that
> says to do that, I have still missed it.)
>
> > In any case, a mention of the use of offline-storage as described in
> 6121 would be sufficient to for me to clear on this point. It would be nice
> for it to suggest (normatively or otherwise) the use of offline-storage, or
> at least point out the consequences of not using it.
>
We called it SHOULD because there are multiple methods for the
decortication of felines, some possibly preferable to the "traditional"
offline messages, and it might be a sensible choice to use these and no
longer support offline messages in the sense of XEP-0160.

In particular, there's XEP-0313 (Message Archive Management) which, either
as a "personal" archive on the consumer's server, or as a service available
on the Pubsub Node, would allow a consumer to "catch up" perfectly well -
and probably more effectively than the XEP-0160 style.

Plus there's XEP-0198 (Stream Management), which rather blurs what
"offline" actually means, XEP-0357 (Push Notifications) which might send
the traffic out of band, and so on.

Also "SHOULD" doesn't mean "OPTIONAL", as Ben OUGHT to know. ;-)

> Peter
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: Florian Schmaus <[email-masked]>
Date: Tue, 26 Mar 2019 16:39:45 +0100

> to each Consumer. We're not recommending that model, but it's something

Right. But my point was that you can not encrypt <IODEF-Document/>,
which is what I assume you would put into those end-to-end encrypted
messages to each Consumer, with XEP-0384 as is, unless you want to put
the XML as string into the <body/>. Sorry if that was not clear.

I would also argue that XEP-0373 provides a standardized technology
(building block) for end-to-end encryption of one-to-many messages in
XMPP, although the XEP is currently marked as 'experimental'.

- Florian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 27 Mar 2019 10:37:44 -0600

> XMPP, although the XEP is currently marked as 'experimental'.

Good points. I suggest that we remove all references to other potential
solutions, because the XMPP community hasn't settled on a technology for
end-to-end encryption that solves all these problems.

Peter