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

Peter Saint-Andre <stpeter@mozilla.com> Sun, 24 March 2019 21:15 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 46FE9120120 for <mile@ietfa.amsl.com>; Sun, 24 Mar 2019 14:15:05 -0700 (PDT)
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 AIeOfIWE_ICr for <mile@ietfa.amsl.com>; Sun, 24 Mar 2019 14:15:04 -0700 (PDT)
Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 4BC77120121 for <mile@ietf.org>; Sun, 24 Mar 2019 14:15:01 -0700 (PDT)
Received: by mail-it1-x143.google.com with SMTP id h9so11106422itl.1 for <mile@ietf.org>; Sun, 24 Mar 2019 14:15:01 -0700 (PDT)
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; bh=U4ysGW8m3QkwNFuqG8ZqBWWMHvp1kPLZike6b8qdxWU=; b=C7EpmNiuIO8y/1RSNU5XWnUswwjOAZFetxeE8bUuWSmA6UAOaN9AVFXudH/0VYA74i olkM10Uy2DGa9s3H2qLvElYD7YCHdrkX18CzpEUtoRFt6pOoRCwlC3uy69HPMA0My7G6 Wwcj4EHWS3rSm4b/twBEgu1TWhbpysCTUR4eo=
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; bh=U4ysGW8m3QkwNFuqG8ZqBWWMHvp1kPLZike6b8qdxWU=; b=RyOXDgb/Ifjj6tzedEIW84offjRG3PmDXYv4WScaUUYrVuZ5uaXV7CbC3vbw42PrNg zk6k8LqjmbJajVr95NECmHvgqGONEnOyaCmEw3SUVbQ4z+NOty7CEEuy22bwaKQR6PrL m836++9ky5Xa9LHrVPzUJR+tC+3L41EubElpAF8mk1iMj2UhVy/3AKXC66tssRDu7l+s xiJe+42ExYeaUrILuOdntRy7iVRkmMyp7wvOUYbKOb7tl0+m7pUPbMrQIPRr08nfL5v7 IDA/TYfKgebZIuB9JlXGpqa7MS0VkPeskifDu2211O5oSon+T+xqOx0BRtSWM1QS/epi zWVg==
X-Gm-Message-State: APjAAAVq+O8EGJ+4ViTxfZYcDVr4SjCvybo/j8qcGZ+aDGWHhStyWYiY IyntkmPCvNzrfBwUViCqqSExuA==
X-Google-Smtp-Source: APXvYqzGFj7qy1VJqfGBLnpb0IqXaSr2XT2kJ7JuVPANHGBqs676AwENY2zBtMvMZALdku4fl/9V7A==
X-Received: by 2002:a02:2b0e:: with SMTP id h14mr9763717jaa.73.1553462100561; Sun, 24 Mar 2019 14:15:00 -0700 (PDT)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id a80sm4837218ita.0.2019.03.24.14.14.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Mar 2019 14:14:59 -0700 (PDT)
To: Ben Campbell <ben@nostrum.com>, "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
Cc: The IESG <iesg@ietf.org>, "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> <7F9B5B96-D304-44B4-88D3-A598450477FF@nostrum.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: <2cee29b8-99ce-2053-6044-2c2e4c501557@mozilla.com>
Date: Sun, 24 Mar 2019 15:14:57 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <7F9B5B96-D304-44B4-88D3-A598450477FF@nostrum.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="XRUpFBzfWu9siIQ03NxCI2rhTUFce2MJg"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/N6m-UOuZ5mTvjnJTwfJplQkYTjw>
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: Sun, 24 Mar 2019 21:15:05 -0000

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)
>> <ncamwing@cisco.com <mailto:ncamwing@cisco.com>> 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
>> <mailto: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.
> 
> I’m not sure that’s enough to solve the isssue. I think this is more
> than an implementation detail. I think there’s some implicit assumptions
> about how and when providers and consumers connnect to the server that
> are required for interoperation. These should be explicit. For example,
> do you expect that consumers will maintain long-lived connections to the
> server, or just connect occasionally to download any waiting data? If
> there are several new pieces of data published while a consumer is not
> connected, do they expect to download all the changes or just the
> latest? (i,e does this require the server to be configured for
> persistent items?) 

The "never-meet" problem isn't really a problem in XMPP - all servers
implement support for so-called "offline messages" and the message
delivery semantics defined in Section 8 of RFC 6121 take full account of
eventual delivery by servers to clients that are not online at the time
the message was created. A reference to RFC 6121 should be sufficient to
correctly specify this behavior.

>>         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).

Peter