Re: [mile] Secdir last call review of draft-ietf-mile-xmpp-grid-09

Peter Saint-Andre <stpeter@mozilla.com> Tue, 05 March 2019 02:40 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 B59B1130EA5 for <mile@ietfa.amsl.com>; Mon, 4 Mar 2019 18:40:00 -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=ham 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 AynunyMRwqHD for <mile@ietfa.amsl.com>; Mon, 4 Mar 2019 18:39:58 -0800 (PST)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 129CD12D4E7 for <mile@ietf.org>; Mon, 4 Mar 2019 18:39:58 -0800 (PST)
Received: by mail-it1-x132.google.com with SMTP id v2so2008014ith.3 for <mile@ietf.org>; Mon, 04 Mar 2019 18:39:57 -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=Kas9j4JkT/8905atQMrTvdov1dlERaZNuPG2AAUuLh0=; b=MZlSGp4KFUIlWRHzE3zflC3qyKEo5WJL15NfFFHYb1ZNjqHs6feCPCyg34e/97WH+W x8BO5J31QoroDLBZ3Cwt47J5racQhTq9pnIllXguG7uzdAketS4jfdDoArW22834pCoI qJWUeP0Xn13i7gNFlcYQ3B79jeOmglCzAsyhE=
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=Kas9j4JkT/8905atQMrTvdov1dlERaZNuPG2AAUuLh0=; b=GofSzccxu6bxyoAJCgJS4XoNoYRJXr34xYgpraClP5TZVqpI6n+7AGr9MdMBO3Cl/l dvLk5iIjbrs+YXPlokV5yE6UKLaOHKXDbVprC6usLCDlTwYDUbsurGgEzYYqRshuAx1P 8WVpTyBjsPfXih/JLO9H35YJPAhw8/u8s/c10SWGWaIU3Pp2wXdpdYQW38Tdq+HeUdBN 95aLgdIyCBihltTerOEiGcNsiijl13cq54usoKCvvR0QcTfIdJDP8F3HD2MplyL8LmK5 IJlWE+p5CuCSU7Hf/oETjeIep9n14/wBZaFkVSojLzWyvJskqczUsiM/z+xwG6n6kpNb /czw==
X-Gm-Message-State: APjAAAV7+9WMwJXk4sOIrdLI4ixiOTyH+CQXiBcOttQyZtVuvhL7++4r QlWPawXj7kpkyuw1KpY1Wu/NRg==
X-Google-Smtp-Source: APXvYqyq//BGSQul7bp9J+2IHvavyVKgRXrEJJ3lBmNzAUM1/8UzUntBgnuEnAc3n9hau21gprRJ1A==
X-Received: by 2002:a24:dd1:: with SMTP id 200mr1411808itx.65.1551753597247; Mon, 04 Mar 2019 18:39:57 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id s12sm3804184itj.41.2019.03.04.18.39.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 18:39:56 -0800 (PST)
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, Matthew Miller <linuxwolf+ietf@outer-planes.net>, "secdir@ietf.org" <secdir@ietf.org>
Cc: "mile@ietf.org" <mile@ietf.org>, "draft-ietf-mile-xmpp-grid.all@ietf.org" <draft-ietf-mile-xmpp-grid.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
References: <154826649938.7505.11018194912932133243@ietfa.amsl.com> <5CFE429E-31EA-4261-B1CD-17181200F394@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: <8eaa83e6-5218-9584-ad4e-5e2e7f8e80ad@mozilla.com>
Date: Mon, 4 Mar 2019 19:39:55 -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: <5CFE429E-31EA-4261-B1CD-17181200F394@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/RNU0bt-VM0PK4q8GRA3xnDT-BxQ>
Subject: Re: [mile] Secdir last call review of draft-ietf-mile-xmpp-grid-09
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 02:40:01 -0000

A few further thoughts from a co-author but not primary author.

On 3/4/19 4:00 PM, Nancy Cam-Winget (ncamwing) wrote:
> Hi Matt, thanks for the review.  Please see below for comments:
> 
> ´╗┐On 1/23/19, 10:01, "Matthew Miller" <linuxwolf+ietf@outer-planes.net>; wrote:
> 
>     Reviewer: Matthew Miller
>     Review result: Has Issues
>     
>     I have reviewed this document as part of the security directorate's
>     ongoing effort to review all IETF documents being processed by the
>     IESG.  These comments were written primarily for the benefit of the
>     security area directors.  Document editors and WG chairs should
>     treat these comments just like any other last call comments.
>     
>     Document: draft-ietf-mile-xmpp-grid-09
>     Reviewer: Matthew A. Miller
>     Review Date: 2018-01-23
>     IETF LC End Date: 2019-01-14
>     IESG Telechat date: 2019-01-24
>     
>     Summary:
>     
>     This document defines an architecture for distributing security
>     information using publish-subscribe semantics over XMPP.  It is
>     well written and addressed many (but not all) known concerns
>     of a publish-subscribe 
>     
>     This document has issues that should be addressed before it is
>     ready to be published as a Proposed Standard.
>     
>     
>     Major Issues:
>     
>     The document does not explicitly discuss the implications of the
>     Controller and Broker having plaintext access and control of the
>     published data.  It seems to be implied in the section 8.2.3 for
>     the Controller (and, for those proficient with XMPP, the Broker).
>     I am not strongly recommending any sort of end-to-end protections
>     be proscribed (since existing protections are likely unsuitable
>     for this architecture).
> [NCW] We have added a sentence in 8.3.3 to address protection 
> against controller/broker to employ end-to-end encryption.

Matt's point about "this architecture" is relevant. We should make it
clearer in the document that the XMPP-Grid is not intended to be an open
system that any arbitrary entity can join; instead, it is a private
network (not connected to the public XMPP network) to which only
authorized entities are allowed access.

>     The document does not have any real discussion around persistence
>     of node items.  if they are expected or desired to be persisted,
>     then there should be some discussion about retention policies
>     (meaning: deployments ought to have one), and behaviors when a
>     Platform subscribes to the Topic (e.g., should or may automatically
>     send the last published item to the recent subscriber).  If not,
>     then some discussion on the implications of existing/historic
>     data being unavailable through this mechanism.
> [NCW] Fair point. We added the following statements to the document to address this -
> Note that the control plane may optionally also implement XEP-0203 to facilitate delayed
> delivery of messages to the connected consumer as described in XEP-0060. Since information
> may be timely and sensitive, capability providers should communicate to the controller
> whether its messages can be cached for delayed delivery during configuration; such function
> is out of scope for this document.

In addition, we should mention the "pubsub#last-published" configuration
option.

Preservation or reconstruction of the history of messages sent to a
Topic strikes me as a service that a Broker isn't required to provide
(e.g., because the history might become quite large), just as a message
archive for an email discussion list might be provided by an entity
other than the delivery service.

>     Minor Issues:
>     
>     XMPP pubsub is complex, and node configuration reflects that.
>     Relying on XEP-0060 is something of a disservice to implementers,
>     in my opinion. 

Given the generic publish-subscribe pattern required here, it felt more
appropriate to re-use an existing XMPP extension (of which there are
numerous implementations) than to invent something new.

>  I suggest that an addition Topic creation
>     example be added that demonstrates the recommended configuration:
>     * pubsub#access-authorize or access-whitelist
>     * pubsub#persist_items = ?? (1 or 0)
>     * pubsub#send_last_published_item = ?? (on_sub? never?) 
> [NCW] That seems reasonable, I will add it as an option (as the current section does state it is the minimal for topic creation).

Yes, on_sub ('When a new subscription is processed') seems appropriate.

Peter