Re: [sipcore] AD Evaluation of draft-ietf-sipcore-callinfo-spam-03

Ben Campbell <ben@nostrum.com> Mon, 14 January 2019 23:16 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9103B12DF72; Mon, 14 Jan 2019 15:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 rBhhecVVYLN6; Mon, 14 Jan 2019 15:16: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 CDD78126C01; Mon, 14 Jan 2019 15:16:50 -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 x0ENGmoH057618 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Jan 2019 17:16:50 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547507810; bh=EcNmjoGQKQevrhfjrygPHIjQNV1HXLvpLnGfon7hTJc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=KCSyxV6Izf2CdjiIaol+c60sgxACprC6p/grNF2fxBTo/s9c3+4+GWSIoo7k4Q44q ssS4Ee22G/KC+UkpMCcng3wgfHSsNpEJEGVGwaEwb+JiZh0YxKRKIm1QeDq5EDCgQL qRQW9ytu+4BdL7k8RAp5xqqnbg2J+iBzJEDA9cyI=
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]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <29F0C4B1-41DE-421B-9223-B45CDC00F7C0@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_DD10F6DE-496B-483D-A475-05D1C47FF4B5"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 14 Jan 2019 17:16:48 -0600
In-Reply-To: <E39B97AC-FD81-4071-B97A-3D94388DE022@nostrum.com>
Cc: sipcore@ietf.org
To: draft-ietf-sipcore-callinfo-spam.all@ietf.org
References: <E39B97AC-FD81-4071-B97A-3D94388DE022@nostrum.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/qn2POtXgLU1OW7ZOIu_Z8p69Zmw>
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-callinfo-spam-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2019 23:16:56 -0000

Hi,

What’s the status of getting a new revision or otherwise responding to my comments? There was some urgency for this draft at the start, please don’t let it stall out this late in the process.

Thanks!

Ben.

> On Nov 28, 2018, at 10:30 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> Signed PGP part
> Hi,
> 
> This is my AD Evaluation of draft-ietf-sipcore-callinfo-spam-03. I have one major comment, and a few minor and editorial comments. I’d like to resolve the major comment prior to IETF last call.
> 
> Thanks!
> 
> Ben.
> 
> 
> *** Major Comments ***
> 
> The draft needs to better describe the trust model. Currently, it says that a UA must ignore any spam parameters unless the registrar included the Feature-Caps tag. That implies the UA trusts the SIP service to label spam; I’m not sure that will always be true.
> 
> Likewise, it’s not clear to me when the callee’s SIP service might trust spam labeling from the caller’s service or some intermediary between them. I expect that we will see bad actors label everything as “government” or “health”.. There’s a mention of signing the parameters, but that’s dependent upon a hypothetical STIR extension that may or may not exist.
> 
> Perhaps the best we can do is say the callee’s service needs to use it’s own local policy to decide what to trust. Even then, do we expect at least TLS integrity protection of the spam parameters between the caller and callee services? Do we expect calling number authentication  (i.e. STIR)?
> 
> I don’t mean to say that I know what the right answers are here, but I think the security considerations need to at least document the assumptions and potential issues or vulnerabilities, especially if there’s a risk of attackers tampering with the labels.
> 
> *** Minor Comments ***
> 
> §2: Is there a reason not to use the new boilerplate from RFC 8174? There are a few lower case instances of “may”; these are ambiguous under the original 2119 boilerplate.
> 
> §3: I don’t think it is appropriate to use a normative MAY when talking about a hypothetical future passport extension that may or may not ever happen.
> 
> Also, the reference for passport (ppt) should be RFC 8225.
> 
> §4, definition of “reason”: The definition describes extended information, not the “reason” in the normal sense of the term. In particular, I would normally expect a reason phrase to be human-readable, which would have i18n considerations. Is it too late to call this something different?
> 
> §5:
> -  definition of “informational”: It’s not clear to me if the calling party is supposed to believe that a business relationship exists, or if it “is believed to” have such a relationship by whatever inserts the label. If the latter, how would it know? (This relates to my major comments about the trust model).
> 
> - definition of “spoofed”: How does this interact with STIR?
> 
> §11.2: Depending on the resolution of my major comments, the reference to 4474bis (now RFC8224) may need to be normative.
> 
> *** Editorial Comments ***
> 
> §1, 1st paragraph, “but unwanted callers may not provide their true name or use a name that
> misleads”: I suggest “... may not provide their true name or _may_ use a name that misleads...” to avoid ambiguity about whether the “not” applies to both alternatives or just the first.
> 
> §3:
> - first paragraph, "This document describes a new set of optional parameters and usage
> for the SIP [RFC3261] Call-Info header field, purpose "info", for
> labeling the nature of the call.”: I suggest ‘...with a purpose of “info...” ‘
> 
> - Third paragraph, "MAY be several Call-Info header instances”: That “MAY” seems like a statement rather than permission.
> 
> §6.2: The heading says “INVITE request”, but the contents are not an INVITE request. I assume it’s intended to be a Caller-Info header field as it might appear in an INVITE request? If so, please say that explicitly.
> 
>