[stir] WG LC Comments: draft-ietf-stir-passport-divert-05

Eric Burger <eburger@standardstrack.com> Tue, 16 April 2019 15:55 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6E92612096D for <stir@ietfa.amsl.com>; Tue, 16 Apr 2019 08:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zkxP39oTPVZk for <stir@ietfa.amsl.com>; Tue, 16 Apr 2019 08:55:31 -0700 (PDT)
Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82438120777 for <stir@ietf.org>; Tue, 16 Apr 2019 07:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:Date:Message-Id:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1sasyTzKMVUMRR3+76OaCtcR9aXHyEvLKd8zAjHA0J8=; b=n+Wmq9O1dP/nO5y8iGX0UORoqm R7vtuOE11w/E9ds7f/W/e1jeyTxsDMbGFoxNioplpNpiI/VSJEaPDnBL6UY0S/R0mLIaUuqj2W+tn /zs2VLeg96pXobs/yYatHKI9cgToX7Jg85nkWnkYdq0q/W5T4EhY3pUkJB/WxG9Mv1mU=;
Received: from [] (port=50053 helo=[]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <eburger@standardstrack.com>) id 1hGPQh-00ByDz-Gp for stir@ietf.org; Tue, 16 Apr 2019 07:51:28 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_FC2EAC01-91DC-43DD-AE44-F36C4E4E5058"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <9536C2D6-A6EF-48B2-858D-10232CCA028E@standardstrack.com>
Date: Tue, 16 Apr 2019 10:51:22 -0400
To: stir@ietf.org
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/CAppHRpKT36RlzhPZofgNCmvOGc>
Subject: [stir] WG LC Comments: draft-ietf-stir-passport-divert-05
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2019 15:55:38 -0000

Most of my comments and nits have been identified and mostly addressed already. Here’s what’s ‘new’:

Section 4.1:
Is there a scenario where the terminating verification service WOULD NOT do verification? There’s a bunch of text on how the diverting platform might or might not do verification and the terminating platform might or might not do verification.

Would it not be better to point out the diverting platform would really, really, really (SHOULD?) want to verify the inbound call, because it will be the reputation of the diverting platform on the line if it signs the diversion on a bad call?

Conversely, why would any terminating provider EVER trust a diversion from a PBX? I.e., would not a terminating provider really, really, really (SHOULD?) want to verify all of the signatures in the chain?

Towards the end of 4.1 we talk about RPH. Is there any issue of forwarding an RPH call? One would think that once a priority call hits a PBX, it will lose its priority. I am not stating a fact that I know, but for those in the RPH world, what is your understanding? Also, this paragraph is dense and a bit confusing. An example would go a long way in providing clarity.

Section 4.2:
Why would a failure in the verification chain EVER result in anything other than a failed verification, other than the obvious, “the certificate expired three minutes ago”? Remember, MAY = Never Will Happen.

Section 4.2, Fifth step
What is a “multiple based PASSporTs”?

Section 5:
As Ben pointed out in his review, div-o seems to be a different beast that might better be addressed in a separate document. In fact, if the only purpose of it is to support OOB, I would insist it go into a separate document. Conversely, if div-o will be the mechanism to support TN-PoP, then say so. Of course, if that is what div-o is about, again perhaps it would be better served in a separate document or as part of the eventual mechanism that allows the originating caller to sign a call (classic STIR) as well as an authentication service signing the call (SHAKEN).

Section 7:
Why would we EVER allow a caller to pickup a signature from a 302 redirecting server? The text goes to great lengths to explain *how* to do it, but never says *why*. I’m having trouble groking the use case. A spammer sends INVITEs to a number, gets back a (set of) signed PASSporTs to include in their spam calls? Why would I ever care if the spammer found my current contact from a redirect from a registrar instead of guessing my current contact directly? Is there a double-secret use case hiding here?

Section [Missing]: Privacy Considerations
Sprinkled throughout the document are privacy considerations, like how this mechanism is inappropriate for anonymization services (see, e.g., the last paragraph of Section 4.2).