[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?
- [stir] Notes from lunch meeting around reducing s… Cullen Jennings