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

Peter Saint-Andre <stpeter@mozilla.com> Tue, 05 March 2019 03:19 UTC

Return-Path: <stpeter@mozilla.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E654E127133 for <mile@ietfa.amsl.com>; Mon, 4 Mar 2019 19:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG-ZMC8nwXAT for <mile@ietfa.amsl.com>; Mon, 4 Mar 2019 19:19:02 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447F7130EAA for <mile@ietf.org>; Mon, 4 Mar 2019 19:18:59 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id k21so5801549ior.13 for <mile@ietf.org>; Mon, 04 Mar 2019 19:18:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OSL3nsmhBKcuZTLHlnBZJqVxGZdTJvpetPOOOt1JZYI=; b=Qy+KPYfv2arUpvdWAwGFqAlzlOrlE7UeYJiB8up2hJDkcp775o0DFTcpS9m/RH8ZcP QlVbyoMJ4bYhV1UuVozudFCYj11w25Irnca7VK+MvfHn3Rhnjbys4UG347wPb/KimnKX lNVSUudXjf/7t5NyEk+UkxDSMDk3fkheWpslU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OSL3nsmhBKcuZTLHlnBZJqVxGZdTJvpetPOOOt1JZYI=; b=lUuQmLxScBGjLbfQfauCxtTHyZrvLNEZqmVaRodxw/ZvEBPqZy8YmkkKRdx853BuHt bcD85y2hwoQPJSTQLmjdUghwF/fzxJLV+HRypGA886L1lIWHO1bEdOcJYIFijx0dN938 iysOjf09lQzsNgKo7VKBWVAz4ZaEmKoBOyF44ytepm0+1WP/AIIM5qY6UIYI7fNbfxU5 YTsL5IOy5ynkACZX0HyOnrI2jpH1UhGigMwUJ37zdd+GVpMME4BEFxne5q6fxQfYa3Ne B5EwLJ8J0enI1uU+q9RfU/V4wp0xk8RUhcFXFVEHKmYNUy8NBoJsUQYs0z6gdrPlndIi FwpA==
X-Gm-Message-State: APjAAAXfHmii+g0RmDEC/olgJEo1Yoa+dcsb6JjYVT2AkdrTDLIqLa05 XPRNQ66KywQBZi+C0ZN9dhvHMQ==
X-Google-Smtp-Source: APXvYqy3thTMZc0Xd4neryJPsDD0GwRTfuXL2IFD/F03x8ZSBRW1mGtkmylmUyE/Iu7PHVvqDlYXEw==
X-Received: by 2002:a5d:958e:: with SMTP id a14mr7568843ioo.125.1551755938311; Mon, 04 Mar 2019 19:18:58 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id r65sm4225360itb.19.2019.03.04.19.18.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 19:18:57 -0800 (PST)
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-mile-xmpp-grid@ietf.org" <draft-ietf-mile-xmpp-grid@ietf.org>, "mile@ietf.org" <mile@ietf.org>, "mile-chairs@tools.ietf.org" <mile-chairs@tools.ietf.org>, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, "mile-chairs@ietf.org" <mile-chairs@ietf.org>
References: <154821326562.13271.17282561556237229622.idtracker@ietfa.amsl.com> <4BD85B49-9F10-4724-B5C7-B4257D8A83CD@cisco.com> <8125411B-783D-4469-B60B-422FA4E447FF@cisco.com> <50DCB5B2-8045-4878-ACA2-A9BE1246DFF1@cisco.com> <C92CD6AF-CC03-4734-8CB4-2FACD071EBFC@cisco.com> <840D870A-36F9-4B32-918B-8F4A3D04EBDF@cisco.com>
From: Peter Saint-Andre <stpeter@mozilla.com>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V
Message-ID: <87b13c76-3363-1f0c-f544-10ede03aaa22@mozilla.com>
Date: Mon, 4 Mar 2019 20:18:56 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <840D870A-36F9-4B32-918B-8F4A3D04EBDF@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/RiHHiwGKoGnwwv8jZWM8VQA9pBg>
Subject: Re: [mile] Ben Campbell's Discuss on draft-ietf-mile-xmpp-grid-09: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 03:19:04 -0000

Inline.

On 3/4/19 10:49 AM, Nancy Cam-Winget (ncamwing) wrote:
> Hi Ben,
> 
>     Thanks for the careful review and comments, please see answers below:
> 
>    
> 
>     On 1/22/19, 19:14, "Ben Campbell" <ben@nostrum.com>; wrote:
> 
>    
> 
>         
> 
>         ----------------------------------------------------------------------
> 
>         DISCUSS:
> 
>        
> ----------------------------------------------------------------------
> 
>         
> 
>         Hi, thanks for the readable approach to this. I like the plain
> English approach
> 
>         to the security considerations, in particular. But I do have
> some comments,
> 
>         including a couple that I think needs to be resolved before
> progressing the
> 
>         draft:
> 
>        
> 
>         1) I was surprised not to see a discussion of the "never-meet"
> problem. That
> 
>         is, what happens if a provider and a consumer never connect with
> the controller
> 
>         at the same time. Is the controller expected to
> store-and-forward items
> 
>         submitted to a topic prior to when the consumer connects? IIRC
> (and I apologize
> 
>         that I did not have time to refresh my memory on the referenced
> XEPs), that
> 
>         sort of behavior is optional under XEP-0060. Is it required for
> this use case?
> 
>         Is support for delayed delivery (xep-0203) or something similar
> required? Or
> 
>         perhaps platforms are expected to keep long-lived connections?
> 
>     [NCW] I think this is an implementation detail, but we've added a
> sentence in section 4
> 
>     To describe that it is an option per XEP-0060.
> 
>        
> 
>         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.

As with any one-to-many or many-to-many communication pattern, e2e is
hard and has not been defined yet for XMPP publish-subscribe. Eventually
perhaps we can use the output of the MLS WG to address this concern.

>         ----------------------------------------------------------------------
> 
>         COMMENT:
> 
>        
> ----------------------------------------------------------------------
> 
>        
> 
>         
> 
>         *** Substantive Comments ***
> 
>        
> 
>         General: I expected to find a discussion of the "never
> 
>        
> 
>         Figure 1: I fail to understand the meaning intended by extending
> "data plane"
> 
>         to the right under the peer-to-peer data flow.
> 
>         [NCW] The intent is to distinctly outline the different ways in
> which data may be transferred.
> 
>     There were some use cases in which the data bypasses the controller
> and goes directly from provider to consumer.
> 
>    
> 
>         §3: It would be nice to somehow include authentication and
> authorization in
> 
>         Figure 1.
> 
>     [NCW] We have revised this figure many times and at some point had
> the flow for authentication/authorization
> 
>     But given the text figure nature, it made it almost unreadable.  If
> you feel this really must be addressed, then we would
> 
>     Have to bring back a previous figure that described that process
> (previous commenters had us remove it ergo its absence).
> 
>         
> 
>         §4: Figure 2 shows the consumer delaying the topic list request
> until after the
> 
>         provider has created the topic. I realize that's just for
> illustrative
> 
>         purposes, but I wonder what would have happened if the consumer
> requested the
> 
>         topic list sooner? Would it ever learn about the new topic?  Do
> you have
> 
>         thoughts about how often new topics will be created in the field?
> 
>     [NCW] If the consumer requests a Topic that is not recognized by the
> controller, then the controller would return an error.
> 
>     The flow shows the consumer effectively doing a "discovery" of
> available topics thru the "Request Topic List" (XEP-0030)
> 
>     As that is also the means to discover new topics....
> 
>     I can't speak in general, but in our implementation of the XMPP
> Controller, we find that while new topics are created dynamically, their
> frequency is not that high in fact, it is very infrequent.
> 
>        
> 
>         §5: "a Platform would send an XMPP "disco#info" request to each
> Topic:"
> 
>         Have people thought about how this might work if there are a
> _lot_ of topics?
> 
>     [NCW] That is a good question, in general, consumers that we run
> across have a small limited number of topics of interest (especially in
> the threat/security sharing domain).
> 
>         
> 
>         §8.1.3: Is the controller trusted to see data and to be able to
> modify that
> 
>         data? Or more to the point: It _can_ do those things. Is it
> trusted to not
> 
>         improperly use, store, or share data, and to not improperly
> modify data? (See
> 
>         further comments below)
> 
>     [NCW] In general, it is trusted to NOT touch the data; in the
> implementations we see, it is possible that the controller can eavesdrop
> but I do not know of any  XMPP Controller implementation that eavesdrop
> today.

Here again, we might want to mention that the XMPP-Grid architecture
assumes a small number of trusted providers, not any sort of public network.

Naturally, such a private network does not guarantee that a Controller
(server) will not engage in eavesdropping, but more than likely the
Controllers will be run by entities that are also providing and
consuming the security incident reports in the first place...

>         §8.3.2:
> 
>         - Can you elaborate on the concept of honey tokens?
> 
>     [NCW] The intent was to provide a means by which the controller,
> acting as the broker could effectively generate "fake" entries or
> messages to detect rogue providers or consumers.  However, the efficacy
> of such a countermeasure I think is minimal so we will remove that sentence.
> 
>        
> 
>         - The requirement that the grid controllers SHOULD keep
> auditable logs of
> 
>         platform behavior has privacy implications that need to be
> discussed in the
> 
>         privacy considerations. In particular, could there be some
> guidance around not
> 
>         logging more information than is needed for the purpose?
> 
>     [NCW] That is a fair point.  Will add a paragraph to that effect.
> 
>        
> 
>         §8.3.3: "permanent read-only audit logs of security-relevant
> 
>         information (especially administrative actions) should be
> maintained."
> 
>         Really permanent, as in forever?  (also, should that "should" be
> a "SHOULD"?)
> 
>     [NCW] Yes, thank you for catching that.

These logging suggestions don't seem necessary for interoperability on
an XMPP-Grid network and thus seem to be a matter of local policy
(outside the scope of this document).

>         §8.3.5: I wonder if this guidance creates a new DoS opportunity.
> Could a
> 
>         malicious provider insert so much data into a topic to make it
> impossible to
> 
>         receive data from that topic due to these size limits?  (That
> brings up a
> 
>         question: Can multiple providers insert data to the same topic?)
> 
>     [NCW] Given that it is guidance, am not sure how this presents a
> DoS?  The
> 
>     Search or subscription in XMPP does provide filtering capabilities
> to allow access

These aren't public networks, so one hopes that the likelihood of
malicious publishers is lessened. That said, any endpoint can be hacked
and turned into a malicious entity. It would be reasonable for the
Broker to refuse excessively large payloads and we can add text to that
effect (see Section 7.1.3.4 of XEP-0060, which defines the
<payload-too-big/> error condition).

Peter