Re: [stir] Questions about stir-certificates

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 23 October 2017 20:46 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 C1F0D13A273 for <stir@ietfa.amsl.com>; Mon, 23 Oct 2017 13:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Zxx5Kbq36J7b for <stir@ietfa.amsl.com>; Mon, 23 Oct 2017 13:46:24 -0700 (PDT)
Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7499D13A1F3 for <stir@ietf.org>; Mon, 23 Oct 2017 13:46:24 -0700 (PDT)
X-AuditID: 12074413-38bff70000007929-6f-59ee551ec86f
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 98.37.31017.E155EE95; Mon, 23 Oct 2017 16:46:22 -0400 (EDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v9NKkKw9011618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Oct 2017 16:46:21 -0400
To: Richard Shockey <richard@shockey.us>, "Gorman, Pierce A [CTO]" <Pierce.Gorman@sprint.com>, Chris Wendt <chris-ietf@chriswendt.net>
Cc: "stir@ietf.org" <stir@ietf.org>
References: <D60E0087.1EEE44%jon.peterson@neustar.biz> <CABkgnnV41djmwJ2A8WkLv1Qu_zxAKPb8EJnuoFS1Zeog3momyQ@mail.gmail.com> <6432f01322c74b1196075c4549f18a12@plswe13m04.ad.sprint.com> <4bbb6330-96e7-6317-cbae-07991075e776@alum.mit.edu> <171f91651e9e4a2eb7873fdbe1b9fcea@plswe13m04.ad.sprint.com> <4e1c72a3-4ae0-d424-8dfd-fff1c7049cdb@alum.mit.edu> <C0F0887C-F247-4B37-99DB-BF175943914C@chriswendt.net> <20d0f1d0-f4cc-2bed-b493-7cb4bfe746d1@alum.mit.edu> <B198E322-83DB-4507-AAAD-ABA071FDBF29@shockey.us> <d4fee7e927a7483d9f2a5fd30b161348@plswe13m04.ad.sprint.com> <7D3DAAC3-9C41-479F-BC6B-FD295F0050CC@shockey.us>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <55d7e862-f729-44a4-5d85-0938b044b8fb@alum.mit.edu>
Date: Mon, 23 Oct 2017 16:46:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <7D3DAAC3-9C41-479F-BC6B-FD295F0050CC@shockey.us>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixO6iqCsX+i7S4PJFc4vpn3YzW5z49p/R YsYPA4vla7cxObB4TOhbw+qxZMlPJo+JH88we7Rd2s0cwBLFZZOSmpNZllqkb5fAlXHlx3fG grfqFd96DrI1MN6S62Lk5JAQMJGYc3kaI4gtJLCDSeLpTZEuRi4g+yGTxK7768ESwgKmEjfO rGHrYuTgEBGYwSixIhDEZBZQlti3oAai/CeLxNG212DlbAJaEnMO/WcBqeEVsJd42OwHEmYR UJV49+wTG4gtKpAmcWfGQyYQm1dAUOLkzCcsIDangJ3E5ekL2UFsZgEziXmbHzJD2OISt57M Z4Kw5SWat85mnsAoMAtJ+ywkLbOQtMxC0rKAkWUVo1xiTmmubm5iZk5xarJucXJiXl5qka65 Xm5miV5qSukmRkiIC+9g3HVS7hCjAAejEg9vg/m7SCHWxLLiytxDjJIcTEqivL9z3kYK8SXl p1RmJBZnxBeV5qQWH2KU4GBWEuGN9AQq501JrKxKLcqHSUlzsCiJ86otUfcTEkhPLEnNTk0t SC2CycpwcChJ8H4KBmoULEpNT61Iy8wpQUgzcXCCDOcBGi4VAjK8uCAxtzgzHSJ/itGYo6fn xh8mjmczXzcwC7Hk5eelSonz5oGMEwApzSjNg5sGS1OvGMWBnhPmdQAZyANMcXDzXgGtYgJa JWv/BmRVSSJCSqqBcf1+x6YF//cW9ElwbylY9oGbw9BLIchYUfe75+eJuzP/uqfzP0yoX/67 kCUmSaortXPteb1YJT7ltPBHpkymP59c+138UDrwR96tc3s5+w4XNQm/jM7bd+7m8grzdQ1q PZHPGDvuJ/O/rv3dxac2MfL3lxfyevvsNv0zktd8dyD53C0G5r9LlViKMxINtZiLihMBAWU+ QS4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/oLB0Bu5a0SiwCKxQcdl7q8xB9us>
Subject: Re: [stir] Questions about stir-certificates
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 23 Oct 2017 20:46:27 -0000

On 10/23/17 2:48 PM, Richard Shockey wrote:
> 
> 
> +1 .. I sat in those meetings with the FTC as did Martin Dolly and Chris Wendt. This is my point that the regulators do have ligitmate concerns but are willing to be helpful without being prescriptive.  As a additional note I also recently met with the FCC folks including brother Eric Burger and they had similar concerns.

OK. That sounds promising. I look forward to seeing how it develops.

	Thanks,
	Paul

> That said we will may see some further regulatory action in the 17-97 FCC docket within 90 days or so.  Right now the industry is digesting the implications of National Number Portability which is REALLY going to have a profound effect on US call routing.
> 
>   
> 
> On 10/23/17, 2:37 PM, "stir on behalf of Gorman, Pierce A [CTO]" <stir-bounces@ietf.org on behalf of Pierce.Gorman@sprint.com> wrote:
> 
>      Paul,
>      
>      There's a letter from Janice Kopec at the Federal Trade Commission (filed as ATIS document "IPNNI-2017-00106R000.pdf") to Tom Goode, General Counsel for ATIS, where the FTC staff provided feedback and guidelines for developing SHAKEN/STIR Caller Validation Display that may provide helpful context around some of the remarks in the discussion.
>      
>      A few of the FTC comments were:
>      
>      * Design fallbacks (e.g., when technology fails or is not available for some users, how does the system react and what is communicated)
>      
>      * Warnings need to be accurate , or else users will get habituated and ignore them
>      
>      * What do full, partial, and gateway attestation translate to in plain language?
>      
>      * What are carriers able to vouch for with those data points, and with what level of confidence?  Need consistent interpretation of levels of validation.
>      
>      * How will carriers handle calls at each level of attestation, when calls fail attestation, and when attestation is absent?
>      
>      *Clearly differentiate between information about the caller ID and information about the content of the call.  Just because a call is authenticated doesn't mean the content of the call can be trusted.
>      
>      Remember that SHAKEN attestion doesn't provide anything with respect to call content and intent.  And, robocalling and spoofed caller ID are not illegal.  They're used by government agencies and charities too, not just bad actors.
>      
>      Call processing systems have a large variety of information presented to them from protocols designed by committees and interpeted by commercial programmers operating under challenging timelines and with limited resources.  Creating a stable consistent experience several millions of times a day will not be a quick achievement.  IMHO, application of SHAKEN/STIR will be permissive in the early stages, and really needs to be married to outboard analytics which look at things like network calling patterns and permit/deny lists in order to be able to render more reliable judgements to the network (or a client application) with respect to relative trustworthy-ness of a call attempt.
>      
>      -----Original Message-----
>      From: Richard Shockey [mailto:richard@shockey.us]
>      Sent: Monday, October 23, 2017 11:28 AM
>      To: Paul Kyzivat <pkyzivat@alum.mit.edu>; Chris Wendt <chris-ietf@chriswendt.net>
>      Cc: stir@ietf.org; Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>
>      Subject: Re: [stir] Questions about stir-certificates
>      
>      
>      For suitably smart devices (e.g. mobile phones) I would hope that
>          various apps and configuration options for those apps can provide the UI
>          to users. Then app providers can compete on who does it better and users
>          can choose. And these can evolve over time as the uptake on the signing
>          increases. Maybe this is what you mean by Call Analytics apps.
>      
>          It would be bad if all of this gets locked up in the FCC regulatory regime.
>      
>      RS> Paul I don’t think this is going to get locked up in a FCC/FTC OFCOM CRTC like regime but the regulators do have legitimate concerns on consistency. The regulators have actually been quite helpful here. They are willing to eventually help with consumer education if the framework for display options is simple, and I also believe there are excellent opportunities for service providers to add value.   Sometimes choice is bad and confusing the consumer with different forms of UX could cause its own problems.  Its still early.
>      
>      
>      
>      
>      ________________________________
>      
>      This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>      _______________________________________________
>      stir mailing list
>      stir@ietf.org
>      https://www.ietf.org/mailman/listinfo/stir
>      
> 
> 
>