automatic end to end email encryption with "inline keys"
holger krekel, Cologne, OpenPGPConf July 2016
on me
- python dev and trainer since 2000, tons of FOSS
- studied cryptography with the Pfitzmanns
- past EU projects PyPy and PYJIT
- mailwitness (digital email signature network)
- now NEXTLEAP EU project decentralized messaging
- living in Freiburg, fathering a 5yo
email refuses to die
- largest federated open social messagging network
- anchors identity in FB, Android, amazon, paypal, ...
- federation makes it harder to achieve encryption
- BUT: many use it "only for spam and work"
repowering email
- better email clients: more motivation and money!
- automatic encryption by default: please!
- using it to anchor new decentralized systems: yes!
email encryption hard problems
- useability: key distribution
- useability: preventing spam
- useability: managing secrets, multi-device
- useability: device/key loss
key distribution schemes
- provider: CONIKS, Webkey, mailvelope, DANE
- inline: attach keys and crypto-info to mails
provider managed schemes
- complex: providers need to extend their ops
- spammable: public key lookup -> encrypted spam
- inertia: MUAs devs & providers need to move jointly
"public key" lookups
"Words don't express what we think, they tell us what to think."
from Gene Youngblood, "Secession from the broadcast" lecture 2012, Buenos Aires.
inline keys basics
- attach keys along messages (header and/or body)
- parse keys from message, encrypt next time
- without reply the other side can't encrypt
- also discussed as "keyserver-less" at pgpsummit
"inline keys" in September 2016
- is a research direction
- many ongoing discussions (~10 people so far)
- concrete protocol draft planned for 2016
inline keys features
- private: no public lookup of public keys (hah!)
- simpler: require support only from MUAs
- no-spam: first cleartext msgs help spam-detection
- safe: if done right, providers can't easily cheat/MITM
attaching keys
- attach keys to MIME standardized but ambiguous
- MUAs can not reliably interpret attached keys
- we need a protocol, not just a data format
no-spam
- first messages cleartext: good for spam detection!
- if you reply to spam, they get your public key
- spammers will not easily get keys from providers
- probably can do key-rotation often (monthly)
inline key protocol constraints
- only depend on MUA changes
- can only amend regular email messages
- hide key management from default users
- but ok to rely on out-of-band ultimately
inline key safety
- DKIM helps to detect mailicious providers
- crypto protocol can provide additional protection
- out-of-band verification (for activists)
- more encrypted emails avoid activist detection!
judge security by actual collective outcome (Saitta)
inline key distribution options
- always insert key into header/body ...
- or just announce capabilities?
- use per user-pair keys?
- amenable to do forward secrecy
inline key protocol/crypto options
- reply to encrypted mail sends hash of what we saw
- when CCing people MUA could attach keys it knows
- revocation could happen over existing SKS infra
- not associate email/key in key material?
managing secrets options
- sync encrypted secrets via IMAP (see whiteout)
- use per-device keys (like apple does)
- external key storage (cards, usb, ...)
- key loss needs to be conveniently handled anyway!
other useability problems
- if i use two MUA & only one supports <protocol>
- can we distinguish devops problems from cheating?
- how to explain "public key" if we need to?
- ...
next steps for developing inline keys protocol
- develop proven protocols with cryptographers
- do sessions/work with MUA/plugin developers
- do IETF draft for MUA interop on encryption
- use early prototypes ourselves
anchoring new decentralized services?
- announcing e.g. ZCASH, crypto-IM addresses
- solves the "human readable ID" problem
- mobile mail apps to answer crypto address queries?
- protocol should give room to experiments!