[stir] WG LC Comments: draft-ietf-stir-oob-04

Eric Burger <eburger@standardstrack.com> Tue, 16 April 2019 15:59 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 88B061207CB for <stir@ietfa.amsl.com>; Tue, 16 Apr 2019 08:59:45 -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 X5te7Lk0qJmr for <stir@ietfa.amsl.com>; Tue, 16 Apr 2019 08:59:44 -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 706181207FA for <stir@ietf.org>; Tue, 16 Apr 2019 08:06:09 -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=5x59jcq4z6ykzE/6ugHix8lpI5wAsMhO4Iz/v6PPdWI=; b=jz+uOmVdmpeEJaJe75rw1mfBBV TEstXBoG9kni9+s1WG/fCA22ARocANBOKmyyzib9U46grTVQ5NFbtl/nrmD2LibfMCXmh9rpquCbY TlAal9IzxyEt2aD6contrkNxPddVWGwXu2G12GJwmS0W5/OUkaVLnAreTThiskutlyIQ=;
Received: from [] (port=50242 helo=[]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <eburger@standardstrack.com>) id 1hGPer-00D2gy-M0 for stir@ietf.org; Tue, 16 Apr 2019 08:06:06 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_68284805-866C-47E5-A42D-195D2CD63976"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <7E25361F-D726-440F-A77A-332BB97AC77A@standardstrack.com>
Date: Tue, 16 Apr 2019 11:05:59 -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/4pmuaHqV_RZw0XzbAffHVdVisDo>
Subject: [stir] WG LC Comments: draft-ietf-stir-oob-04
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:59:45 -0000

Section 11:
It looks like there was going to be a list of discovery requirements and considerations for credential discovery, but there’s just a blank space.  There is an element of “and then a miracle occurs” which is a bit disturbing.

Section 10 and Section 5.4:
Also “a miracle occurs” moment in how to find a CPS.

Section 6.1:
Where do the public keys come from? This also means lots of crypto work for the caller. This could be a benefit, namely requiring a proof of work to place a phone call. Although, it could be more efficient to charge some fraction of bitcoin in lieu of proof of work ;-)

Section 5.5:
This scheme totally fails for a call center or enterprise that just uses a single number for all (or many) outbound calls. They will all have the same source address.

Section 5.3:
Should note that the receiver will need to query every call that does not have a PASSporT attached.

Section 5.2:
Should note that the sender will have to deposit a PASSporT for *every* call placed. Likewise, the receiver will have to attempt to retrieve a PASSporT for *every* call received without a PASSporT attached.

Section 5.1:
Should note that the gateway will have to deposit a PASSporT for *every* call through the gateway, irrespective of receiver’s capabilities.

Section 14:
Should note this mechanism adds a ton of vectors for things to go wrong. As well, while the From identification is nominally encrypted, simple traffic analysis will give up most of the privacy provisions.

Nit: top of page 13:
PSTN mechanisms for relying a calling party
PSTN mechanisms for relaying a calling party