Summit 2019 Notes

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

Contents

  1. Summit 2019 Notes
    1. Plenary talks
      1. Patrick discussed future of Enigmail and Thunderbird
      2. Andre talks about GnuPG plans and updates
      3. Holger presents deltachat -- implementation and status
    2. Workshops
      1. Workshop: How to approach UX Decisions
      2. Workshop: OpenPGP Standardization (RFC4880bis)
      3. Workshop: key distribution mechanims interaction in clients
      4. Workshop: OpenPGP implementations
      5. Workshop: Key Transparency
      6. Workshop: OpenPGP device syncronization
      7. Workshop: Thunderbird & OpenPGP
      8. Workshop: Validation of Digital Signatures
      9. Workshop: Mail test suite
      10. Workshop: What we learned from EFAIL
      11. Workshop: Mail STS
      12. Workshop: WKD
      13. Workshop: Future of SKS Keyservers
      14. ​Workshop: Symmetric key​​​​​​ re-encryption of archived ​​​​​​​mail

Plenary talks

Patrick discussed future of Enigmail and Thunderbird

Andre talks about GnuPG plans and updates

Holger presents deltachat -- implementation and status

Workshops

Workshop: How to approach UX Decisions

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

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

Workshop: key distribution mechanims interaction in clients

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

Quick overview of key dist mechs:

How do we deal with presenting/combinging all these?

Critiria to care about:

e.g. of how these are done:

gnupg:

mailpile:

mailfence:

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?)

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

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

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

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)
Persona Devices Scenario
Thomas, 43. Germany. Developer, current GnuPG user. stationary desktop (Win), laptop (Linux), personal phone (Android) Retrieving encrypted email on phone and also on other devices, ability to read messages on all devices at all times
Ming, 24. HK. Data analyst, father laptop (macOS), personal phone Going to a protest, wants to communicate with fellow protesters, but also need to check in on child
Olga, 37. Ukraine. Investigative journalist travel laptop, personal phone (iOS), secure phone (iOS) Border crossing, one phone confiscated by border agents; still wants to access and send encrypted mails to her editors and sourcese confiscated by border agents; still wants to access and send encrypted mails to her editors and sources
Alex, 56. Canada. Job-seeking public desktop, personal phone (Android) Works at a computer in a public library during the day, wants to send/receive encrypted email at home and at libraryencrypted email in both desktop and mobile contexts

Workshop: Thunderbird & OpenPGP

Background: The old thunderbird plugin interface is being removed and with it Enigmail. Thunderbird is picking up OpenPGP support as core development c.f https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/

The statements below are a snapshot of our current thoughts for the TB OpenPGP integration. Anything said here might change during the next months.

Thunderbird will do its own implementation (with existing library) instead of outsourcing to GnuPG to avoid need for complexity of separate installed application. We need a library that has been audited, monitored for side-channel attacks etc. Boton and RNP libraries seems likely to use for actual cryptographic operations.

A large number of past Enigmail support requests were related to GnuPG setup. About 20 million installations of Thunderbird and about 300,000 enigmail users. Wants to make OpenPGP easily accessible for the masses.

Important to have an upgrade path where they, maybe once, maybe more often, can migrate key material from gnupg to Thunderbird. Initial import of the old Enigmail/GnuPG keyring.

How will TB manage the key? It might use the keyring storage implementation of RNP, and use private keyring files that live inside the Thunderbird profile directory. Thunderbird could protect all secret keys with the same random passphrase, randomly created by Thunderbird, which in turn is protected by the existing Thunderbird master password mechanism, and the associated symmetric key that Thunderbird/NSS already manage. (Vincent's recent AutoCrypt Add-on has implemented that idea, and we could reuse that code.)

Christian commented that the existing password storage mechanism in Thunderbird/NSS is not considered safe enough within BSI, but unknown why. We're guessing: KDF not using sufficient iterations. (However, NSS developers currently working on improving that, see https://bugzilla.mozilla.org/show_bug.cgi?id=524403 ) Also, it is easy to see the passwords in TB if a user has not enabled a master password and leaves the computer unlocked.

RNP implements a keystore that is GnuPG compatible (they claim both KBX/g10 and gpg keyring). Thunderbird might potentially use that keystore format, but will not share the same keyring directory with GnuPG.

Although RNP doesn't support smartcards currently, a potential solution was suggested by Kristian and Andre: talking to SCDaemon (scd) with IPC. Details need to be discussed, but it would be an optional solution, that only works if the user has installed software (scd etc.) in addition to Thunderbird. How would this work? GnuPG as an optional dependency? Outsourcing smartcard handling to scdaemon (scd), which is available cross-platform through Unix socket or TCP/IP (windows) with usual user system protection? Or... extend the RNP library to talk to scd? Needs discussion and contributors, but that should wait until we're certain what library TB will use.

Should master password be a requirement for enabling OpenPGP? Maybe it's better to keep that optional, as it could be considered too much hassle. Better to explain it well (e.g. cloud backups of computer files can be used to access unprotected keys), to motivate people to enable master password.

Very important to ensure that you have a proper recovery method for private key material so users don't get into surprises if migrating between devices. (Backup reminder?)

We're under time-pressure, because of fixed Firefox schedules, which have an immediate impact on Thunderbird. Fully stable production quality needs to be ready by summer 2020. So initial expectations is for a minimalistic deployment, it should still be possible to encrypt and decrypt messages. Code-reviews is a slow process in Thunderbird process which can require multiple iterations before committing code. Completely unrealistic to work separately in a branch and getting it merged back due to fast movement of the main development tree. Intend to work on main TB development branch, disabled with a pref while it's not yet usable.

Because of Efail, TB will only decrypt outermost MIME layer, this will also impact mailing lists (???unclear what this comment refers to). If doing it like k9mail there is a set of (nine?) MIME structures that is recognized and will decrypt nested content.

There will not be a Thunderbird plugin-API for other encrypted mail add-ons in the first version. It was argued, this could make some users unhappy. However, it was noted, some will also be unhappy because Thunderbird no longer supporting the old style plugins in the next year release.

If we use RNP, we'll probably use JS C-types to call the C API from javascript. The current enigmail is fully written in Javascript and calls out to GnuPG for cryptographic operations, these parts will then be rewritten to use a C API instead. The botan library is written in C++ with a C API for a subset. The botan library uses exception handling for a great part, which is not allowed in Firefox, so Thunderbird can only use the C API.

When asked about the future user experience, a comparison was used to explain it. One group of apps (i) uses a power user UI, which requires the user to know about the terminology, but has a lot of control over many details, examples are gnupg on the command line, and Enigmail might also fit into group (i). Another group of apps (ii) attempts to automate as much as possible and avoids asking questions. Examples for group 2 could by Delta Chat and Vincent's recently presented AutoCrypt extension for Thunderbird.

The idea for Thunderbird is to be in the middle between these two groups. Make it easier than (i), but make less decisions automatically than group (ii) does. Explain what's happening, involve the user by make suggestions and ask for decisions (not by prompts/alerts, it's better to use one screen notifications, which require the user to take the first step).

One reason for considering this approach, we cannot have a fully automated solution that also helps the user to remain secure against active attackers.

The TB integration might have a new UI with wizards etc to automate as much as possible, but the user needs to actively choose to enable OpenPGP to avoid negative user experience. See also a survey from 2015 about enabling e2e encryption, that supports taking this approach:

Idea: For new users it might make sense to automatically decrypt (stored) messages on reception to avoid issues with archiving (loss of access to message archive if key is lost)

Who is using Thunderbird? Someone who wants more control than webmail / other solutions. This might be a rationale for giving users choices if they are explained well enough.

Important to learn from the experience of trainers of e2e encryption that exists already when designing the UX, e.g. how strictly should terminology be reused? Avoid new terms/explanations?

Suggested that the OpenPGP community could follow the Thunderbird beta cycle, as a way to learn what Thunderbird is doing, and allow you to give feedback, while we still can implement changes before the release.

Thunderbird is based on the enterprise version of firefox that receives only one major upgrade every year. Support for thunderbird 60 will end soon. There is an overlap between versions in Thunderbird for 2-3 months after a new version is released. Thunderbird 68 is supported until fall next year. Thunderbird 78 will be released in june. After this it is too risky to keep supporting old thunderbird as it doesn't receive any new security fixes.

Workshop: Validation of Digital Signatures

1st: timestamps for signature verification (OpenPGP signature creation time)mps for signature verification (OpenPGP signature creation time)GP signature creation time)

Workshop: Mail test suite

It would be nice to have a corpus of interesting mails. It would be nice to select a mail from a given corpus with specific properties or to generate a mail with specific properties as a test suite to test email clients for presentation of security indicators to the user.

Where to find mail test cases:

Problems:

Workshop: What we learned from EFAIL

Workshop: Mail STS

Different preferences

We decided to focus on "expect valid signatures"

Mechanism

Points raised

Semantics

Other examples

On violation

Research paper

Followup

Workshop: WKD

Implementations?

List of Capabilities for clients?

Specifics to consider:

Workshop: Future of SKS Keyservers

​Workshop: Symmetric key​​​​​​ re-encryption of archived ​​​​​​​mail

OpenPGPEmailSummit201910Notes (last edited 2019-10-31 07:17:58 by AndreHeinecke)