Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21

Ben Campbell <ben@nostrum.com> Fri, 04 January 2019 23:15 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C173126BED; Fri, 4 Jan 2019 15:15:55 -0800 (PST)
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, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 UZC78ddeJUfj; Fri, 4 Jan 2019 15:15:53 -0800 (PST)
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 31F1C130EA2; Fri, 4 Jan 2019 15:15:53 -0800 (PST)
Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x04NFi8D023254 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Jan 2019 17:15:46 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546643747; bh=nUkiXTa7ghxtDEZfTfSt/DcfwZQRSe2zHSHFNG4JiTs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=B70UW7MMKA7AksamQB5P1fi9NAUktRxsrCQ2h4Z8tyJPm7X0mxVrMdnZ0yygp8qjv LEv+9UCF3J3N3s4dvGsyTrUfcENMEq/azVnyc5NfjXjCWeMHqTSueWX9uiF9kBSESu WpZMUy33jx+H4w8GR+c0X+pXyxs84gws8C4HdZlo=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45]
Content-Type: multipart/signed; boundary="Apple-Mail=_3C6786DD-9419-4F77-8A29-3A03954C10D8"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Ben Campbell <ben@nostrum.com>
X-Priority: 3 (Normal)
In-Reply-To: <1546631184.64914945@apps.rackspace.com>
Date: Fri, 04 Jan 2019 17:15:43 -0600
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-sipcore-sip-push.all@ietf.org" <draft-ietf-sipcore-sip-push.all@ietf.org>
Message-Id: <215DF6BE-69A3-4394-9BE2-EE7751957E07@nostrum.com>
References: <1546285539.44113084@apps.rackspace.com> <DB7PR07MB56286B4A2702A5FF1915D1D6938D0@DB7PR07MB5628.eurprd07.prod.outloo k.com> <1546631184.64914945@apps.rackspace.com>
To: "Scott G. Kelly" <scott@hyperthought.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/n7IQxBFhZVSz28zMSylFQgqXKVk>
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jan 2019 23:15:55 -0000

(Speaking as responsible ART AD)

I will let Christer work through most of the comments, but I want to comment on one in particular:

> On Jan 4, 2019, at 1:46 PM, Scott G. Kelly <scott@hyperthought.com> wrote:
> 
> I don't know what other documents have been produced by the WG, so maybe this is covered elsewhere, but there are generic security considerations that apply abstractly to this use case. I think this document should either point to documents that describe them, or explicitly describe them here. For example, 8030 lists confidentiality with respect to the PNS, privacy considerations, authorization, DoS, and logging risks. All of those apply here.


This draft is about how to carry some parameters in SIP that get used with an external PNS. It should definitely document security considerations related to carrying those parameters. But I don’t think it’s reasonable to expect this draft to document security considerations for PNSs in general. That’s up to the spec for the PNS itself. I recognize that two of the mentioned PNSs are proprietary; but I still don’t think that puts the onus on the IETF to document their security considerations.

The categories you mention from 8030 do seem generic, but the text in the respective sections of 8030 seems fairly specific to HTTP(S) Push.

That all being said, I would be happy to see something to the effect of the following in this draft: “The security considerations for the use and operation of any particular PNS is out of scope for this document. [RFC8030] documents the security considerations for HTTP Push. Security considerations for other PNSs are left to their respective specifications.”

Thanks!

Ben.