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

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

On 3/25/19 9:31 AM, Florian Schmaus wrote:
> On 25.03.19 14:52, Peter Saint-Andre wrote:
>> 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.
> 
> I'd like to point out that XEP-0384 can sadly, in its current state, not
> be used for this, as it only allows encryption of the <body/> element
> content. But there is the series of "OpenPGP for XMPP" XEPs (XEP-0373,
> -0374), which do support the encryption of arbitrary extension elements
> and hence is suitable for this use case. Full disclaimer: I am one of
> the authors of those XEPs and therefore should be considered biased.

The proposed text says that if you want one-to-many encryption, you'd
need to NOT use pubsub and instead mimic that functionality using the IM
pattern - i.e., each XMPP-Grid "Publisher" and "Consumer" would need to
be a user@host JID, the Consumers would (likely) subscribe to the
presence of each Publisher they want to receive information from, and
the Publisher would send a 1:1 (not 1:many) end-to-end encrypted message
to each Consumer. We're not recommending that model, but it's something
that *could* be done.

Peter