Summit 2019 Notes

This page documents the notes that were taken during the 5th OpenPGP Email Summit which took place 2019-10-12/13.

Plenary talks

Patrick discussed future of Enigmail and Thunderbird

• enigmail is going away (except for postbox)ox)ox)ox)
• thunderbird will build in openpgp support as a peer of S/MIME support
• timeline is short -- identifying crypto library is a blocker at the moment -- language + licensing are the biggest concerns
• most likely at the moment sounds like Botan + RNP

Andre talks about GnuPG plans and updates

• 2.3.0 is expected to be released 20 December
  • Biggest work in progress is the keyring daemon
• they'll have a local office in Duesseldorf soon
• they're working on organizational/institutional support

Holger presents deltachat -- implementation and status

• cross-platform implementations (iOS is biggest blocker)
• verified groups
• verification
• upcoming:
  • Burner accounts
  • ed25519 upgrade for keyskeys
  • chat bots
  • mime-parser cleanup and review
  • rPGP improvements and parsing

Workshops

Workshop: How to approach UX Decisions

• Quick round how do people approach UX issues, how are decisions made, are there dedicated people working on it?
  • Some teams had dedicated UX people, worked with universities on structured studies
  • Some had dedicated "special users" who they regularly sought feedback from
  • Others were more ad-hoc: shoulder-surfing, feedback from users

• You can learn UX Design, it's a good problem solving tool.

• Eileen: Don't armchair problems, go out and ask people.

• Eileen introduces personas: helps you be empathetic. AKA a more personalized form of threat modelling. Sounds vague at first, will get more concrete when you "flesh it" out.

• A persona is a sketch of a person.
• A couple of bullet points about a person, based on reality
  • Demographics, but also how they might use the software
  • What are their hobbies, their family? Help with empathy.
  • What is their intent, what do they want to achieve
  • A more generic form of threat modeling

• UX testing doesn't have to be complicated, start with pen&paper and ask people if they can make sense of your drawings.

• Based on groups of personas you can build user stories: X wants to do Y to achieve Z.

• Break-away, into pairs, developing our own personas for our projects, discussion...

• The need for too many users is often a sign that you're doing too much at once (which probably won't make anyone happy).

• Having only 3 personas can also lead to doing to much at once.

• Hacker as a persona: do we need to design for them? They can build their own thing? But they are often quite vocal (loud), maybe support the project financially or technically. But often don't even actually need encryption tools, don't have a threat model, want encryption for the sake of it.

• The question is not: how can we simplify things. It is: how can we make it work better for the persona we're thinking about. For a hacker persona that could actually mean a lot of configuration options.

• Problem: immature projects have more hacker/tech-savvy users, even if the target would be more mainstream. Changing the interface would repeal them. Maybe leaving hackers behind is ok, they will be able to care for themselves. Reaching the "mainstream" is hard, though, you can get stuck on the way.

• A challenge: reacting to user feedback from a vocal minority, e.g. power users who know about GitHub issues. How to meet and talk to people who are not already "hackers"?

• A persona is a sketch of a person, a scenario is a sketch of a situation/use-case.

• Personas are beautiful, use personas for your software: : ​​​​​​​https://simplysecure.org/resources/persona-template-security.pdf

• Probably bad example from GnuPG of personas and user stories: https://wiki.gnupg.org/EasyGpg2016/VisionAndStories

• More resources:
  • UI Heuristics (NN Group, 1994): https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/cles/how-to-conduct-a-heuristic-evaluation/t-a-heuristic-evaluation/cles/how-to-conduct-a-heuristic-evaluation/
  • Formative Testing (Tails interview): https://simplysecure.org/blog/formative-testingistic-evaluation/rmative Testing (Tails interview): https://simplysecure.org/blog/formative-testingistic-evaluation/
  • Example of Tails personas: https://tails.boum.org/contribute/personas/
  • NoScript Case Study (Designing for power users): https://simplysecure.org/blog/noscript-case-study/blog/noscript-case-study
  • Some templates for UX beginners: https://simplysecure.org/ux-starter-pack/

Workshop: OpenPGP Standardization (RFC4880bis)

IETF started standardizing RFC 4880 bis, but the perspective is not clear. Many are waiting for a full standard before implementing, but this is stalling the standard efforts: many open questions, without a roadmap. Should we push and get a standard out of the door?

Deciding curves and standards

In order to continue we could get a set of test vectors and some working implementations for the necomers

It is difficult to chose a set of curves that can be defined as a "minimal subset".

There exists already a subset of GPG: https://github.com/boring-pgp/spec

It is difficult to deprecate stuff, as you would need to provide a library to decrypt these algorithms, but not encrypt with them. The best step to deprecate could be to just replace the asymmetric primitives with more modern ones "fairly cheaply". This could be done with a compat lib. Deprecation would create a lot of friction, in order to add it to the RFC.

Regarding RFC4880bis it could be a minimal document, e.g. with only one curve, with a subset that requires the least amount of arguing, and could have the best chance to get the consensus. People can still support a superset for the satandard. Different people are already using a variety of curves, and will want to keep them.

In RFC 4880 there is already a "good bits" subset, and RFC 4880bis-08 has a "Compatibility Profiles" section.

AEAD

Since there was no legitimate streaming crypto in PGP, so it could be split onto a new RFC, that should take care individually of the AEAD chunking problem. This will have a dedicated team to tackle this issue. (The code points, i.e. assigned numbers = IDs, could be reserved for future use, for then to be added separately, as it is not a refresh of the current standard)

Removing chunking right now could on the other hand could break many existing messages, because it has been in the draft for a while. It could be used to preview emails.

Follow ups

• Streaming, random access w.r.t. chunking of symmetrically encrypted data
• How to break the impasse of releasing the new RFC
• later work as separated drafts (e.g. privacy issues, attestation signatures)

Strategic questions w.r.t. IETF workflows for a new RFC4880bis

• Deprecation of items (IDs; assigned numbers for packet tags, algorithms)
• adding more test vectors to improve interoperatibility
• AEAD chunk size limit issue (almost solved on mailing list with compromise)
• AEAD as a replacement for MDC; maybe without chunking to make cryptographers happy
• good for IETF process: demonstrated consensus on the mailing list, not only exchange of arguments
• authorship of part of the new document; showing effort and participation in the working group (WG)

Workshop: key distribution mechanims interaction in clients

https://download.sumptuouscapital.com/tmp/20191012_144832.jpg

Quick overview of key dist mechs:

• manual download from a Web site
• email attachement
• local trust store - already exists
• sneakernet
• WKD - domain specific directory, key for that domain
• sks keyservers
• public validating keyservers - server validates key first
• DANE/OpenPGPkey - cert is in the DNS, signed with DNSSEC
• LDAP
• AutoCrypt - keys in headers
• AutoCrypt Gossip - keys of other recipients in headers
• out-of-band, e.g. signal
• keybase
• namecoin
• pep - similar to email attachement
• vvv - we don't really know what this is but it is a thing - fairly close to some other things in this list - not know to be used/software exists - https://keys4all.de/media/beschreibung-vvv-loesung.pdf
• OS/system keystore (Debian package)
• email round-trip - explicitly ask for key

How do we deal with presenting/combinging all these?

Critiria to care about:

• opennes
• uploading opennes
• network/data protocols
• metadata leakage
• scoping
• api - what do get back
• maintenance

e.g. of how these are done:

• detect from all, give option to add to local trust store
• on send local trust store takes precedence, wkd and local keyserver fallback, further (future) fallback to verifying keyserver

gnupg:

• local keystore, wkd fallback
  • prioritisation as well, web-of-trust
• more can be configured
• grouping and prioritisation by source

mailpile:

• local keystore, attachments, autocrypt headers, things which can be done over tor: wkd, validating keyserver
  • ranking of multiple results
• dane not open enough for ppl to participate

mailfence:

• user keystore easily importable, import from sks (to be removed), future maybe wkd & validating

Small discussion on whether sks still has any future Validating keyserver needs regular checks to the keyserver, not just initial fetch Users will trust the first sks result, but implementations can not. Users will just choose the newest key. Key history could allow better ranking, identify keys which are not wrong but old, ignore the source as a quality signal. counterpoint: WKD is organisational so can be preferred, validating keyserver is a fallback if organisation does not support wkd there's a tension between solutions that providers want to support vs end devices which want to work with any provider

More info on the rating systems for keys use would be nice! Please add below.

Workshop: OpenPGP implementations

What are the ones we know? (Should we separate OpenPGP from cryptographic libraries in general?)

• rPGP (pure rust) - https://github.com/rpgp/rpgp , dual licensed Apache/MIT
• RNP (C API, C++, botan)
• GnuPG (C, libgcrypt, with bindings)
• OpenPGP.js (javascript)
• pgpy (python)py (python)
• go-openpgp (go)
• netpgp (C, openssl)
• LibTMCG (C++, libgcrypt + (botan); experimental feature), used by DKGPG - https://www.nongnu.org/libtmcg
• Previous attempts
  • GnuPG ME didn't have the right parsers
  • RNP, C++ library derived from NetGPG
  • NewPG, former GnuPG dev reducing size of codebase
  • See more: https://www.openpgp.org/software/developer

What are criteria to compare libraries/implementations? <1> easy <2> a bit harder <3> hard <4> really hard to determine

• What standard operations can you do with the protocol? If it's a more limited set of options, then added security but limited usage scenarios. What is exposed to the user/developer?
• API completeness/ compliance to standard (RFC) <4>
• Portability <1>
• Dependency chain of the libraries <2>
• Active maintainers & feedback loop <1>
• Documentation <1>
• Is there any key storage and how secure is the storage?
• Language bindings <1>
• Test cases for your own testing, demo code <2>
• Reviews and audits <2>

Core features of OpenPGP: key generation, decrypt/encrypt, verify / generate signatures, key signing, trust management

Key storage, does it have a standard format? What are security requirements for that? See OpenSSL comparision on Wikipedia

Workshop: Key Transparency

https://docs.google.com/presentation/d/1wtzwbto1cvImx1vBnkXtul3WAhYnLnZej81dKjnP2pc/edit?usp=sharing

CONIKS like. Put the hash of the root into CT-log

Goal: Prevent a key-server from lying about the binding of an ID to a key first-use scenario of a key requires less trust, because the operator leaves publicly verifiable proofs

Merkle-tree of all the keys a key-server has

users need to check the tree regularly for the integrity of their own key

each operator has their key transparency tree but could that be shared among operators? but then you get malicious actors messing with the tree. whitelisting entities who are able to add to the tree might be a solution.

we could standardise the protocol, e.g. how to actually make a lookup

WKD: Could sign outgoing keys to have a transferrable assertion that someone served a key at a given time

protonmail's mechanism could probably be ported to other validating key servers like Hagrid

Workshop: OpenPGP device syncronization

what kind of users and which type of device we want to sync?

what does it mean syncronization? let's map needs and concerns

• needs: we need to be able to sync privkey but at least privkey
• needs: verify sender and integrity
• do we need to read history? email are not messenger, users needs to read old emails
• device should have the same capabilities
• syncronization can be multiple and different - what are the specific we need?
• main concern is on user needs, if mail client is used for e-commerce we dont actually need to sync

3 macro challenges

1. historic access to content (e.g. old mails)
2. crypto capabilities (verify a msg, sign, encrypt, decrypt)
3. message status integrity

What is a key? 1 OpenPGP certificate can have multiple keys!

WE AGREE that we don't want individual certificates for each device. (maybe.)

how to do it?

sec subkeys per device

• encrypt the msg for all the subkey of a personal certificate
• using hw sec key use-case to sync privkey

let's back, why we need it?

- the main certificate need to be sync to ease user to communicate

what do we want to archive? - es. gov resistant on border and having multiple device, sync device with different keys

>> We need multible personas here, and they have quite a range!

We're defining synchronization: how do we make all of our devices to do the same things?

user preferences - user may want to see the msg in the same way on all devices

make sync working only for new user it's fair to exclude privkey import Primary vs secondary device: no, we AGREE all the device will share same power once linked the device are sharing same msgs, config, preferences autocrypt has a setup-msg verification we can use

important challenge : device injection > we need to keep in mind but solution is difficult

transport

1. sync points
2. sync protocol (maybe not imap)