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

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

On 3/26/19 9:39 AM, Florian Schmaus wrote:
> 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'.

Good points. I suggest that we remove all references to other potential
solutions, because the XMPP community hasn't settled on a technology for
end-to-end encryption that solves all these problems.

Peter