SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
1.
An Abuse-Resistant
Messaging Protocol
Jim Fenton
fenton@bluepopcorn.net
1
2.
Problem
• Limits on abuse resistance of existing
general-purpose protocols
• Email, SMS, telephone
• Anti-abuse features run afoul of some use
cases
• Need to accept either collateral damage or
limits on protocol usage
2
3.
Approach
• Migrate subset of messaging use cases
• New abuse-resistant protocol
• Focus on high value use cases
• Need value for both senders and
recipients to prompt migration
(migration is hard!)
3
4.
Value
• Moving messaging to an abuse-resistant
protocol decreases fraud
• Messages sent using legacy protocols
eventually become “suspicious”
• Narrower protocol may also better serve
certain use cases
4
7.
Desired Characteristics
• Recipient:
• Opt-in only
• Prioritized
• Authenticated
• Expire or deleted
when not relevant
• Timely
• Unsubscribable
• Configurable “push"
• Sender:
• Receipt confirmation
• Intermediaries not
needed
• Possible with modest
originator, e.g. IoT
• Update or delete
7
8.
What is a Nōtif?
• Nōtif : notification :: app : application
• Tell a user that something they’re
interested in is happening or has happened
• Requested by the user
• Typically time-sensitive, perishable
8
9.
What a Nōtif isn’t
• Anything unsolicited
• correspondence
• spam
• Addressed by a human
• addresses are unsuitable for that
• Two-way
• Multihop
9
10.
Nōtifs Manifesto
• Users:
• Should have control over what nōtifs they receive
• Should be able to know that the nōtifs they receive are genuine
• Should have control over if and how they are alerted when
nōtifs arrive
• Should not have to reveal information about themselves just to
receive nōtifs
• Notifiers:
• Should not have to guess whether nōtifs are being delivered
• Should not have to employ intermediaries to get nōtifs delivered
• Should be able to amend or delete nōtifs to keep them relevant
• Nōtifs:
• Should expire and hide when no longer relevant
10
11.
Notifiers
Agent
User endpoints
Notification
Agent
Phone
CallSMS,
App push
Growl
Management,
Authorization
Notifications
Authorization Table
Rules
Bank Emergency
Services
RetailersSocial Media
Approval
Requests
Calendar
11
12.
Notifiers
• Typically not operated
by user
• Opt-in by user through
authorization ceremony
• May or may not know
much about the user
• Examples:
• Emergency services
• E-Commerce sites
• Social media
• Enterprise services
• Reminders
• IoT sensors
12
13.
Nōtif Agents
• Operate on behalf of
user
• Cloud-based
• User-chosen,
decentralized
• Store notifications for
retrieval by user
• Manage authorizations
for user
• Analogous to last-hop
MTA/MDA
• Alert user to specific
notifications of
particular interest or
urgency
13
14.
User endpoints
• Push
• Mobile device app
(push notification)
• SMS
• Voice (telephone)
• Desktop app
• Email (!)
• Pull
• Web interface
• Email-like (IMAP)
• Mobile app (via future
API)
14
15.
Nōtif Authorizations
• A record of a relationship between a notifier and a user
• Contains:
• Notification address
• Notifier’s domain
• Description (provided/edited by user)
• Max authorized priority
• Tags
• Flags (active, deleted, etc.)
• Statistics (count, etc.)
• Link to user (internal)
15
32.
Protected Header
• Public key from DNS TXT record ala DKIM
• Algorithm must agree with that specified by key
record
{"alg": “RS256",
"kid": "shiny"}
Public key obtained from DNS:
<kid>._domainkey.<notifier-domain>
Signing and hashing algorithms
32
33.
Nōtif Body
• You can’t spoof what isn’t there:
• From address/domain (comes from
authorization)
• To address (part of the envelope)
{"origtime": “2015-04-04T16:17:00.242181Z",
"priority": 4,
"expires": “2015-04-05T16:17:00.242193Z",
"body": "It is now 09:17 and all is well”,
"subject": "It is now 09:17"}
33
0 likes
Be the first to like this
Views
Total views
308
On SlideShare
0
From Embeds
0
Number of Embeds
16
You have now unlocked unlimited access to 20M+ documents!
Unlimited Reading
Learn faster and smarter from top experts
Unlimited Downloading
Download to take your learnings offline and on the go
You also get free access to Scribd!
Instant access to millions of ebooks, audiobooks, magazines, podcasts and more.
Read and listen offline with any device.
Free access to premium services like Tuneln, Mubi and more.