Re: [mile] Adam Roach's Yes on draft-ietf-mile-xmpp-grid-09: (with COMMENT)

[Peter Saint-Andre <[e-mail]>]

A few amplifications inline.

On 3/4/19 2:46 PM, Nancy Cam-Winget (ncamwing) wrote:
> Thank you for the comments Adam, please see further below:
> 
> On 1/22/19, 19:25, "Adam Roach" <[e-mail]> wrote:
> 
>     Adam Roach has entered the following ballot position for
>     draft-ietf-mile-xmpp-grid-09: Yes
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     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.
>     
>     ---------------------------------------------------------------------------
>     
>     §6:
>     
>     >  (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?
> [NCW] In the implementations (of subscribers) we have seen, they typically are looking for
> Schemas they already understand.  That is, when it does the capability discovery, it is looking to match namespaces it knows about and ignores the ones it doesn't.

Even more specifically, the service discovery information result
returned by the Broker will contain a field such as the following:

       <field var='pubsub#type' label='Payload type' type='text-single'>
        <value>urn:ietf:params:xml:ns:iodef-2.0</value>
       </field>

It's true that discovering the Topics that support the desired
namespaces thus requires a bit of work by the Platforms, but that
information can be cached locally once discovered.

>     §9:
>     
>     >  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.
>         [NCW] Thanks for pointing this out. We added the following sentence in Section 9 -
>         The means to achieve end-to-end encryption is beyond the scope of this document.

See also my reply to the secdir review earlier this evening, in which I
noted:

  We should make it clearer in the document that the XMPP-Grid is not
  intended to be an open system that any arbitrary entity can join;
  instead, it is a private network (not connected to the public XMPP
  network) to which only authorized entities are allowed access.

Peter