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

Ben Campbell <ben@nostrum.com> Sun, 24 March 2019 21:56 UTC

Return-Path: <ben@nostrum.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 DE91E120141; Sun, 24 Mar 2019 14:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 KiNXpKaVRPFd; Sun, 24 Mar 2019 14:56:08 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 471C8120140; Sun, 24 Mar 2019 14:56:08 -0700 (PDT)
Received: from dhcp-9259.meeting.ietf.org (dhcp-9259.meeting.ietf.org [31.133.146.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2OLtxTv058992 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 24 Mar 2019 16:56:02 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553464564; bh=GpvVoda6jsG79PT6wSMhOT/yprF7OabJLaHJNSca2Ko=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=RY2nGz24UNmDo1Q/Lv31VcJZtqp4+EcAZGTBniwcLWii2C8rct0JVjJMWPYBzgkDp jCbTH0KFP17PIYZO7ykjmPvoUQKasbE6bsscR7BEsT9PX2xTAn3QH86hkMRudxncYo LGk82KFpTGTLAz2n1WGBw04dwyDDRcGlCfs6+etA=
From: Ben Campbell <ben@nostrum.com>
Message-Id: <67A5EFDB-F42F-4FE3-8DB0-9280B06C9289@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_05DCA918-7605-4641-A3DA-6F560D07EE8A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sun, 24 Mar 2019 22:55:58 +0100
In-Reply-To: <2cee29b8-99ce-2053-6044-2c2e4c501557@mozilla.com>
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "draft-ietf-mile-xmpp-grid@ietf.org" <draft-ietf-mile-xmpp-grid@ietf.org>, "mile-chairs@tools.ietf.org" <mile-chairs@tools.ietf.org>, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, The IESG <iesg@ietf.org>, "mile-chairs@ietf.org" <mile-chairs@ietf.org>, "mile@ietf.org" <mile@ietf.org>
To: Peter Saint-Andre <stpeter@mozilla.com>
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> <2cee29b8-99ce-2053-6044-2c2e4c501557@mozilla.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/nCPxPxT3fh6k4taAY0z5IipECbM>
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:56:10 -0000


> On Mar 24, 2019, at 10:14 PM, Peter Saint-Andre <stpeter@mozilla.com>; wrote:
> 
> 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.


I agree referencing RFC 6121 would help.  I had missed the fact the examples use ‘message' stanzas (although if there is normative text that says to do that, I have still missed it.)  Am I mistaken to remember that offline-storage is still optional even for message stanzas?

In any case, a mention of the use of offline-storage as described in 6121 would be sufficient to for me to clear on this point. It would be nice for it to suggest (normatively or otherwise) the use of offline-storage, or at least point out the consequences of not using it.


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