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

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

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