2018 update on the state of Notifs, an anti-abuse messaging protocol for notifications

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

5. Proposed use case:
Notifications
5

6. 6

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

16. Authorizing
16

17. Authorizing - 2
17

18. Authorizing - 3
18

19. Nōtif Summary
19

20. Nōtif Detail
20

21. Nōtif (IMAP)
21

22. Authorization Summary
22

23. Authorization
23

24. Methods
24

25. Alert Rules
25

26. Current status
• Prototype Nōtif agent up and running
• Linux/PostgreSQL/Go
• Prototype user/authorization/nōtif management
• Linux/PostgreSQL/Python/Django
• Notifier SDK (Python)
• Sample “clockwatcher” notifier running
• Available on GitHub!
26

27. Under development
• Generate notifs from tweets
• IMAP gateway
• Connectors: Generate notifs from other
services
27

28. Backup Slides
28

29. Notification examples
• Emergency bulletins
• Advertising / special
offers
• Event invitations
• Approval requests
• Tech support
• Password resets
• Fraud alerts (bank, etc.)
• Alerts from
“things” (IoT)
• Newsletter availability
• Social media alerts
• Burglar/fire alarms
29

30. Nōtif characteristics
• Opt-in
• Typically short
• Modifiable/deletable (best effort)
• Acknowledged delivery
• Domain-signed
• Encrypted in transit (use TLS)
• Priority tagged
• Expires at specified date/time
30

31. Typical Nōtif
{"header": {"to": “d28363d7-9d28-49f2-8d5b-
b9c1cf989335@altmode.net:5342"},
"payload": “eyJhbGciOiAiUlMyNTYiLCAia2lkIjogInNoaW55In0.
eyJvcmlndGltZSI6ICIyMDE1LTA0LTA0VDE2OjE3OjAwLjI0MjE4MVoiLC
AicHJpb3JpdHkiOiA0LCAiZXhwaXJlcyI6ICIyMDE1LTA0LTA0VDE2OjE3
OjAwLjI0MjE5M1oiLCAiYm9keSI6ICJJdCBpcyBub3cgMDk6MTcgYW5kIG
FsbCBpcyB3ZWxsIiwgInN1YmplY3QiOiAiSXQgaXMgbm93IDA5OjE3In0.
MVXxsqrqc6XQm2gkVgatmHC847JEBxg0eR4LSmsUsTpMAwWgZ7dKQ_Wk_Q
K0It0aibj4qVdnJbs1MY6IwV7rqJMsSbzuZ7n_QDn_OKjI2L_rPq9IsW7z
EUtwf2T1J1j9yfWX0zmXwqSxdqnFHNcv49S7eDPrEhlvIMLtixHDOjk"}
Protected header
Unprotected header
Payload
Signature
Now in JWS format!
31

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