[stir] Notes from lunch meeting around reducing spam

Cullen Jennings <fluffy@iii.ca> Thu, 22 March 2018 16:40 UTC

Return-Path: <fluffy@iii.ca>
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 E31651200A0 for <stir@ietfa.amsl.com>; Thu, 22 Mar 2018 09:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RAObAFZhxMRp for <stir@ietfa.amsl.com>; Thu, 22 Mar 2018 09:40:38 -0700 (PDT)
Received: from smtp66.ord1c.emailsrvr.com (smtp66.ord1c.emailsrvr.com [108.166.43.66]) (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 17117124B17 for <stir@ietf.org>; Thu, 22 Mar 2018 09:40:37 -0700 (PDT)
Received: from smtp17.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 373CA607AD for <stir@ietf.org>; Thu, 22 Mar 2018 12:40:37 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C30A5607A0 for <stir@ietf.org>; Thu, 22 Mar 2018 12:40:36 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.61.212.241] ([UNAVAILABLE]. [173.38.220.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Thu, 22 Mar 2018 12:40:37 -0400
From: Cullen Jennings <fluffy@iii.ca>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <5241C8E9-C886-4373-84ED-CA57D23DA733@iii.ca>
Date: Thu, 22 Mar 2018 16:40:43 +0000
To: stir@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/DGcg_QipzrWm4uoH-F3BpLmCHOs>
Subject: [stir] Notes from lunch meeting around reducing spam
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: Thu, 22 Mar 2018 16:40:40 -0000

Huge thanks to Mat Miller for taking notes. 


SIPCOIN/CALLBACK Side Meeting

* Hilton Meeting Rooms 1-4
* 2018-03-22 T 12:15:00

 We had 16 people. 

======== SIPCOIN ========
DISCLOSURES

* There is IPR on SIPCoin draft, will be posted
* other prior art (hashcash, for email then phone)
  - The compute time is too long for typical use


OVERVIEW

* mint a coin ahead of time
* burn a coin at use
* posted to a CA for verification by signing block
* merkle tree to track history efficiently


IETF responsible for determining value
- WG? document?
- robocallers packing the WG?
- not possible/feasible for such an org

COMPUTE

* bitcoin is competitive mining
* assumption is robocalls will use most optimal equip (ASICs)
* less compute --> less coins
* going with "unresistant" models that favor ASICs is ok
  - ASICs needed for buy-in
  - (ots ASCIs, cloud service in Iceland, etc)

BREAKING IT

* centralized email spam mitigations <-- more centralized services
  - email spammers: central advertiser contracts with smaller ops, who contracts with smaller ops et al .... who operates botnets
  - small players see bits, and money filters down

ALTERNATIVES

The idea is make the problem an economics one
* SIPCoin is one
* donations to LE or other foundations

rather than community-based, make it regulatory
  - pay penalties if you're not doing STIR
  - big carriers cannot legally force downstream to comply (needs to be regulators)

if PASSPOrT goes to edges, then leave it to ends to force compliance laws cannot:
* bond on the phone number holder
* who will issue the bond? (financial incentives?)
  - carrier bonding --> deal with legal but incentivized?
  - ends bonding --> not sure

* problem starts to mitigates with verified source (STIR)
  - PSTN is the biggest problem
  - SIP has more leverage

* traceability works for post-facto (forensics), but not real-time
  - may only work for robocalls if high value victim (e.g., Senator) 

* total solution involves multiple factors (relevance scores)
  - find the knobs to turn the costs up for spammers

CHALLENGES

* cost on acquiring numbers vs impersonation
* cheap/free gateways also complicate (e.g, Skype, Twilio, Tropo, etc)
  - banks of numbers --> spammers mixed into legitimate callers

* phone calling margins are tightening (??)
* all carriers have to offer call blocking services (via FCC)
  - Opt-in, centralized SIP app analyzing
  - works really well
  - e.g., COMCAST -- NoMoRobo
  - carrier cost is very very low (so far)
  - still based on unverified reported numbers (spammers can adapt)
* honeypots and heuristics interesting
  - could be an economic disincentive 

FOLLOW UPS

* FCC motivated for solutions
* research validation
  - Barbara van Schewick
  - Moz Foundation for more contacts

* Mark and Jon to help continue it
* how to bootstrap?

======== CALLBACK ========

OVERVIEW
* callee calls back the caller (no dial)
  - verify the callers really made the call

* each agent builds up cache of certs found

QUESTIONS

ASSUMPTION

* validation on cert (by accepted CA), not on the identity per-se

CHALLENGES

* if the middle is not SIP (e.g., SS7)
  - OOB is solving this (designed for smart end-points)
  - might also trickle into SHAKEN
  - OOB still assumes 8226 cert

* More work on the gateways (SIP terminations)
  - put something in front-end to do this
  - also not yet doing STIR (?)
  - out-of-band made for this issue

* deployment ()?
  - STIR is a set of tools
  - work in ACME to define proofs et al (for PASSPOrT)
  - to start, agreement on what the CAs are
  - this will get shaken out over the next year or so
  
FOLLOW UPS

* look for a distributed technique to generate certs that are combined over the top?