Re: [stir] WGLC: draft-ietf-stir-cert-delegation-02

Russ Housley <housley@vigilsec.com> Thu, 12 March 2020 21:29 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0238F3A046D for <stir@ietfa.amsl.com>; Thu, 12 Mar 2020 14:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Ue-tk4kVTDe8 for <stir@ietfa.amsl.com>; Thu, 12 Mar 2020 14:29:55 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960A23A041E for <stir@ietf.org>; Thu, 12 Mar 2020 14:29:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3F724300B02 for <stir@ietf.org>; Thu, 12 Mar 2020 17:29:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7Xo3UX0DDzTV for <stir@ietf.org>; Thu, 12 Mar 2020 17:29:51 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 974AA300A02 for <stir@ietf.org>; Thu, 12 Mar 2020 17:29:51 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BE7D2593-0CF0-472B-9F4D-6F6760E44C34"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Mar 2020 17:29:52 -0400
References: <bb76518f-3373-1368-d2d2-0959f7894e2b@nostrum.com>
To: IETF STIR Mail List <stir@ietf.org>
In-Reply-To: <bb76518f-3373-1368-d2d2-0959f7894e2b@nostrum.com>
Message-Id: <54D85CFD-6F90-4953-B103-F020C1FD4424@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/HNu-FfhcPfdyEfb1zoATwcFnuCQ>
Subject: Re: [stir] WGLC: draft-ietf-stir-cert-delegation-02
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: Thu, 12 Mar 2020 21:29:59 -0000

The US FCC released a document earlier this week: https://docs.fcc.gov/public/attachments/DOC-362932A1.pdf <https://docs.fcc.gov/public/attachments/DOC-362932A1.pdf>

This part is relevant to this document (it is arguing that STIR/SHAKEN is ready for mandatory implementation):

    We disagree with those commenters who argue that we should not move
    forward with a STIR/SHAKEN implementation mandate.  First, we
    specifically disagree with the argument that we should delay a
    mandate while industry develops technical solutions to allow the
    STIR/SHAKEN framework to accommodate certain more challenging
    scenarios.  According to some commenters, the standards for
    attestation do not fully account for the situation where an
    enterprise subscriber places outbound calls through a voice service
    provider other than the voice service provider that assigned the
    telephone number.  In such scenarios, commenters claim, it would be
    difficult for an outbound call to receive "full" or "A" attestation
    because the outbound call will not pass through the authentication
    service of the voice service provider that controls the numbering
    resource.  We are optimistic that standards bodies, which remain
    engaged on the impact of STIR/SHAKEN on more challenging use cases
    and business models, will be able to resolve those issues just as
    they have overcome numerous other barriers to caller ID
    authentication so far.  For instance, the Internet Engineering Task
    Force (IETF) has proposed a certificate delegation solution that
    would allow the carrier who controls the numbering resource to
    delegate a credential that could be used to sign calls regardless
    of which  network or administrative domain handles the outbound
    routing for the call.  Further, granting a delay until standards
    bodies address every possible issue would risk creating an
    incentive for some parties to draw out standards-setting processes,
    to the detriment of widespread STIR/SHAKEN implementation.  In any
    event, the TRACED Act requires that voice service providers
    implement the STIR/SHAKEN framework in their IP networks and so
    the point is moot.
    
Russ

> On Mar 11, 2020, at 12:11 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
> 
> This is a Working Group Last Call for draft-ietf-stir-cert-delegation-02
> 
> Please send your comments to the list or the chairs by Wed Apr 1. (This LC is three weeks because of the proximity to the IETF 107 week).
> 
> RjS
>