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

[Ben Campbell <[e-mail]>]

Looks good, thanks!

I have cleared.

Ben.

> On Mar 25, 2019, at 2:52 PM, Peter Saint-Andre <[e-mail]> wrote:
> 
> On 3/24/19 3:14 PM, Peter Saint-Andre wrote:
>> 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)
>>>> <[e-mail] <mailto:[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:
>>>> 
>>>> 
> 
> <snip/>
> 
>>>>         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.
>> 
>> 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