Subject: Re: [sacm] XMPP grid

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 29 Apr 2015 03:12:09 +0000

Hi Kathleen,

Our apologies for taking so long in responding!

Below are further responses/comments:

On 11/7/14, 5:40 AM, "Kathleen Moriarty"
<[email-masked]> wrote:

>Hello,
>
>I just reviewed the recent version of XMPP grid:
>https://tools.ietf.org/html/draft-salowey-sacm-xmpp-grid-01
>
>First, thank you for your work on this draft.  It looks very good and I
>appreciate the detailed security considerations section.
>
>Here are some comments to consider:
>
>Figure 1 what does dev mean? I didn't see this expanded anywhere, maybe I
>missed it?
[NCW] We mean ³device type² so I¹ve modified it to be dev-type to make it
fit in the figure.

>
>3.6 2nd bullet, typo NThe
[NCW] Fixed (thanks for catching this!)

>
>6.3.1 set minimum for TLS - 1.2 unless there are reasons why that's not
>possible.
[NCW] No reason, so I can make that more clear and reference the RFC as
well.

>
>A reference to the UTA best practices draft for TLS would be good to add
>in this section.  It covers all the decisions admins need to consider
>(developers too).  It's close to finishing up, so it will be published
>before this draft.
>http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-05
[NCW] Done

> 
>
>Http auth has a few newish options for authentication instead of just
>basic and digest, could one of them be an option?  HOBA is about to go
>into IETF last call.
>6.2.1 - do you want to add a reference to the PM RFC7258?
[NCW] I am not sure how to insert addressing Privacy Monitoring in this
contextŠ.do you have suggestions?

>
>7 privacy section
>It's worth mentioning that the easiest way to protect privacy sensitive
>data is to leave it out in the first place.
[NCW] I¹ve added one sentence to this affect in the preamble for this
section.

>
>You should add something to cover considerations for End to end crypto.
>This may matter more for any sensitive data that is sent via an alternate
>protocol like if-map.  I'm not as familiar with that protocol as it's
>been a while since I've read the spec.
[NCW] I¹ve added another paragraph at the end of the privacy section to
cover this.   I¹m not sure IF-MAP is applicable either, but I think it is
worth noting that as a ³transport² protocol, it allows for the data layer
to obscure the data before it gets to the transport layer.

>
>For XMPP grid, I think from the flow diagrams, you actually wind up with
>point-to-point data access with no interchanges leveraging the grid until
>you switch to an end-to-end mechanism to transport the structured or
>unstructured data, is that correct?  I just want to make sure that is the
>case, if not, a recommendation for object-level encryption should be
>added for the control plane (common concern in the incident response
>space, which this could be used for as well and SACM has similar
>considerations for some of the data to be transported).
[NCW] It depends on how the nodes set up their communications.  The
³broker² is there to establish authentication and authorization of the
nodes for how they can communicate within the grid.  One means is to
authorize two parties to establish point-to-point data access, and in that
case the grid doesn¹t get involved in any of the data path (or its
transport).  But in the case where a pub/sub mechanism is imposed, it is
possible that a broker (which could be the grid or some other pub/sub
transport) could be a mediator to disseminate the information to all those
subscribed (and vice versa).

>
>The draft looks great, thanks.
>
>Thank you,
>Kathleen
>
>
>
>Sent from my iPhone
>_______________________________________________
>sacm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sacm