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

[Florian Schmaus <[e-mail]>]

On 25.03.19 23:50, Peter Saint-Andre wrote:
> 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.

Right. But my point was that you can not encrypt <IODEF-Document/>,
which is what I assume you would put into those end-to-end encrypted
messages to each Consumer, with XEP-0384 as is, unless you want to put
the XML as string into the <body/>. Sorry if that was not clear.

I would also argue that XEP-0373 provides a standardized technology
(building block) for end-to-end encryption of one-to-many messages in
XMPP, although the XEP is currently marked as 'experimental'.

- Florian