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

[Ben Campbell <[e-mail]>]

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) <[e-mail]> wrote:
> 
> Hi Ben,
>     Thanks for the careful review and comments, please see answers below:
> 
>     On 1/22/19, 19:14, "Ben Campbell" <[e-mail] <mailto:[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.

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


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

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]